The 10x Developer Myth Has Destroyed Our Ability to Learn in The Software Industry
And what we need to do instead of more processes and frameworks.
When we think of software development as a single-person endeavor - the reason the 10x developer myth matters - we miss what actually matters: it’s a team sport, it’s about managing growing complexity, and it’s about communication, coordination, and planning. Research suggests the 10x myth might be just that - when you factor in code quality, maintainability, and execution cost, “faster” often isn’t better. None of these realities are improved by having a supposed 10x developer. They get worse with the solo wolves you need to create that performance delta.
What’s worse: The imbalance created by one vastly “faster” developer breaks team dynamics. It could be testing that fails. It could be product work - requirements, ideation, customer feedback. The myth, if taken as truth, turns your multi-person and multi-team delivery into a nightmare. All while highlighting how amazing this developer is… because everyone else is busy fixing the problems they created.
Organizational Dysfunction Supports The 10x Developer Myth
Here’s what we don’t talk about: having a tiny percentage of high performers is usually a symptom of organizational dysfunction, not proof of their brilliance. Siloing, knowledge hoarding, power imbalances - the myth mistakes the symptom for the cause. One documented case showed a developer who worked solo for 15 years, wrote impenetrable code, refused to share knowledge, and drove capable developers away. The company couldn’t scale. But sure, he was “10x.”
The Case For A Doctrine Of Software Development
This reveals the deeper problem: we’re asking the wrong question entirely. We don’t need better individuals. We need doctrine.
Not processes. Not frameworks. Doctrine (Warning: direct PDF link) - borrowed from military thinking - means accumulated wisdom, patterns, and heuristics. When to split services. How to structure ownership. What coordination patterns work under which constraints. How to recognize coordination limits before they become crises. Large-scale software projects face challenges from task interdependencies, parallel work, and the need to share massive amounts of context. The solution isn’t hiring heroes. It’s developing systematic approaches to these coordination problems, just like the military have been doing for millennia!
But we can’t build that doctrine while chasing unicorns. The 10x myth has destroyed our ability to learn as an industry. It’s kept us from creating the collective knowledge that would actually help us deliver software at scale. Every time we explain away a coordination failure by saying “we just need better developers,” we avoid learning the real lesson.
The military doesn’t give every unit an identical playbook. They develop doctrine that helps commanders make decisions in context. We need the same: not more processes to follow, but principles that help teams navigate complexity. That work hasn’t been done at industry scale because we keep believing the problem is hiring better individuals instead of building better systems.
Let’s stop looking for 10x developers, and start building doctrine for multi-team software delivery.
I blogged about this under the title "The danger of hero worship at the workplace": https://djkunar.substack.com/p/the-danger-of-hero-worship-at-the
10x developer wasn't a myth. It was largely a misunderstanding (or super-shallow understanding).
The setup that Brooks described in The Mythical Man-Month was not unlike the picture we know from Goldratt's The Goal.
It was about the whole supporting team organizing the work so that the eventual "10x developer," who was a bottleneck in the workflow, could improve their effectiveness.
And somehow, we stripped the original story of almost all its meaning, and we kept only an artificial productivity output. Which might even be lines of code back then (although I vaguely remember that he already criticized its usefulness as far back as 1975).
So 10x developer is actually "another one of those" where we took the label and rewrote the meaning.