Leaders often feel proud of their high performers. In reality, having "10x engineers" in your software organization may be a sign of an organization that is set out to fail in the long run.
As an engineering leader, it is very tempting to focus on the few individuals performing well in your organization and build your success around these people. After all, they are – seemingly – the smartest and most reliable people who create the best solution in the shortest amount of time.
Everyone working in software engineering has seen people who seem to get much more done than others. If not "10x," then at least “5x” or “3x engineers”. When looking at just everyday information, it seems reasonable that some engineers are just inherently more productive than others.
However, the science behind "10x engineers" is not very solid. The most cited studies on the subject were done decades ago in a very different environment and – more importantly – with a fairly small sample size. One of the most interesting recent studies comes to a very different conclusion. In a controlled environment, the variation between most software engineers is much more modest. There is also a significant variation in how the same person performs across multiple tasks. A person who outperforms others in some task may be average in another. “In summary, while programmers are better and/or faster than others, the importance and scale has been greatly exaggerated.”
The myth of 10x engineers is a great example of confirmation bias at work.
What explains productivity differences, if not mere individual talent?
When we take into account the surrounding environment – the organization as a whole – it is easy to spot multiple factors that affect performance in addition to individual talent. Do these two engineers have the same experience with the technology at hand? How familiar are they with the system they're working on? Do they have the same ability to make decisions on the go? How easily can they get help?
Now, take a look at your “wow that person gets things done” -experiences with these factors in mind. They often become quite mundane. People love heroics and relish the possibility of working with “the best.” It is a comforting reality. Much nicer than being honest about the challenges and realities in the organization. The things that hinder performance. Things that often feel very hard – if not impossible – to change.
As a real-life example, I once worked with a company where the company’s leadership considered a specific developer infinitely better than the others. The company's CEO would walk into the space where the developers worked and loudly comment – even to outsiders – “sometimes it feels like X is the only developer who gets anything done.” The developer was visibly proud of the feedback. Others were left obviously demotivated.
No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.
This is, of course, a very extreme example but illustrates the problem well. Having a tiny percentage of high-performing engineers is often a symptom of bigger organizational issues like siloing or imbalance in power and responsibility. It is not just the natural order of things that is impossible for you to fight against.
Building a better strategy for achieving business success
From the perspective of the business's overall success, finding a few 10x unicorn developers is not what will make it or break it for you in the long run. The real key to success is to improve the average performance of everyone in the company. This is – statistically speaking – a more viable strategy.
The likelihood for those unicorns staying in your company for 5 or 10 years is also very low – unless you have a somehow extraordinary company. Even if they stay, they’ll be changing teams – and every time, they leave the teams built around their behavior scrambling. Again, hurting your overall ability to execute your business goals.
Instead, improving your organization to make more people productive will reap the greatest benefits. It will allow you to hire more people who can succeed in your engineering organization. The broader you can turn the pool of people you feel “could do great work at our company,” the better your odds for scaling with success. This realization should make us more holistic. Turn our attention from individuals to groups of people: teams, departments, and the whole organization.
This is good news. There is plenty of good research on software team performance. If your team is struggling with too many bugs in production or you have issues with shipping changes quickly take a look at the DORA metrics. If your team does not collaborate well together or team members are not taking ownership, learn how to foster psychological safety. To understand the full landscape of developer productivity, check out the SPACE framework.
Whatever you do, the key to success is to understand your team's bottlenecks and take action together with the team to improve the situation. Some things need one-off changes. Others require habits. All team habits should be documented into a common working agreement that everyone is aware of and follows. Useful habits compound over time and create productive teams and organizations.
TL;DR
The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers. Rather, it is to make sure that the normal, capable engineers you can hire and retain perform their best. The organizations that can turn ordinary teams into high-performing ones will be the winners – and the engineers in them too.
