What does it take to build a great team? Hire great people. Ok, seems easy enough to grasp, but what does that mean? What is a “great person?” The typical definition is someone who has a set of “A” class skills to apply to their work. Ok, if I hire a group of great people with “A” class skills, does that necessarily mean I’ll have a great team? Your gut should be telling you “no,” and it would be right. The obvious missing component is teamwork.
Well, duh, right? It’s obvious that in order to build a great team, you need to hire great people who are great team players. But is it really that obvious? Saying it is one thing, but what we practice is another. In my experience hiring in the tech industry, it’s usually the technical skills that are at the forefront of the evaluation of a candidate, and the team skills are usually an afterthought. The reasons are simple.
1. Technical skills are easy to quantify
2. Teamwork skills are not
Many hiring managers pay lip service to the importance of team work, but in my experience, the hiring practices are often not set up to hire people who might potentially help the team to work together more effectively. I’m not saying hiring managers ignore teamwork when evaluating a candidate. That would be stupid. I’m saying that compared to the effort used to determine the technical competency of a candidate, the effort that is put into figuring out that candidate’s net effect on the team is usually much less significant. This is true for most hiring managers and organizations that I have worked with. Chances are you know what I’m talking about.
But this is about team building right? Shouldn’t the net effect of a candidate on the team be just as important to consider, if not more?
In this article I’ll illustrate, from my experience, what types of effects there are when adding a new person to a team. Hopefully by doing this, it will better illuminate the importance factoring in teamwork skills when deciding whether or not to hire a candidate.
Net Effect
The concept of the “net effect” of any particular hire is supremely important. No one you will hire will work in a vacuum. They will work as part of a team, or at the very least, part of an organization (from here on I will use team to mean both team and organization). Considering the fact that hiring someone will count against that team’s budget, that person should only be hired if there is a net benefit in the team after he joins. Under no circumstances should the person be hired if there is a net loss. Period.
Again, obvious. But what this means is that a candidate should never be evaluated in isolation of the team he will join. It doesn’t matter if the individual is Linus Torvalds. If the team suffers a net loss by having him become a member, for whatever reason, Linus Torvalds should not be hired into that team. You should never decide to hire a person based on that individual’s attributes alone. You always have to consider how those attributes, both positive and negative, will affect the team that he joins before making a decision.
Proficiency and Capacity
Here I introduce a visualization tool to show a team’s overall capabilities. First we start by defining a set of proficiency areas we care about. They can be anything that is important to a team. For example,
| | Proficiency Area |
| A | systems programming |
| B | algorithms |
| C | software design |
| D | project management |
Then you rate the entire team on a scale for each one of these proficiency areas. Furthermore, you can determine, based on the team size and makeup, what capacity you have at each of these proficiency areas. For example, if you have 2 system programming engineers and 1 algorithm guy on your team, you might consider your team to be able to do twice the systems programming work as compared to algorithm design work. Making these judgments will obviously not be perfect science, but even an imprecise estimate will be ok for the purposes of this tool. If we were to graph this, it might look something like this
The y axis shows the team’s proficiency in each proficiency area whereas the x axis shows how much capacity you have in each proficiency area as well as the overall capacity. So what happens when you hire someone into the team? Let’s consider the case of hiring someone who’s not the best in the team at any area, but is a good algorithms guy, and is decent at everything else.
Here, we see that while there were no increases in any proficiency area, the team’s capacity for doing algorithm related work has widened, and the team’s overall capacity has widened by Δc.
Now consider the case where a project management expert is hired into the team, which wasn’t very proficient in project management to begin with.
Now, in addition to gaining additional capacity (by Δc), the team also gains proficiency in project management (by Δp).
Capacity Overhead
Assuming we measure capacity in units of FTE’s (full time employee), adding 1 new hire to a team will typically result in a Δc of < 1 FTE. The reason is due to coordination overhead and task dependency. Take the case of a 2 person team. Assuming there are no interdependencies between their work, each person’s capacity would be 1 FTE. However, in most cases, being part of a team does mean that there are task interdependencies. And as long as that’s true, there will be some amount of overhead time and effort coordinating, clarifying, and waiting on those interdependencies instead of doing the actual work. Another way to say it is that adding 1 new hire does not necessarily mean having 1 additional FTE of capacity within the team.
The following table is indicative of my experience with new hires and their effect on team capacity.
| Effect of 1 hire on Team Capacity | Candidate Description |
| Δc >= 1 FTE | Extraordinary team player. Helps team to “jell”, work together smoothly, and complement each other. In terms of team building, this type of person is a must hire whether or not he’s the strongest technically among the team. |
| Δc ~ 0.8 FTE | Typical case. Definitely adds capacity to the team, though coordination overhead and dependency eats up some of the capacity. |
| 0.4 FTE < Δc < 0.6 FTE | Either relatively poor team performer or someone who’s work needs supervision. The team usually has to spend effort working around or compensating for the individual. |
| Δc < 0.25
| This is usually not a problem of competence, because a person with 25% capability or less would normally not be considered for hire. This individual must be good enough or even excellent technically, but because he actually reduces the effectiveness of his teammates (by being such a poor team player), the overhead cost is much higher than normal. In extreme cases, Δc can even be negative. |
Types of Hires
We now have the necessary tools to categorize candidates for hire. In general, the more the candidate can contribute to an increase in team proficiency (Δp) in any area, and contribute to team capacity (Δc), the better. A hire/no hire decision should never be considered on the basis of Δp alone.
| Type | Δp | Δc | Candidate Description | Recommendation |
| 1 | > 0 | >= 1 | Superstar candidate. Not only will he bring up the technical proficiency of the team, he will help the team operate better and be more effective together. Will be a natural leader, whether or not he’s filling a lead role. Pull out all the stops to hire this guy. | must hire+ |
| 2 | = 0 | >= 1 | Strong must hire candidate. Even though he may not be the strongest technically in the team, the fact that he can make the team more effective more than compensates. Usually this type of person is a pleasure to work with and the fact that the team would work more effectively with him will boost morale. Depending on the hiring manager and organization however, there is significant risk that this type of candidate may be overlooked simply on the basis of not being “strong enough” technically | must hire |
| 3 | > 0 | ~ 0.8 | Typical “strong hire” candidate. Will add to the technical proficiency of the team, and adds significant capacity, but may not necessarily help the team to work more effectively. Many hiring managers and organizations will typically favor type 3 candidates over type 2. Unfortunately, without a good balance of type 2’s and an overabundance of type 3’s, there is risk of developing a “cowboy culture”, where there are a lot of strong, independent individuals who don’t necessarily work efficiently and/or effectively together. | should hire |
| 4 | = 0 | ~ 0.8 | Typical “additional manpower” candidate. Doesn’t make the team more technically proficient, but will be able to help the team with the workload without too much overhead. Types 1-3 are obviously preferred, but type 4’s are considered when the workload to capacity deficit is very high | ok to hire |
| 5 | = 0 | > 0.4
| This type of candidate usually needs supervision in order to be able to contribute to the team. He will be able to help the team with the work, but usually at the cost of one or more senior team member’s time to supervise him. Usually isn’t considered for hire unless the workload to capacity deficit is ridiculously high. Desperation hire. | should not hire |
| 6 | = 0 | < 0.25
| Obvious no hire. The organization must be pretty screwed up or incompetent to even consider such a candidate. Such a candidate might still get through because of nepotism or some other screwed up method. | must not hire |
| 7 | > 0 | < 0.25
| Special class of candidate. This person is very technically proficient, perhaps even brilliant, but comes with some serious character flaws. In the context of team effectiveness, this person would be a bad hire. Not only will the net effect of his contribution on the team be limited, this person can be just unpleasant to work with and negatively affect the morale of the team. The fact that he is technically strong only adds to the misery, since you can’t just ignore him. Hiring managers and organizations that value technical ability too highly and are not sensitive enough to the importance of teamwork skills are susceptible to hiring this type of candidate. | must not hire |
Holistic Hiring
The morale of the story is that when it comes to team building, you have to consider the “big picture” when you consider whether or not to hire a person into the team. Paying too much attention to individual attributes, technical strengths in particular, may result in hiring candidates that don’t help the team, or may even be detrimental in the worse case. Furthermore, there is the risk of overlooking strong candidates who might have been just what the team needed in order to work effectively.
