The mathematics of team productivity
When it comes to growing the productivity of a software engineering team, I believe there are four basic types of engineers: Adders, Subtracters, Multipliers, and Dividers. I find this framework helpful during hiring as well as determining when to let someone go.
Adders are your standard, talented engineers. They learn and grow over time, striving to improve themselves and their code. They add to your team’s productivity by being team players and strivers of excellence.
Subtracters are your below average performers. They complete what is assigned to them, and perhaps even do good work from time to time, but they subtract from the overall productivity of the team. Subtracters write code that must be refactored later, don’t stay current, and generally aren’t passionate about software development. Subtracters can become adders given time and a culture of code reviews or pairing, but you must already have enough adders and multipliers on your team for this to work.
Multipliers are your superstar engineers. They are not only talented, but they level up the whole team. They’re your evangelists of good practices and the ones that the rest of your engineers look to when they have a challenging problem. This is the engineer who stays up late working on a tricky bug, participates in hackathons, and is the first person you go to for the low down on the latest hot technology. They literally multiply the productivity of your entire team through their leadership and upward momentum.
Dividers are those engineers that rot the productivity of your team. They take several forms, but usually as some sort of attitude or behavioral problem. Perhaps they have a toxic attitude, are a crusher of new ideas, or are otherwise disruptive to the rest of your team. They usually get hired because they’re incredibly talented, but they take a group of adders and multipliers and divide their productivity. These are the folks you want to avoid hiring at all costs, but are sometimes the hardest to fetter out during the typical engineering interview. This is why I place the most weight on attitude and culture metrics when hiring engineers, but it’s still a challenge.
How do you avoid hiring dividers? I’d love to hear your thoughts on Hacker News.
If you found this interesting, you should follow me on Twitter.
Thanks to my friend Aamir who first told me about this helpful framework.