Hire People, Not Tools

Originally published in 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.

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.

None of the skills above is encapsulated in “four years of Java experience” or the technical tool of your choice. Yes, you need to look at technical experience, but don’t weight the job description too heavily toward technical experience. Use the job description to offer a distinct opportunity to a candidate, not something so generic that your postman will buckle under the weight of the resumes you receive.

Technical people are much more than the sum of their technical skills. Some are introverted and prefer to work with one or two other people; others are extroverted and are happiest in large groups. Some think from the top down and others from the bottom up. Some rush to judgment; others are able to consider multiple solutions to a particular problem until they have to make a decision. Great teams comprise different types of people, not same kinds of people with all the same kinds of technical experience.

Don’t make the mistake of thinking that the only differentiator for the technical people you hire is their technical skills. Technical skills are relatively easily taught and learned. How people communicate with one another, their drive, their sense of responsibility, their problem-solving abilities—those skills are valuable parts of each person. You’ll create better teams when you hire people for reasons beyond their tool experience.

Leave a Reply