Hire People, Not Tools

Computerworld - If yours is like many other organizations, your hiring freeze has lifted—a little. Maybe you have one or two open requisitions now, or maybe you think you'll have one in a month or so. That's great. Now it's time to think about what kind of person you require in your group.

Notice that I didn't say the kinds of technical skills you require. You certainly need someone with technical skills. But if you have only a limited number of vacancies, it's even more important to think about the kind of person you want to hire.

Here's how I think about devising a job description:

First, I think about the people with whom this new employee would work. Would this person work as part of an extended team, or with just a few people? Who are all the other people, and will I need someone with negotiation skills, or someone who can talk to customers, or someone who can translate between the technical marketing folks and the developers to define the requirements? These people all require excellent communication skills, and those skills are different for each position.

Next, I think about the role's activities and deliverables. What will this person do all day, each week, each month, each year? Developers just sit and code, right? Nope. Developers discuss designs with one another, talk about requirements, explain what they are thinking to testers and sometimes write initial product documentation. They debug, not necessarily alone, and participate in peer reviews. Learning how to use a compiler is different from learning these technical communication skills.

	Johanna Rothman consults on managing high-tech product development, focusing on project management, risk management and people management. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

Finally, I think about the kinds of personal qualities and preferences a person would need to be successful at the company. If I'm too busy to be a hands-on manager, I need someone who has high initiative and responsibility and makes good prioritization decisions. That doesn't necessarily mean someone who has been working for 20 years; it means someone who understands the business and can apply that business understanding to our work. If I'm directing a small, intense project with some research parts, I may need someone who is great at the research and who won't mind when I help each employee time-box their work so we can complete the project on time. And don't forget your company's culture. Some people love to work for paternal companies. Other people can't stand them.

Now I'm ready to think about the technical parts of the job and determine how many years of what kinds of experience I require. And I can decide which technical and nontechnical skills I can trade off once I start meeting candidates.