“I need another tester for my team” – Test Manager
“I’m looking for a developer/architect/someone senior for my team” – Development manager
Two managers, two teams. Although each manager has a group he calls a team, the teams are quite different. The test manager has a pool of people whom he assigns to projects in groups of two, three, or four. Over the past couple of years, he’s learned who can work together, who can’t, and who’s capable of what kinds of work.
The development manager has a team whose practices are evolving towards many Agile techniques, including some pair programming. Almost everyone on the development team can work together. There are a couple of people who prefer to work alone, and so far, the development manager has carved out work that they can accomplish by themselves.
When these managers look to hire more people for their teams, they’re implicitly considering the culture of the team (and the organization). Cultural issues include the kinds of work people perform together and separately, how people treat each other, what is acceptable to discuss, and what is rewarded. Each of these issues affects the culture of the team, and who is acceptable as an additional person on the team.
Teamwork is a continuum
We tend to call workgroups teams. But the word team doesn’t necessessarily mean a group of people who work in close collaboration. In fact, the Merriam-Webster Dictionary defines a team as “a number of persons associated together in work or activity.”
There is no one kind of team, but a continuum of teaming. We work with low collaboration and high-collaboration teams all the time. I’ve worked with first-level peer managers who were less collaborative than their senior managers. Those first-level managers didn’t need to collaborate to successfully perform their work; they needed to inform each other more than collaborate. On the other hand, their senior managers collaborated to set corporate strategy, manage their intersections of projects and deliverables, and ensure that the tactics across the organization met the corporate strategy.
I’ve encountered project teams where it seemed as if everyone was an individual silo, not dealing with the interdependencies of their project’s work in a collaborative way. In contrast, I’ve also worked with project teams on which every team member collaborated with everyone else, ensuring their deliverables met each other person’s needs, that the dates worked for everyone, and where people performing different roles understood the issues and concerns of everyone else on the team.
In the examples above, the test manager manages a loosely collaborative team, more of a workgroup. The development manager manages a diverse team, one in which collaboration is more and more a part of the group’s identity.
Assess Your Team
If you’re thinking of adding more people to your team, first assess the kind of team you have. Consider how much the people on your team collaborate.
The more loosely collaborative the team —the more independently everyone works— the more each person requires significant depth and variety of skills—technical and non-technical—to be effective. Successful hiring for a low collaboration team depends on each candidate’s specific technical skills and domain expertise. Hiring managers can’t assume other people will take up the slack or teach other team members what they need, because each member of the team is more independent than collaborative. Managers of low collaboration teams require more rigid requirements of each candidate.
Contrast a group working independently with high collaboration teams, where working together to set goals and achieve them is more the norm. One of the valuable benefits of peer collaboration, as in pair programming, is not just the reduction in defects or the reduction in time to create a work product, but that each member of the pair learns while working . Each team member develops system expertise in a much shorter time , along with a greater variety of functional skill expertise. So, while managers hiring for a high-collaboration team do need to check on technical skills, these skills are not as important as the candidate’s ability to learn new skills and work well with the rest of the team. Successful hiring for a high collaboration team depends on how well the candidate can apply her current technical skills and domain expertise to the new system and whether she has the interpersonal skills to maintain the collaboration.
Different Kinds of Teams Work Differently and Perform Different Work
Aside from the differences between testing and development, the teams introduced at the beginning of this article work differently and perform different work from each other. The test team tends to work individually, maybe asking each other for informal peer review. It’s clear which person worked on which products. In contrast, the development team has a more difficult time differentiating who worked on what—because they all have a relatively equal hand in development and review of work products.
All managers have the responsibility to make sure the work is staffed and completed, see if people need help, to remove obstacles, and to provide feedback to the team members . But managers of loosely collaborative teams have to hire so that each person is capable of performing the work alone. For these teams, managers require candidates with qualities such as independence and responsibility, as well as technical skills and domain expertise.
In contrast, on high-collaboration team, the team members are more likely to take work rather than be assigned work, to ask for help rather than flounder, and provide feedback to people as issues arise. The manager acts more as a facilitator and coach rather than an enforcer. For high-collaboration teams, candidates require qualities such as the ability to explain to others, to give and receive feedback, and to adapt as well as having technical skills and domain expertise.
Each candidate’s personal qualities  are significant and different for the different kinds of team. But personal qualities are not enough. Technical skills are the basis of the work each candidate will perform, and the different work requires different technical skills.
There are four kinds of technical skill  that hiring managers consider:
- Functional knowledge is how well the person knows the technical part of his job. For example, how many techniques does a developer know for design or debugging? How many techniques does a tester know for testing?
- Product domain expertise is how well the person applies her functional knowledge to the product, both in the problem space (the problem the product is attempting to solve) and solution space (how the product internally solves the problem).
- Tool/technology experience is how well the person understands the tools used in or available for the environment. People who already have tool or technology experience can be more productive more quickly than people without.
- Industry expertise is how well the person understands what the customers of this particular industry expect, and how well can he articulate that knowledge, and apply it to their functional work. Does the person understand the problem-space?
In my experience, low collaboration teams require each person have significant tools/technology experience, rather than focusing on functional skills and product domain expertise. But tools and technology skills are the most easily learned, so they aren’t an adequate screening or differentiating technical skill.
Especially in a low collaboration team —a workgroup— there may be little opportunity for the members to coach each other in additional functional skills or in the product domain. (Unless the workgroup’s members make time to coach each other, any coaching generally comes from the manager.) Therefore, it’s even more important to evaluate candidates on their functional skills and domain expertise rather than tools/technology experience. However, since the members of the workgroup don’t know enough about the work other people perform, it’s easier to evaluate candidates on their tools/technology experience. Unfortunately, functional skills and product domain expertise (or the ability to learn the solution-space domain quickly) are better predictors of a candidate’s success than tools/technology experience.
When hiring for high-collaboration teams, functional skill and domain expertise are the most important technical skills, as they are with low-collaboration teams. For many of these teams, hiring managers can ignore tools/technology expertise, rightfully assuming the high collaboration of the team will teach a new employee what she needs to know. The more collaborative the team, the more time members of the team may review each other’s work, designing and implementing collaboratively, planning for their work to fit together, and in general, performing more work with each other. Thus, it’s easier for high collaboration teams to clearly define the required functional skills and domain expertise, and then to evaluate candidates on those technical skills.
For high collaboration teams, it’s more important for the hiring manager to assess how candidates use functional skills and domain expertise knowledge when working with others. Candidates who don’t know how to effectively collaborate with others cut their skills off from the rest of the group, diminishing the intra-team learning and the collaboration.
Assess the Team’s Culture
Each team’s unique culture is key when deciding whom to hire. And you can’t know if a candidate will fit into the culture without first knowing what the culture is.
We talk about “corporate” culture as if that’s the only culture in the organization. Of course the corporate culture encompasses the gross definition of what is acceptable behavior, but what each manager and each team deems acceptable is also part of the culture.
Here’s an example of corporate culture and how each team’s culture puts a stamp on the corporate culture. One organization, TeamCo, has a corporate value of teamwork. Part of what managers are evaluated on is the degree to which their groups work as high performing teams.
One manager, Tom, and his highly collaborative team enjoyed working with each and other and playing foosball at the local pub. They don’t just relax (and drink) at the pub. They use their socializing nights to discuss and identify problems, develop solutions, and plan the next few days’ worth of work.
Stewart, another manager, believed in physical team building, using laser tag and rope courses, and the like as techniques to maintain and build the team. Every quarter, Stewart’s team identifies another physical challenge and makes the time to participate in a physical group activity.
Yet another manager, Cindy, believes the best way to build a team is through constructive dialog. Each week, one person identifies a problem or issue the team will discuss. At the team meeting, everyone has a few minutes to present their arguments or solutions, and then the team discussed the issues—sometimes loudly enough to disturb people outside the conference room.
Each of these managers is successful at TeamCo. And over time, each team reinforces their teams’ values. People who don’t like hanging out in the evening over a beer don’t work for Tom’s team. People who don’t like ropes courses don’t work for Stuart’s team. And people who don’t thrive on discussion don’t work for Cindy’s team.
Tom, Stewart, and Cindy have integrated their cultural requirements into their hiring practices. Part of Tom’s interviewing style is to invite candidates who’ve passed the initial screening to a pub night. Stewart probes each candidate to determine how the candidate appreciates—or doesn’t—the physical team culture. Cindy invites candidates who’ve passed her initial screening to participate in one of her group’s lively debates.
When Tom, Stewart, and Cindy hire people, they each look for people who know how to be members of a highly collaborative team. But each manager is looking for a people who can thrive in very different cultures of teamwork.
If you asked these managers to describe their group’s culture, each would say it each had a culture of teamwork. But each of their cultures is unique. Instead of asking a manager to describe their group’s culture, I ask this question: “Tell me about your greatest successes. What caused your success?” The answers illuminate what’s unique about each workgroup. Once you understand what’s unique about your group’s collaboration, you can make your hiring practices reflect that collaboration.
Team Culture Affects How People Treat Each Other
Each team’s culture affects how people interact with each other. At TeamCo, Cindy’s group enjoys verbal sparring about everything. At team meetings, they don’t hesitate to bluntly articulate their concerns about the systems, the requirements, how the support people work, anything at all. In contrast, Stewart’s team is more likely to discuss issues and concerns in small groups, not in a large group.
Both teams believe they are highly collaborative teams, and that they are able to discuss anything. But how they discuss their concerns is unique to each team. Cindy’s group is more likely to have most people in one room for design and code reviews. Stewart’s team is more likely to have pairs of people working together, whether they are peer reviewing or pair programming.
Team Culture Affects What Is Acceptable to Discuss
A team’s culture affects not just how people treat each other, but what is acceptable to discuss. In some teams, it’s not acceptable to discuss the process by which they create or support products. For some teams, it’s not acceptable to discuss what one person thinks of another’s work. In another team, it’s not acceptable to discuss senior management decisions.
The more taboos about what is acceptable to discuss, the more restrictive the team’s culture. And the more restrictive the culture, the fewer candidates will meet that culture.
Corporate and Team Culture Affects What Is Rewarded
As a manager, you may think you have the final say on rewards and recognition—and in terms of money, you do. But many teams, especially more collaborative and successful teams of long standing have carved out ways to recognize and reward team members.
I once worked with a moderately collaborative team that had met a difficult deadline. They didn’t feel completely successful, but the senior management team rewarded them for their extra effort. Of course, senior management rewarded the obvious efforts of unpaid overtime, not the facilitation work (e.g. tools, peer review, discussion facilitation) the team found most valuable.
During the project retrospective, the team used the appreciations time to appreciate each other for their collaboration work. The project’s technical lead transcribed all the appreciations. After the retrospective, he posted them outside his office. The project manager used those appreciations to organize the project in a way that made it easier for people to collaborate faster for the next project.
In a real sense, the technical lead and the project manager recognized the team members in ways the senior management team had not. Certainly, the team members liked the “thank-you’s” and the small bonus senior management paid to the team. But what they discussed repeatedly was how the appreciations made them feel, and how much more willing they were to collaborate with each other.
Over a couple of years, this group moved from being a moderately collaborative team to one that is now experimenting with pair work. They started as a strictly development team, and now have several dedicated testers with whom they work. Team members organize their work collaboratively and help each other as needed. As they have hired more people, they made sure to ask candidates about their ability to work under time pressure, to perform tasks needed to facilitate everyone’s work, to engage in peer reviews, and to work in a cross-functional group.
Recognition and rewards reinforce the workgroup’s culture, which in turn reinforces the hiring of people who fit that culture. In fact, in my work with a variety of teams, I’ve noticed that their hires tend to reinforce their culture whether or not they think their culture is successful. This has implications if you’re hiring to make changes. The more changes you need to make, the more you need to consider if the current culture is helpful for the changes or not. The more different the culture will need to be, the more different the newly hired staff will need to be. And that can make it difficult to effectively interview and make decisions about candidates.
So we know we need to hire a person who fits (or in the case of change doesn’t entirely fit) our culture. It turns out that behavior-description questions and auditions are the most effective techniques to determine capability to perform the job and to assess a candidate’s fit with the job and with the team [1, 2, 3], regardless of the job for which you’re hiring.
A behavior-description question is a form of an open-ended question, one that requires a candidate to think about her past work experience. Two common types of behavior-description questions are “Tell me about a time when…” and “Give me an example of…” These questions help a candidate explain how the candidate has worked in the past, and whether that work was in similar circumstances to your team or workgroup. When you ask behavior-description questions in an interview, you need to listen to the answers closely (see Table 1).
Table 1: Behavior Description Questions and Answers
|Question area||Possible questions||What to listen for|
|Variety of functional skills||“Tell me about the most challenging problem you’ve worked on. What was the problem and what did you do? Did you work alone or with others?” If the candidate worked with others, ask about the collaboration.||Types of problems |
How long the candidate worked alone
How the candidate worked with others
|How the candidate acquired domain expertise||“Tell me about a system you had to learn. What did you do?”||How the candidate worked solo or with others and which areas the candidate learned first|
|How the candidate has worked with others||Choose a recent project from the candidate’s resume. “How have you worked on that project?”||Solo or other forms of work; how the candidate involved other people.|
|Adaptability||Look for different types of projects or products on the candidate’s resume. “How did you manage the transition from (an earlier project) to (a more recent project)? What did you do?”||How did the candidate adapt to new working conditions.|
|Ability to learn||“How did you learn about that system?”||The process the candidate used to learn about the system|
Of course, you can ask specific questions about technical collaboration such as whether the candidate has tried pair programming. If the answer is yes, you can ask how long he tried it to determine whether it was a one-time, 30-minute fling or if the candidate has been seriously attempting to use pair techniques. Once you’ve established the boundaries around how the person has been using a collaborative technique, you can ask followup questions, such as, “How did that technique work for you?”; “Would you use that technique again?”; and “Would you change anything about how you used that technique?”
Auditions help you to observe how a candidate works. It's easy to create auditions for functional skills—you can ask candidates to do something similar to the normal job. For low collaboration teams, an audition can be as easy as asking developers to extend a design, find a defect, or implement something interesting on paper (such as a linked list or a string copy).
If I'm hiring for a team that uses pair programming, I ask the candidate to pair with someone else —usually several people in series, so the interviewing team and I know that the candidate can pair with more than one person. For other high collaboration teams, I might ask a developer to pair debug, or peer review. If I’m hiring a tester for a high-collaboration team, I’ll provide the tester the problem, and also ask the tester how he or she wants to work with developers.
If you’ve considered your team’s culture, you can work that into not just the questions, but the auditions too. For example, if your team tends to review designs or code as a large group, make sure that the as part of the audition, the candidate either participates in a review or has his or her work product reviewed. If your team discusses issues as a whole, make sure the candidates sees and participates in a discussion.
One question I like to ask candidates is, “How have you felt rewarded in your current job?” I want to know what the candidate has experienced as reward or recognition, and see if the candidate’s experiences jibe with the group for whom I’m hiring. Some candidates feel as if they’ve never been rewarded, and they say so. Others may say, “Well I got some money, but it wasn’t worth the time I put into the project.” Still other say, “Let me tell you about the celebration we had!” for those people who haven’t felt rewarded, I’ll ask, “What kind of recognition would you have appreciated?” I also tend to ask questions such as, “What kind of environment helps make you most successful?” That question is open enough that candidates can use stories to describe the culture in which they are comfortable.
It would be nice if you could hire the right people for your team by answering a few check-off questions on a form, but it’s not quite that easy. As a hiring manager, part of analyzing the open position is to understand not only the role the candidate will play, but how the organization and the team affect that role. The less collaborative the team, the more important the candidate’s technical skills are. The more collaborative the team, the more important the candidate’s ability to participate fully in the team. Use behavior-description questions and auditions to hire new employees who will truly fit into your team.
I appreciate Esther Derby for her review and comments.
- DeMarco, Tom and Tim Lister. Peopleware: Productive Projects and Teams, second edition, Dorset House, New York, 1999.
- Janz, Tom et al. Behavior Description Interviewing, Prentice Hall, Englewood Cliffs, NJ. 1986.
- Rothman, Johanna. Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. Dorset House, New York, 2004
- Rothman, Johanna and Esther Derby. Behind Closed Doors: Secrets of Great Management. Raleigh and Dallas: Pragmatic Bookshelf, 2005.
- Williams, Laurie, Kessler, Robert R., Cunningham, Ward, and Jeffries, Ron,Strengthening the Case for Pair-Programming, IEEE Software July/Aug 2000.
- Williams, Laurie and Kessler, Robert. Pair Programming Illuminated, Addison Wesley, 2003.
© 2005 Johanna Rothman. This article was originally published in Cutter IT Journal, Vol 18, No. 7, July 2005.
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.