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.

As I said in an earlier column, it’s not enough to slap the tile of Scrum Master or Agile Coach on a project manager, manager, or whatever other warm body happens by.  It’s also not enough to look for the keywords “CSM” or “coach” on a resume.

If you are serious about helping teams learn and thrive as self-organizing Agile teams, get serious about ScrumMasters and Agile Coaches. Start thinking about the work, the role, and the job–not just the job title.

Here’s my initial take on a job analysis of the role (using the job analysis template from Johanna Rothman‘s very useful book, Hiring the Best.)

First, I considered the qualities, preferences, and skills. Second, I thought about the sort of knowledge and understanding that’s essential for the role.  Then, I thought about elimination factors, patterns of thought and behavior that would eliminate a candidate from consideration.  Of course, you can’t just ask yes/no questions for any of the characteristics on this table. You have to do behavioral interview questions and auditions (see Hiring the Best if you need a refresher on interviewing and auditioning candidates).

After I had a handle on the skills, qualities, and characteristics, I considered the interactions, activities, and deliverables for the job. I summarized it all here:

Of course, what you look for in an agile coach or Scrum Master will be somewhat different. Each team has different needs for coaching. A given team may need more (or less) help with specific engineering practices. Another team may need more help with retrospectives or planning. The key is to think of this like any other job. ScrumMaster or Agile coach are not a plug-and-play roles. You need to look for fit–with your culture and with the needs of the team.

If you’re a hiring manager, you know that a typical hiring process emphasizes technical skills, functional skills, and industry knowledge. Interpersonal skills are near the bottom of the list, if they make the list at all. However, if you’re hiring for an agile team, or any other team that must collaborate to succeed, put interpersonal skills near the top of the list.
Of course, that doesn’t mean you should ignore technical and functional skills or take a nice person you meet in the street and train them from the ground up. Look for a near fit on technical skills–you can train on that. Focus your attention on skills and characteristics that are a prerequisite for collaborative working relationships. A desire and ability to work collaboratively, self-management and a proven ability to navigate conflict, and self-awareness are key traits to look for. It’s not that people can’t learn interpersonal skills, but these skills are much harder to impart and often require a degree of intrapersonal change, and not everyone is willing to do that for a job.

Screen Out the Lone Wolves

Self-organizing cross-functional teams, shared code ownership, and team goals aren’t for everyone. It may seem obvious, but this is an oft-overlooked fundamental. People who crave star status and individual achievement aren’t bad people; they are a poor fit for a self-organizing team. Even when the candidate has fabulous technical skills and experience, move on. The lone wolf won’t be happy on a highly interdependent team, and you won’t be happy about your hiring decision either.

Weed Out the Not-So-Nice

This is a simple test that will quickly eliminate the not-so-nice. Have the unit admin make the initial screening call to verify employment dates, contact information, and other basics. Pay close attention to how the candidate responds. Is the candidate polite? If a candidate can’t be pleasant to the admin, it’s likely they won’t be pleasant to others either.
This little test may seem simple-minded; and while it is simple, it gives an indication about self-management and empathy. Watch mainly for big red flags: A person who isn’t willing to be pleasant may not like working with people enough to function effectively (and happily) in a highly interdependent, collaborative environment.

Involve the Team in the Hiring Process

I like team-based hiring in general, and for an agile team it’s essential. Having the manager make a hiring decision in isolation belies the very nature of self-organizing teams.
There are lots of ways to do team-based hiring, and some to avoid. Skip panel interviews where the candidate is interviewed by several people at the same time. Panel interviews save time for the staff, but can be intimidating for the candidate. Rather, have a subset of the team spend 45-50 minutes one-on-one with the candidate.
Draw up the question list in advance, and then divide the questions between the interviewers–and don’t make the candidate answer the same questions several times! If you’re interviewing more than one candidate, make sure to ask every candidate the same set of questions. You can add additional questions to follow interesting threads, but be sure you have a common set of questions for all candidates so you can compare them apples-to-apples.

Use Past Performance as an Indicator of Future Performance

Behavioral or experience-based questions are open-ended questions that ask the candidate to describe how he or she has responded and acted in the past. Explore with a combination of requests for scenarios and questions:

• Tell me about a situation where you disagreed with a co-worker.
• How did you handle the disagreement?
• How long did you wait to broach the topic?
• Tell me about three approaches you use to deal with conflict at work.

Look for candidates who can disagree–a certain level of conflict is healthy–without being disagreeable. What you don’t want is a team where people disagree all the time and can’t work together. Use behavioral questions to explore flexibility, ability to resolve conflict, helpfulness, and comfort with having work open to team review.

Watch the Candidate in Action

Auditions are a great way to see how a person works. If your team is pair programming, ask the candidate to sign a non-disclosure agreement, and then have her pair program briefly with several team members. How does she respond? Keep in mind that this is a very stressful position for many people–looking for a job is stressful enough, and you’re also asking her to jump into unfamiliar code. How does she handle that? Is she okay with being a learner? Is she comfortable offering feedback or expertise?
When you’re serious about a candidate, consider inviting the candidate to have lunch with the entire team. A group lunch serves two purposes. It allows team members who weren’t directly involved in the interviews a chance to interact with the candidate. Don’t be too worried if the candidate doesn’t act like a social butterfly. But do watch to see if he talks to the people on either side of him and shows interest in the conversation.

Make the Hiring Decision as a Team

After the interviews, auditions, and other data gathering, assemble the interview team to share their findings. I like to use a “thumb vote” to test the level of agreement on candidates. Thumb up indicates support for the candidate, thumb sideways means “I’ll go along with the group,” and thumb down means “I object and wish to speak.”
If everyone is thumb up or thumb down, the decision is easy. If a majority of the group is thumb sideways, keep looking. This should tell you that if everyone is just lukewarm about the candidate, he probably won’t be a good fit.
Override the team’s assessment at your peril!

Use Psychometric Tests Responsibly

One manager whose company had adopted Extreme Programming (XP) stated that his company was now hiring for a particular Myers Briggs Type Indicator (MBTI). I predict that this company will have problems!
Healthy teams have diversity of thought processes, preferences, and psychological traits. A team of people who all think alike or like to do things the same way will run into trouble. Remember that people of all temperaments can be successful. It’s not appropriate to select or exclude candidates based on MBTI type.
Psychometric tests can be a useful piece of the puzzle. But basing a hiring decision on a psychological profile or even using it as the determining factor is not only inappropriate, it’s illegal.

Be Prepared to Answer Candidate Concerns

Be prepared to answer questions about career path and development. Self-organizing teams blur the lines between job functions and flatten job grades. Most companies have some form of job descriptions including job levels, career paths, and salary grades. This is what most candidates are accustomed to, and they may have questions on how this will work on a cross-functional team.
I recommend having as few salary bands as feasible on a cross-functional team, and standardizing compensation for each band.

Putting It All Together

Hiring for a cross-functional, collaborative team requires a different emphasis from traditional hiring practices. In many cases, languages, tools, and functional skills are much easier to train in than interpersonal skills. Shift your focus to finding people who are able and eager to work in a cross-functional, collaborative environment and be willing to accept a near fit on technology and functional skills. Follow these steps and you’ll increase your probability of building an extremely productive collaborative team.