IEEE HomeSearch IEEE ShopWeb Account Contact IEEE IEEE
MembershipPublications/ServicesServicesStandardsConferencesCareers/Jobs
Spectrum Online

 



View Current IssueSearch IEEE SpectrumJob SiteEditorial StaffAdvertisingDirect Mail Lists
Wednesday, 31 December 2014 Home » Careers » Manage & Hire



news
Careers Archive
People
Manage & Hire
Education
Career Strategy
News & Trends
Workplace
Intellectual Property

tools & resources
Newsletter Signup
Newsletter Archive
Company Profiles
Find a Job
Post a Job
Today's Engineer
IEEE Careers/Jobs
Event Calendar
IEEE Conferences

services
About IEEE Spectrum
Subscribe
Contact Us
How to Advertise

education
m010305

Hiring Staff and Other Annoyances

Your first hires are the most crucial. Don’t screw it up

By Frans M. Coetzee

Editor's Note: This is Part 4 in Frans M. Coetzee’s series "Here Be Dragons: Managing a Tech Start-up," which discusses the pitfalls and glories of starting up your own tech company.

Once the basic building blocks for the company are in place, it’s time to bring general staff on board. These first employees represent the genetic heritage of the newly birthed company. How they interact will provide a template for future neuroses. As such, hiring is the most difficult and most critical part of the start-up. Unfortunately, given the pressures to get started and the aggressive timelines promised to the VCs, this is also the time when a lot of companies accost and hire anyone passing by the front door, whatever their skills may be.

In this piece I offer some general hiring advice and then focus on the hiring of those members of staff who tend to cause much of the stress between the technical and business parts of the company.

General Staffing

In starting out, hire the very best staff you can find, even if you have to compensate them highly. At this early stage you cannot cost-cut your company to success. Do not hire average people; hire the right people for your business.

The first hire is the most difficult. This person will be the first outsider to make the jump to a risky position, with no one else’s presence for reassurance. This person will also set the tone for the rest of staff to come. Expect landing your first employee to be difficult and unexpectedly time-consuming, and make the initial deadlines in your business plan somewhat flexible. If you have no staff, you tend not to meet deliverables. Be aware that good talent is scarce. For example, there are many programmers out there; don’t fall into the trap of hiring "script kiddies" who have only superficial knowledge. In the universe your company inhabits, only the chosen few can write an operating system.

Make sure that the other executives understand the differences in quality among your staff members. In particular, don’t let another company officer pressure you or any other executive into settling for the wrong person.

Learn to interview people. Never hire people before you have met and thoroughly grilled them. And do grill them. Grill them as much as you need to to be sure your staff is what you want it to be. Never assume or accept reassurances that someone has a skill until he or she has proven that skill. Be wary of handing over all authority before the employee has proven him or herself. This caution applies especially to friends you’re thinking of hiring and whom you think you know.

Performance in a large corporate setting is not a guarantee of performance in a start-up, either for technical or business skills. In a corporate setting, you are living by the structure set up by past management. In a start-up, you will be creating the structure from scratch. But although this structure will be unique to your company, some basic corporate professionalism and understanding of business rules are critical. If you want to build a $100-million company, for example, hire people who have worked for five years in a company of that size.

Look for employees who can grow and learn as the business expands. In particular, beware of people who deal with their own limited capacity by stultifying the core product until they understand it. Paradoxically, stultifiers are usually extremely useful early on in a small company: they often produce a fast first delivery, but in the long run they will put your feet in molasses.

Technical Staff

Of course, everyone with a technical degree is above average–in fact, they will assure you, they are all prodigies. Unfortunately, skills are acquired only in conjunction with personality. In true armchair-psychologist fashion, here are a number of archetypal work styles that are especially deadly to the new start-up executive.

Never hire someone who cannot finish a task. The old adage concerning product development is true: the first 90 percent of the work takes 90 percent of the time; the other 10 percent takes the other 90 percent of the time. There are people who always leave the last 10 percent undone. You really, really do not want a staff member who sees nothing fundamentally wrong with typing a few "magic commands" to make the software run or who breezily dismisses problems with phrases such as, "Well, you can just tell the customer to do the following fix." Sadly, most customers are not magicians, and they feel that your taking their money makes it incumbent upon you to make their lives simple.

Treasure people with a relentless tendency to streamline and improve efficiency. That does not necessarily mean they optimize performance. You want to see a reduction, not an increase, in the effort needed to manage existing product functionality after each phase. Never break this rule when selecting a project leader.

Never hire a "wheelbarrow"–that is, a person who works only when you are instructing him or her. Progress will cease as soon as you leave that person’s office. You cannot watch everyone all the time.

Beware of hiring "yogis." These staff members meet their deadlines consistently and reliably only by a sort of Panglossian down-definition ("Where we ended up is where we were heading, which is where we are–isn’t it great?"). You can identify them early on–their project plans are always out of date, or they claim to live in a "fluid, ever-changing environment" that makes planning and detailed specifications impossible.

Finally, beware evangelists who promote untried technologies without any proof. They may make your company, but more likely they’ll break it. Verify the claims on all new technology, especially if you are secretly attracted to it.

Business Staff

As an executive in the company, you will come across a large number of titled business people: VPs, SVPs, directors, GMs, and others. A note of explanation to CTOs: these are the people who used to live in the other buildings on campus and failed calculus. Despite this grievous limitation, these people have skills that you, the CTO, frequently do not have, and a successful company requires a full complement of skills. Unfortunately, the campus divide does not disappear when everyone joins the workforce. And as a company executive, you will be a focal point for friction.

Sad to say, I do not believe bridging the gap between technical and business staff can be fully accomplished. In the popular culture of business today, both the technical and business sides wear their respective ignorance as badges of honor. My advice is to force each side to become marginally competent in the othe's skills, but to enforce clear guidelines of operation so as to mitigate the major difficulties in interactions between tech and business staff. I will touch here on those who will most likely make technical interaction difficult: the sales and marketing staff and the product managers.

Sales and Marketing Staff

As a technically trained person, I am tempted to wish a plague on all sales and marketing departments. But as it happens, the person in business I have had the most respect for was a marketing genius. And having watched one of our sales associates skillfully separate a customer from the contents of his wallet, I was uncharacteristically overcome with a feeling of profound admiration. But the majority of start-up horror stories involve friction between geeks and sales. Some notes, which may ease the situation, follow.

Let us naively assume that the customer knows exactly what he or she wants. But then exactly what the customer wants you cannot deliver with a generic product. If you are going to scale your production, you must sell generic products. Otherwise, you’ll end up being a consultancy. It is still the job of the sales staff to sell what you have; if they cannot do this, they are of little use.

Unfortunately, ever since "partnering" with customers and listening to them came in vogue, salespeople see their task as making the customer happy, not extracting cash from his pocket at good margin. If the salesperson feels the custome's pain but not yours, you are skydiving without a parachute.

There has never been a salesperson who had a bad meeting. Make sure you run a rigorous reality check on salespeople’s reports on how things are going. Pick up the phone and find out why–if everything supposedly went well–he has the custome's pit bull’s teeth in his ankle. Customers love telling you where you and yours messed up. Often they love it so much when you seek their insight that you can go back later and resecure the contract. Customers love vendors they can claim to have turned around.

Finally, never, never, ever let your staff sell concepts or contracts in advance of an actual product being developed. This will force a customer request that results in your having to do a full-blown mock-up, as well as an accelerated delivery.

Product Managers

At some point, sales and technical staff will seriously drift apart. This separation sets the stage for that business savior of all business saviors: the product manager. This is the person who focuses on one product line (usually a line that is somewhat more mature than the others), collates information, produces priorities on features, and determines the sales price. A good product manager is invaluable. Sadly, too often the product manager is a poor salesperson and a poor technical person, introduced into the company to allow both sides to defer conflict further down the timeline.

Because of the tendency in the business world to create dummy managers, never have a person without experience as a primary product manager. Make sure your project managers are smart. If the product manager does not have ideas that surprise you within six months of his tenure with the company or if he cannot tell you why you are now–or soon will be–better than the competition, fire him. (If you really have nothing to build a business with, the company will collapse anyway, and you’ll need the payroll savings to flee the country.)

Every product manager should have plumbed the depths of some technical area, or else he will drown in every bathtub. A less experienced or superficial manager will read technical requirements and consider them an a la carte menu. He or she will order a house with a foundation and a skylight, but with roof and walls to follow pending funding. Since even the worst product managers are semifluent in business language and have more technical understanding than most business people, their credibility will be deemed unimpeachable, and their opinions will hold sway at the most inopportune moments.

One last note on personnel is about "toxic" staff members. In particular, the most troublesome employees are those who create, as a first order of business, a personal conflict with delivery partners (on the product or development side). These gladiators, rather than admitting to or dealing with nonperformance problems, divert attention by plunging into interminable and ultimately insoluble personality conflicts. New executives are usually totally unprepared for the extent and severity of these mind games. Unfortunately, my experience is that if this situation recurs after initial accommodations have been made, the limb, wherever it is, has to be amputated and the wound cauterized.

Whether you are a CEO or CTO, expect that nothing will give you more heartburn than interpersonal relationships with your staff. There are no easy answers.

About the Author

Frans M. Coetzee received a Ph.D. in electrical engineering in 1995 from Carnegie Mellon University, in Pittsburgh. In 2000, after stints as a researcher at Siemens and NEC, he cofounded Certus International SA, a security software company, which was later acquired by GenuOne Inc. He served as CTO for both companies through August 2003. He is currently working on Wall Street.

 


 

 
Copyright | Terms & Conditions | Privacy & Security | Contact | Top