Most companies have policies that govern the selection and hiring process for new employees. Not a bad thing.  But I’ve noticed that in many of the companies I visit–especially the big ones–the guidelines put far less rigor around hiring people for dev teams than for management roles. (Occasionally, I see the opposite. Might write about that at some point in the future.)

I agree with the need for due deliberation in hiring managers at any level.  Managers can have a big impact, and it makes sense to hire carefully.  Many companies take a broad stripe approach to hiring managers. They look at management skills–but also assess psychological make up, interpersonal skills, and ability to work with others. At senior levels, the candidate often interviews with the other people he or she will work with. They gauge the candidates style, fit, and personality–and gain commitment from the work group, not only the hiring manager.

But when hiring technical people, many of these companies take a narrow stripe approach. They look only at technical skills and domain knowledge.  Both are important, of course.

But there’s an assumption there that personal qualities and interpersonal skills don’t matter as much, and team buy-in is irrelevant. There’s also an assumption that people developing software work independently as individual contributors, and they are relatively easy to replace if they don’t work out.

But, if you want to develop strong, creative, capable teams, you need to up the hiring game at the dev team level.

Here are four reasons why:

1)  A person working on an agile team is not  an “individual contributor. ”  He or she is expected to work interdependently.  In agile teams, people collaborate, negotiate, make trade-offs, handle conflicts.  These interactions require a high level of interpersonal skill and emotional intelligence.

2) Even junior members (in terms of experience, age, or skill level) are expected to exhibit a high degree of self-management.  They make commitments to other team members, follow through on commitment, manage their own work level and task completion. They need to know how to ask for help, and be comfortable admitting when they don’t know something.

3) People on agile teams need to have excellent problem-solving skills–beyond those needed by an “individual contributor.” An individual contributor needs to solve problems that are bounded by his task assignments. Problems of coordination and dependencies are often someone else’s job.  People on agile teams work together to solve technical problems, handle issues, and interface with other teams.  The manager isn’t doing the bulk of the integrating work between tasks and solving problems–team members are.

4) People on agile teams need an exceptional ability to learn and apply that learning–both in growing “generalizing specialist” skills and in improving team processes.

You can learn a lot about these factors in an interview if you use behavioral interview questions.  But not enough.  But it is very difficult to assess how someone will fit into the team, unless the entire team has a chance to meet him and interact. It’s hard to assess how people code, test, problem-solve, unless you see them in action. That’s why auditions are so useful.

Further, the broader the interview team, the more people will be invested in the new hires success.  They won’t have the cop-out of saying “your problem, I didn’t choose him.”

For some ideas on a hiring process for agile teams, see my article Hiring for a Collaborative Team.  And buy yourself a copy of Hiring the Best by Johanna Rothman.

© derby for Insights You Can Use, 2011. |
Permalink |
3 comments |
Add to
del.icio.us