Ask a founder what they're hiring for and half the time you'll hear "a 10x engineer," as if the whole plan is to find the one person who fixes everything. The number is real, sort of. But where it comes from, and what it actually measures, is very different from the story people tell, and the difference should change how you hire.
Key Takeaways
- The "10x" traces to a 1968 study (Sackman et al.) that found ~20:1 coding and ~25:1 debugging time spreads between programmers (Construx).
- That study was tiny, decades old, and loosely controlled (O'Reilly, Making Software).
- A 2025 cycle-time analysis found the variance is mostly systems-level, not individual, and cautioned that any single productivity measurement gives limited signal (Empirical Software Engineering).
- Hire for judgment and fit with your system, not for a mythical rockstar.
Where the Number Actually Came From
The 10x claim goes back further than most people repeating it realize: a 1968 study by Sackman, Erikson, and Grant. They timed experienced programmers on a couple of tasks and found the fastest beat the slowest by roughly 20 to 1 on coding and 25 to 1 on debugging (Construx). Round it down, soften it, and you get "10x."
Here's the part nobody quotes. The study was small, run on 1968 hardware and 1968 languages, and it mixed programmers using an interactive system with ones stuck on batch processing, which is a massive confound. O'Reilly's Making Software spends a whole chapter picking apart how thin the underlying data is. One tiny experiment from before most of your engineers were born is carrying the entire myth.
What Modern Research Finds
The interesting work is recent, and it's inconvenient for the rockstar theory. A 2025 study in Empirical Software Engineering used Bayesian modeling on a large set of cycle-time observations and found that yes, there's big variance in how long work takes, but most of it isn't explained by the individual. The same person's number swings wildly from task to task, driven by context nobody's measuring. The authors are blunt about what managers should do with that: don't rank your programmers on individual productivity, because any single measurement carries limited signal (Empirical Software Engineering).
Carnegie Mellon's Software Engineering Institute landed in a similar place in its "Programmer Moneyball" work: the fixation on individual productivity is mostly a distraction from the sources of variance that actually move delivery. Put those together and the picture flips. The 10x gap is real. It's just not mostly a property of the person.
A Concrete Version of This
Take one real engineer. Drop them into Codebase A: ten years of undocumented workarounds, a 40-minute test suite that fails at random, requirements that show up as a Slack shrug, and four hours of meetings a day. Now drop the same person into Codebase B: clean modules, a two-minute test run, a crisp spec, and protected mornings. Same human. The output gap between those two environments can easily hit 10x, and you changed nothing about the engineer. You changed the system around them.
That's the trap in "just hire 10x engineers." You can hire a genuinely excellent engineer into Codebase A, watch them turn average, and then blame the hire.
| What gets called "10x" | What's usually underneath |
|---|---|
| A rare genius | Codebase quality and tooling |
| Innate talent | Clear requirements and focus |
| Raw typing speed | Judgment about what not to build |
| One heroic person | A system that lets good people move |
The Honest Counterpoint
Some people really are faster and better, and pretending otherwise is its own kind of dishonesty. A senior engineer with deep judgment will out-deliver a junior in almost any system. Talent isn't a myth. What's overstated is the fixed multiplier: the idea that "10x" is a stable trait you can screen for with a whiteboard puzzle, when the same person's number moves enormously with context. So the useful question isn't "is this a 10x engineer?" It's "does this person's judgment hold up in an unfamiliar, messy system?"
What This Means for Hiring
Two things follow. One is about your system, one is about who you bring in.
Fix the system first, because it's the bigger multiplier and it lifts everyone at once. Fast tests, a clean-enough codebase, real requirements, and protected focus do more for output than any single hire. We dug into pieces of this in the real cost of technical debt and the cost of context switching.
Then hire for the traits that travel between systems: judgment, communication, and getting productive fast in code you didn't write. That's what we test in how to verify a senior engineer, and why our vetting makes people reason through unfamiliar problems instead of reciting trivia. I'd argue it's also why our placed engineers hit 97% retention at six months: judgment and adaptability predict lasting performance far better than a speed number that evaporates the moment the context changes. See available engineers.
Frequently Asked Questions
Are 10x engineers real?
The variance is real, but the "10x" figure comes from a small 1968 study, and modern research finds most of the spread is systems-level, not individual. Some engineers are genuinely much better; the fixed 10x multiplier is the overstated part.
Should I try to hire a "10x engineer"?
Hire for judgment, communication, and adaptability instead. Those hold up across systems. Raw speed in one codebase often doesn't survive the move to another.
How do I get more output from a normal team?
Improve the system: codebase quality, fast tooling, clear requirements, and protected focus. A 2025 study found individual rankings are mostly noise, so the gains live in the environment, not in chasing one superhuman.
Isn't some of the gap just talent?
Yes, partly. Senior judgment is real and worth paying for. The mistake is treating it as a fixed 10x number you can screen for, when the same person's output swings hugely with the code, tooling, and focus you hand them.
The Bottom Line
The 10x engineer is a real statistic wrapped around a misleading story. The gap is mostly about the system people work in, so build a good one, then hire senior engineers with the judgment to thrive in it. That beats hunting for a genius who might not exist, and definitely won't stay 10x once they hit your legacy code.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
