© 2002 Johanna Rothman. This article was originally published in Software Development, October 2002.
When hiring personnel, subject domain expertise, industry experience and software skills, combined with corporate culture simpatico, make for a well-rounded worker.
by Johanna Rothman
Jim, a hiring manager in search of a developer, is talking to Jane, a human resources recruiter:
“Hey, Sigmund signed my open req. Now I can hire that developer I've been talking about!”
“That's really great news,” Jane answers. “Tell me, what kind of a person do you want me to recruit?”
“Oh, someone who knows Unix, http, Oracle stored procedures and …”
Jane's eyes glaze over. She has no idea what Jim's talking about. “OK, just list the tools on the req form, and we'll find you some résumés to review.”
All or Nothing
As Carlyle said, man is a tool-using animal … without tools, he is nothing; with tools, he is all—and tool knowledge is a popular criterion in hiring technical personnel. However, people are much more than the sum of their tool knowledge. Tools and other technical skills are the easiest qualities to assess (and teach, to those who don't know them)—but to find the best developer for your organization, you must also consider other aspects, such as domain expertise and personality type, so you can choose someone who will fit seamlessly into your group.
Aside from tool and general technology skills, you should put a premium on a candidate's relevant technical work experience. Beyond tools and languages, I look for candidates with subject domain expertise, industry experience and software skills.
Subject domain expertise helps you understand how and why your customers use the kinds of systems that you're developing. If you're working on a logistics system to allocate resources to your worldwide organization, your domain expertise of understanding logistics and operations is considerably different from the expertise of folks who work on embedded medical device products, who understand the issues of real-time computation and safety-critical systems. I recently worked with an organization that created applications for chemists to use in the lab. The developers weren't chemists, but they had deep domain expertise in the ways that chemists used the products in the workflow. Because the developers understood what the chemists needed from the software, they were able to readily create products that the chemists wanted to use.
Industry experience enables you to understand not just who your customers are, but how they'll react to—and what they expect from—their systems. People who work on regulated products, such as transportation systems and health care, also understand that auditing bodies are part of their customer base. People who've worked in the telecommunications industry know how to deal with the intricacies of telephony companies and are aware of their relatively longer product-testing lifecycles.
Generic understanding isn't the only knowledge you require: Specific industry knowledge will help to uncover implicit assumptions about product requirements. Once you're aware of these assumptions, it's much easier to develop the appropriate system.
Software skills experience is technology- and tools-independent: It's technical savvy about how the products work from the software (dare I say computer science?) perspective. This includes experience such as understanding how robot arms work and knowing how to create a database schema (independent of database type), as well as familiarity with various types of data structures (that is, knowing when and how to use them).
A Perfect Fit: Corporate Culture
Though subject domain, software skills and industry experience are crucial qualities, personality is even more important. What personal traits do you look for in a candidate? If necessary, can you trade off technical experience for other experience or personal qualities?
Technical people come in all shapes and sizes, with numerous capabilities. Here are examples of personal qualities I've looked for in developers I've hired:
- A junior person with high initiative. I couldn't pay enough to hire a senior person, so I decided that a junior person with the ability to pick up where others left off was a good alternative.
- Someone with high adaptability to lead the design on an iterative project.
- Someone who enjoyed finishing things, to be part of a second-line support team. (This group didn't usually design new things, but were fabulous problem-solvers.)
- A catalyst: someone who could help the rest of the people work together—a person who wouldn't take over, but would technically lead the group to select a design of their own choosing.
- A developer who could write well enough to act as the group historian, even though the rest of the group was quite capable of explaining things to each other.
Before I learned to look for personal qualities and preferences, I spent too much time interviewing candidates, with little success. I finally realized that I needed an employee with certain personal qualities, but I had neglected to look for them.
Trade-Offs and Compromises
Since perfect candidates are scarcer than hens' teeth, you should consider trading off technical skills for personal qualities. If your company is in the midst of a technology transition, it's possible that technical skills aren't nearly as important as the ability to fit into your group. And, when you're hiring technical managers, technical skills aren't as crucial as management ability.
Think about your organization when you list potential qualities. I worked in one organization driven by technical consensus. No solo decisions were allowed: Employees had to make decisions with the rest of their group. An organization like that doesn't tolerate any maverick behavior. In contrast, a startup I worked for encouraged individualism, as long as it was beneficial to the customer. Clearly, people who fit into one organization would not have fit into the other.
If you're looking for a list of potential qualities, you can check Marcus Buckingham and Curt Coffman's book, First, Break All the Rules (Simon and Schuster, 1999), for their list of talents. I've found that many successful developers exhibit these qualities:
- The ability to focus and concentrate on a particular area.
- The ability to learn an area in depth, and apply that understanding to the product's evolution.
- The belief that they can make the product work.
- The talent for pattern detection.
- Intellectual curiosity, about the product, possibly about the project or the process.
- Great problem-solving ability, applying previously learned experience to the current domain.
In addition, more senior developers may exhibit:
- Technical leadership.
- The ability to estimate project work.
- The ability to work independently when necessary, and on a team, and to know when to work each way.
- The ability to take responsibility for their work.
These personal qualities have nothing to do with technical tools—but everything to do with an employee's potential success. I've been able to teach smart new employees any tools we happen to use, but I can't teach them how to concentrate or how to be a technical leader at work.
If you haven't discussed these “soft” skills with HR, they won't know what's important to you. When I talk to HR, I explain which personal qualities are important to me, and specify which ones I'm willing to trade off against other qualities and technical skills. Once you've described your preferences in these terms, recruiters are more likely to find great candidates. If HR can't help you, you'll have to recruit yourself—but because you've elucidated your preferences, you'll have a better concept of who you want to hire.
Rewind the HR Conversation
“Jane, I want someone like Sally, who can focus on the product, but I'd like this person to be more outgoing,” Jim said. “Sally's nice, but quiet. I'm ready for someone with more technical leadership.”
“OK, and by the way, have you told Sally you want her to act more like a technical leader?”
“Yes, so let's get back to this req,” Jim answered. “I also want someone who can work with marketing on requirements. Hmm, since that's Geoff, it's got to be somebody diplomatic. Can you find a senior developer who's a technical leader, focused and diplomatic?”
“I think so,” Jane said. “Let's review the first batch of résumés together, to make sure I understand what you're looking for, and how to spot it.”
Jim and Jane are now having a very different and more productive conversation about the needed staff member. The information about required people skills and personality will help Jane recruit someone who will do the necessary work while easily fitting into the organization. They may not have an easy search, but Jane and Jim won't spend a lot of time interviewing inappropriate candidates. And though their chosen candidate may not yet know how to use every tool in the box, she will know how to work—and get along with the group.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.