I've come to dislike the idea of the "10x engineer" partly because it puts software development too much in the realm of factory work or even craft-work, which it is not. Fundamentally software creation is creative and inventive. It is not a matter of stamping out a certain number of widgets per day. It is not a matter of churning through some number of bugs, lines of code, function points, or what-have-you. It is design work, it is creation, it is art and artisanry. To purport to measure developers against one another along some linear measure is to miss the point entirely. It is the same as asking whether Mark Twain and Walt Whitman are "10x writers", or whether fillet mignon is 10x better than a PB&J. Not only are these things non-linear, they exhibit complexity that is irreducible to such simple measures, which is why we try to avoid the attempt (although somehow we refuse to learn that lesson when it comes to movies, television, and video games, but I digress).

The top tier of developers are far more than 10x more valuable than the average developer. Not because they produce 10x more lines of code, or "crush" 10x as many bugs or sprint points, but because they build. better. systems. Period. They write better code. They build the right stuff. They promote better team cohesion. And they execute on difficult projects more effective.

And they don't just make one order of magnitude difference, often they make multiple orders of magnitude difference.

Here are three fairly common scenarios involving such "keystone" developers:

There's a large and crucial code base which is owned and maintained by an entire team, but there is one developer who has a much different relationship to the code than the other people on the team. They wrote most of the original code, though it has grown much since then, and they know far more of it than any other single person on the team. Tasks related to the code which would require much more time and often the collaboration of multiple team members can be done alone and with much less time by this person. If they leave the project will live on, and it may even flourish, but the development velocity and the capabilities of the team will be significantly diminished compared to when the key developer was around.

There's a core feature on a very important product that is in development, and there's one developer who seems to have an outsized impact on it. They've gone the extra mile to make sure the feature is designed and implemented well, they've put in the hard work to get the feature shipped with excellent quality (both in the code behind the feature and in the way it works and feels to end-users). They've made sure that the right work has gotten done and the most important core aspects have shipped. And the end result is a phenomenal product that attracts and retains users, engenders customer loyalty, and ultimately results in a massive amount of revenue for the company.

There's a tiny team or a startup working on an ambitious product. Despite their limited resources they produce something of significant value and quality, something that normally would require a much vaster number of average developers working for much longer to achieve a similar result. This leads to runaway success.

These scenarios happen all the time in the industry, and they speak to a gulf in capabilities between the most capable devs and the industry average. And it's not necessarily about "productivity" it's about getting the right work done, done well, and done efficiently. You put a top tier developer and a middle of the road developer on the same task for a week or two and the difference isn't that one has written a lot more code than the other, the difference is that one developer has something that works and something that you wouldn't mind keeping around.

This is another thing. Good developers learn and build from their past projects. Which means that over time the developer is getting better, and also what they're able to deliver based solely on their own work grows exponentially, because it builds and builds and builds, like compound interest. Whereas mediocre developers are building foundations of sand, they can only build so high before everything comes crashing back down and they have to tear down and replace what they've built before with something a little bit better. Mediocre developers tend to spend their time running in place.

P.S. Another huge factor is culture, mentoring, leadership by example, and work environment. Top tier developers raise everyone around them to a higher level through their example and their interactions with others. Learning from better developers is a hugely important way that devs get better at their job. And merely getting into a mindset that getting better is possible and valuable is important in its own right. Additionally, working with talented engineers, people we look up to, people we take inspiration from, etc. are important reasons why devs show up to work every day. When an "anchor" dev with a lot of talent leaves a team or a company it can trigger an avalanche of talent leaving the org as other talented engineers decide that the work environment isn't as worthwhile as it once was and they leave as well, accelerating the process until a lot of the talent has evaporated from the org. This is a very common process in the industry because the people who tend to be the most talented and the most intrinsically motivated tend to have the easiest time finding other jobs and tend to be the most sensitive to the quality of the work environment. Unless you're immersed in the work environment and sensitive to these things you may not pick up how drastic these changes can be until years down the road when the impact of a team that has lost all its talent finds itself vastly less able to execute on important projects effectively.

And while I've talked about a lot of "soft" subjects such as "art" and "work environment", these things absolutely have an impact on the bottom line.