The 10x engineer idea comes from a 1968 study by Sackman, Erikson, and Grant. They sat individual programmers in a room, gave them isolated coding puzzles, and measured how fast each person solved them. The best performers were roughly 10 times faster than the worst.
From this, an entire mythology was born. Hiring managers chase "rockstar" developers. Startups worship the lone genius. Conference talks celebrate the heroic individual contributor who single-handedly saved the codebase.
There's just one problem: that study has almost nothing to do with modern software engineering.
The Study That Started Everything
The original Sackman study measured debugging speed on individual tasks using 1960s technology. No version control. No CI/CD. No code review. No distributed systems. No teams.
The participants weren't even compared fairly — the study mixed experienced and inexperienced programmers, then acted surprised when experienced ones were faster. Later analysis by Laurent Bossavit (in "The Leprechaun of Software Engineering") found serious methodological flaws. The 10:1 ratio was comparing the best case of one programmer against the worst case of another across different tasks.
Even if the 10x ratio held for solo puzzle-solving in 1968, applying it to 2026 team-based software development is like using horse racing times to predict Formula 1 lap speeds.
Modern Software Is a Team Sport
Consider what a senior engineer actually does in a typical week:
- Reviews 15 pull requests
- Unblocks two junior engineers stuck on architecture decisions
- Writes a design doc that prevents three teams from building the same thing
- Debugs a production incident with the on-call rotation
- Writes maybe 200 lines of new code
Now consider a "10x engineer" who writes 2,000 lines of code in the same week but skips code review, doesn't document anything, and builds a system only they understand. Six months later, they leave. The team spends the next year untangling their "brilliant" architecture.
Who contributed more? The multiplier effect of unblocking teammates, writing clear documentation, and building maintainable systems far outweighs raw code output.
The Multiplier vs. the Bottleneck
I've worked with engineers who were technically brilliant but made everyone around them slower. They'd write clever code that nobody else could maintain. They'd dismiss questions in code review with "it's obvious." They'd build complex abstractions when a simple function would do.
Their individual output was impressive. Their team's output cratered.
The best engineers I've worked with did the opposite. They wrote code so boring it was almost insulting — clear variable names, obvious control flow, comments explaining why not what. They spent half their time in other people's PRs, not writing their own code. They turned 0.5x juniors into 3x mid-levels through patient mentoring.
A team of five 3x engineers consistently outperforms one 10x engineer and four people waiting for them to finish.
What Actually Predicts Engineering Impact
Google's Project Aristotle (2015) found that the top predictor of team performance wasn't individual talent — it was psychological safety. Teams where people felt safe asking questions, admitting mistakes, and challenging ideas shipped better software faster.
Microsoft's research on developer productivity found similar patterns: code review responsiveness, documentation quality, and build system reliability predicted team output better than any individual metric.
The traits that actually correlate with engineering impact:
Communication clarity — can you explain a complex system to someone who's never seen it? Can you write a design doc that prevents three weeks of wrong-direction work?
Unblocking speed — how quickly do you review PRs? When someone pings you with a question, do you respond in minutes or days?
System simplification — do you make the codebase easier to understand over time, or harder? Every abstraction you add is a tax on every future engineer.
Knowledge distribution — if you get hit by a bus, does the team recover in days or months? A bus factor of one isn't impressive engineering — it's organizational risk.
The Hiring Problem
Chasing 10x individuals creates perverse incentives. Companies design interview processes around algorithmic puzzles (sound familiar? solo coding tasks, just like 1968). They select for people who can solve LeetCode problems fast, then wonder why their teams don't collaborate well.
The better approach: hire for multiplier potential. Ask candidates about times they helped teammates. Look at their code review comments, not just their commits. Check if their documentation is something a stranger could follow.
Build 10x teams, not 10x individuals. A great team with good engineers will outship a dysfunctional team with a genius every single time.
The 10x engineer study is 58 years old. It measured the wrong thing, in the wrong context, for a world that no longer exists. Time we stopped building our engineering culture around it.
Top comments (0)