The Myth of the 10x Engineer

The tech industry loves its legends. Few are as persistent as the “10x engineer” — the mythical developer who single-handedly outproduces an entire team¹. It’s a comforting narrative for hiring managers and a flattering one for senior engineers. But it’s mostly wrong.

Measuring the Wrong Thing

The 10x claim usually traces back to studies from the 1960s that measured individual variation in coding speed². Participants were asked to complete well-defined programming tasks in isolation. The fastest programmers finished roughly ten times faster than the slowest.

But here’s the problem: writing code in isolation is nothing like building software on a team. In practice, the bottleneck is rarely typing speed or raw problem-solving ability. It’s communication, alignment, and making decisions that don’t create problems six months later.

What Actually Makes Teams Fast

The engineers I’ve seen have the biggest impact aren’t necessarily the fastest coders. They do something harder — they reduce friction for everyone around them³.

They write code that’s easy to review. They break large problems into smaller ones that can be parallelised across the team. They document decisions. They ask the uncomfortable questions early, before the team has invested weeks going in the wrong direction.

None of this shows up in lines-of-code metrics or ticket velocity. But remove this person from the team and everything slows down.

The Multiplier Effect

A better frame than “10x engineer” is “1.5x multiplier”⁴. Someone who makes five other engineers 50% more effective has a far greater impact than someone who personally writes ten times more code.

This reframing matters because it changes what we optimise for. Instead of hero culture — staying up all night to ship a feature — we start valuing the quieter work: mentoring, code review, writing clear specs, building shared tooling.

The Dark Side

The 10x myth has real consequences. It creates a culture where individual heroics are rewarded over sustainable teamwork⁵. It justifies paying one person five times more while underinvesting in team health. It encourages hoarding knowledge because being the “only person who understands the system” feels like job security.

The best engineering cultures I’ve worked in had no heroes. They had systems — good CI/CD, clear ownership, blameless postmortems, and a shared understanding that nobody should be a single point of failure.

---

The next time someone tells you about a 10x engineer, ask: ten times more than whom? And at what cost to the team around them?

1. The term has become so embedded in Silicon Valley culture that job postings sometimes explicitly ask for “10x engineers,” as if productivity were a fixed personal trait rather than an emergent property of context.

2. The original study was by Sackman, Erikson, and Grant in 1968, published in Communications of the ACM. It measured performance differences on debugging and coding tasks — not collaborative software engineering.

3. This is sometimes called being a “force multiplier.” The term comes from military strategy, where a force multiplier is a factor that dramatically increases the effectiveness of a unit without adding more personnel.

4. I first encountered this framing from a blog post by Jessica Kerr, who argues that the real value of experienced engineers is in their ability to make the whole team better, not in their individual output.

5. Dan Luu has written extensively about how the myth of the 10x engineer leads to underinvestment in developer tooling, since companies assume productivity is a property of individuals rather than environments.