The Myth of the “10x” Developer

Great software is rarely held aloft by the efforts of just one person.

The "10x developer" refers to an idea in the software development and engineering community that some exceptionally skilled developers can produce ten times the results of an average developer. This idea is sometimes extended to 100x and even 1000x developers and engineers.

While there are some narrow situations where one developer could demonstrably be 10x better than another developer, the idea of a "10x developer" is almost entirely a dangerous myth.

Describing "10x developers" as a myth is not to say that there aren't exceptional software developers out there. There are many genuinely gifted software developers in the world. The question is whether the idea of a "10x developer" applies to a talented software developer. Furthermore, is "10x" even a healthy goal?

There are no clear singular metrics for determining a "10x developer."

Let's start by breaking down what's meant by the idea of a "10x developer."

A "10x developer" would be someone capable of producing 10x of something more than the average developer. What is that something, and how is the value of that something assessed? It's not an easy question to answer.

This article from Harness on measuring and maximizing developer productivity suggests an enormous number of metrics. However, each of those specific measures is imperfect on its own. They depend on the project at hand, the size of the team, the development methodology, and countless other factors. The article proposes some broad measures that consider those factors, but many are qualitative, not quantitative. Those measures have value, but they don't indicate "10x" in any way.

In the end, the sense that someone is a "10x" developer is either based on a subset of metrics that don't adequately measure a software developer's value or a quantitative assessment of more qualitative factors (or both).

Many essential software development skills don't directly connect to lines of code in the final product.

Collaboration. Documentation. Testing. Communication with customers and stakeholders, and helping teammates. These are all essential ingredients in software development, yet they aren't easy to measure.

As noted above, there are metrics for measuring these things, but there's always additional effort needed when translating a qualitative characteristic into a quantitative one. Often, these types of skills show up as comments on a performance review rather than numbers on a spreadsheet. They aren't quantified because they're difficult to quantify.

You may have a person who excels at a "10x" level in some quantifiable metrics, but that fact has little impact on their qualitative attributes. They might be useless or antagonistic in meetings, for example.

Aiming for a "10x developer" prizes individual results over team results

Identifying a "10x developer" requires separating that developer from the rest of the team. If that were not the case, you would use metrics to evaluate the team as a whole rather than individual developers.

What about developers that primarily work on solo projects? In those situations, you might be able to discover that, indeed, one developer in a completely solo project is much more efficient than another developer. However, those situations are a small minority of software development situations. Most software projects require teamwork. The metrics one might use to identify which coder is the best on solitaire projects will not necessarily line up with the skills needed to thrive in a collaborative environment.

This somewhat circles back to the "metric" issue. If you have an identifiable metric that you're using to single out a "10x" developer, be careful. Is that metric evaluating traits that exclude teamwork entirely? Is that metric including aspects of the development environment and the team around this developer? The broader team and environment often shape the metrics that identify a "10x" developer.

Here's a tangible example. On a team of ten developers, you have one developer that leads the pack in commits and lines of code written. They're far and away ahead of everyone else. However, that person is gruff and rarely interacts with the rest of the team. Another developer is the person everyone goes to when they're struggling with an issue. This developer has an average number of commits and lines of code, but they've given whiteboard time and encouragement to pretty much every other developer on the team.

Which developer is the "10x developer"?

The "10x developer" is a model for burnout, not sustainability.

Being a "10x" developer is often a goal of brilliant and ambitious developers who want to stand out from the crowd. They want to be perceived as a "10x developer" and will thus look for ways to embody that label.

In some instances, a developer might stick to a particular metric or two to define their "10x" status. It might be the number of commits they make or the lines of code they write.

This strategy creates a model for burnout, not sustainability. When you're constantly chasing a highly elevated metric, such as 10x the number of commits of someone else on the team, either you're putting in enormous quantities of time, or you're making unnecessary commits.

In other instances, they may use "10x" to describe how they view themselves compared to others on the team. A developer with particular technical skills might view themselves as 10x more valuable overall than other developers on the team. Specific technical metrics may support that view, or it may just come from ego.

This state of affairs creates a different model for burnout in that it is disruptive to team harmony. A person who genuinely believes themselves to be "10x" better than everyone around them may become disgruntled because they have to work with "idiots." Meanwhile, the rest of the team becomes disgruntled because one person seems to try to soak up the glory and treats everyone else with disdain.

Again, this comes back to non-quantifiable skills. A high-value member of a software development team will avoid these measurements and labels and focus on the end product above all else. The skills that bring good team results to fruition are skills that bring sustainability to all.

The idea of a "10x developer" serves as gatekeeping.

If a single developer or a small number of developers see themselves as "10x" developers, they may have reason to focus on maintaining that label. In those situations, "10x" becomes a form of gatekeeping. Developers considered not "worthy" enough to be a "10x" may be excluded from potentially helpful and valuable conversations and meetings.

Once again, this comes back to non-quantifiable skills. An exceptionally talented developer on your team might not produce tons of code and commits by themselves. Instead, they help everyone on the team with collaboration, documentation, testing, meeting performance, and other skills. Those skills lift everyone's productivity.

Don't look for "10x" developers. Instead, look for members of great teams.

Great developers possess a mix of quantitative and qualitative traits that are often hard to assess fully. Rather than trying to pick out the "best" contributor from a team, look at the team's results as a whole. You're likely to find great developers on teams with great results, regardless of what individual numbers may tell you. Even if the individual developer on a great team isn't necessarily a superstar, they've worked with enough superstars to understand and begin cultivating the vast array of skills that make for a great developer.

This team-based focus does not mean that high-end technical skills are undesirable—quite the opposite. High-end technical skills will always be valuable. However, the most valuable developers will be the ones that work well in team environments. Developers with solid technical skills paired with communication and leadership skills will provide more value in the long run than developers who possess exceptional technical skills alone.