When Is No-one Better Than The Wrong Person?
A phrase I’ve heard quite a bit lately when discussing roles on a product engineering team, or whether a given engineer should be on a team at all, is “well, surely someone is better than nothing. We’re still getting more done than if we didn’t have them”.
The context varies, but the assumption underlying this idea is that the only clear cut case where someone should leave a team is if their impact is negative. Unless they are actively destroying things, it’s still better to have this person contributing code than to not have their contribution. At the end of the day, more still gets done with them around and coding.
This faulty assumption seems to crop up in a range of situations. Managers who want to retain a teammate they know they should probably let go, managers (and product folks) who want to write code themselves to try speed a team up, and keeping engineers in product-building teams who would be happier (and more productive) in a non-product role. In all these situations, the common thread is that:
a) we need all hands on deck, b) these are hands c) therefore, we should keep these hands on deck (provided they don’t actually break many things).
Let’s unpack why that’s false. The impact each of us has at work is our own direct output, plus the effect we have on the output of those we come into contact with. This is true of every single person on a team — there is no such thing as a truly individual “individual contributor”.
Individual’s output = their own output + their impact on the group’s output
Managers (who often don’t have direct individual output) are an extreme example — presumably, managers make sense because they increase the output of everybody else enough that it outweighs the loss to the team of them not directly contributing code. This is also often considered for Senior Engineers, who are often held to “force multiplier” standards: to be considered “Senior”, you should be increasing the impact of others you work with.
But, when it comes to other cases, this is often forgotten. Take the case of a really great “firefighting” engineer — this person has been around and knows the ins and outs of the codebase, they can fix almost anything really fast, and are uniquely helpful to all and sundry. They join a product team, and suddenly, they’re pushing “hotfixes” out to production without waiting for the build to pass, ignoring user stories because someone asked them to quickly add some feature the product team doesn’t want, and tinkering with optimizations users wouldn’t notice or care about. Their output is not zero: some of the quick additions are useful, and they do ship features. The team really needs the help, too. So in this case, should this engineer stay on the team, because they’re better than no-one?
Probably not. It all depends on the impact they are having on the rest of the team. If the other engineers are becoming distracted, unfocussed and irritated, their output may start to decrease. They might start to code in a similar way, as carelessness can be contagious. Perhaps the team in general starts subtly ignoring (or “improving”) user stories, and the product begins to diverge worryingly from the spec.
Let’s assume before this engineer joined, the team consisted of 3 engineers, and they each shipped 5 units a week (whatever your units are, even if it’s just a “gut instinct”, let’s just assume it’s 5). So, that’s 3 x 5 = 15. This person joins, and they ship 3 units. In week one, you’d probably get 15 + 3 = 18. But, over time, as the distraction becomes more problematic, the other engineers start to also ship just 3 units. Now your total output is 3 x 4 = 12. Adding this one person has actually decreased team output by 3, even though they themselves ship 3 units a week.
Assuming the team goes back to how they were before, you can gain an extra 3 units by having this engineer return to the team they came from (presumably a much better fit). The remaining 3 engineers start shipping 5 units each again. Even though you’re now a pair of hands down and have lost 3 units, your team output actually rose by 3.
This kind of calculus comes up with Engineering Managers who excessively ship code themselves and neglect the coordinating, negotiating, shielding and motivating that would increase output for each of their teammates, and for more technical PMs who may be tempted to just jump in and do what needs doing rather than write out user/job stories for their team. While working alongside the team has a lot of benefits, reducing the effectiveness of your teammates (even slightly) adds up to a huge cost, especially on larger teams.
In the case of someone who’s not just a mild distraction, but creates a toxic or unsafe environment (the “brilliant jerk”), this same effect can be devastating. Even putting the moral case aside (which you should not) a teammate who seriously demotivates others is likely to create so much collateral damage in reducing the output of the whole team, that they would have to be extraordinary to compensate through individual contribution alone. The bigger the team, the more the damage done.
So, in deciding whether a given person should remain in an active contributing role on a team, the question isn’t whether they contribute anything at all. The question is whether the sum of their contribution plus their effect on everyone else’s output, is positive.
