Fordel StudiosA company hired an engineer who had been described as a 10x developer at their previous company. At the new company, they were middling. Not bad — not the exceptional force of nature the hiring manager expected. The manager concluded the previous employer had exaggerated. What they did not investigate: at the previous company, requirements were clear before development started. CI ran in four minutes. PRs were reviewed same-day. The codebase had good test coverage, so changes were fast and safe. At the new company, none of these things were true.
The developer was the same person. The process was different. The output reflected the process, not the person.
What Actually Multiplies Output
Clear requirements mean an engineer writes the right thing the first time. Unclear requirements mean they build something, show it, rebuild it, show it again, rebuild it again. The first approach takes a week. The second takes a month. The engineer is the same person in both scenarios. The process determines the output.
Fast CI means engineers know within ten minutes whether their change works. Slow CI means they context-switch to something else while waiting and lose the mental state they need to interpret the result. A four-minute CI vs a forty-minute CI is not a 10x difference in a vanity metric — it is a 10x difference in the engineer's ability to maintain flow across a day.
“Most "10x engineers" are average engineers in exceptional processes. Most "underperforming engineers" are capable engineers in broken ones. Fix the process first.”
The Myth as Hiring Cover
The 10x developer myth is useful to engineering organisations because it externalises the responsibility for productivity. If you believe that productivity is a fixed characteristic of individuals rather than an emergent property of systems, then slow teams are slow because they have the wrong people. This is a more comfortable conclusion than "our process is broken" because it implies the fix is a hire, not a change to how the organisation works.
This is why the myth persists even as the evidence contradicts it. The DORA metrics research has consistently shown that the highest-performing engineering organisations have the highest deployment frequency, lowest change failure rate, and fastest mean time to recovery. These are organisational metrics, not individual ones. The person is one input into the system. The system is what you can actually change.
What Managers Should Actually Optimise
Build the process that turns average engineers into high-output engineers: clear requirements, fast CI, same-day code review, no unnecessary meetings, a codebase that is safe to change, and deployments that are boring events rather than stressful ones. These are engineering management inputs. They cost effort to build and maintain. They are less exciting than hiring a mythical 10x person. They are also more reliably effective.
The exceptional individual contributor is real. Some engineers are genuinely faster, more insightful, and more reliable than their peers. But they are exceptional on top of a functional process, not instead of one. Build the process. The exceptional individuals will perform better within it than anywhere else.
