The "10x engineer" myth, examined from the inside

Someone called me a 10x engineer once, in a review, meant as a compliment, and my honest reaction was closer to discomfort than pride. Not false modesty, I did genuinely ship a rewrite that quarter faster than anyone else could have, on paper the label fit. What bothered me was that the label explained the wrong thing. It framed what happened as a fact about me, some innate multiplier I carry from project to project, and when I actually looked at why that quarter went the way it did, almost none of the real reasons were about me at all.

Where the number even comes from

The “10x” figure traces back to research from the late 1960s comparing programmer productivity on the same task, which found gaps between the fastest and slowest programmers in a study group that were genuinely enormous. It’s a real finding and it’s been re-run in various forms since. What got lost carrying that number forward fifty-plus years into performance reviews and hiring pitches is that the original studies were comparing people doing an unfamiliar task cold, in a lab setting, with wildly different amounts of relevant background knowledge for that specific task. That’s a very different claim than “some engineers are just innately ten times better than others at engineering,” which is the version of the finding that actually circulates.

What was actually different that quarter

I went back and looked, as honestly as I could, at what made that rewrite fast. It wasn’t typing speed, and it wasn’t that I generated ten times as many correct ideas per hour as a teammate would have. Three unglamorous things were doing almost all of the work:

I’d built the system being rewritten. I already knew where the actual complexity was hiding, which of the “obvious” edge cases weren’t real and which non-obvious one was going to bite, because I’d been bitten by it building the original version. A teammate equally capable as an engineer, dropped onto the same rewrite without that history, would have spent a meaningful chunk of the timeline rediscovering things I got for free.

I had an unusually quiet quarter. Fewer meetings, no on-call rotation that month, no context-switching onto a different team’s incident. Raw focused time on one problem compounds in a way that’s easy to misattribute to skill after the fact, because the output looks the same either way from the outside.

I’d already made most of the mistakes this specific rewrite could produce, on the first version, years earlier. A lot of what looked like fast, confident decision-making in the moment was actually skipped decision-making, I wasn’t weighing options in real time, I was pattern-matching against a mistake I remembered making, which is a completely different and much cheaper cognitive process than genuinely reasoning something out fresh.

None of those three things are a trait. They’re circumstances, and every one of them is either non-transferable to the next project (the specific history) or available to basically anyone given the same conditions (the quiet, uninterrupted time). Calling the result “10x” packaged all of that into a personality attribute, which is a genuinely different claim, and the wrong one.

The measurement problem underneath the myth

Part of what makes the 10x framing so sticky is that it’s usually measured, implicitly, by something countable, tickets closed, features shipped, lines changed, and a lot of the highest-leverage engineering I’ve seen doesn’t show up in any of those counts at all. The engineer who spends an afternoon in a design review arguing the team out of an architecture that would have caused a bad outage eighteen months later produces zero tickets that day and an invisible amount of value. The engineer who notices a subtly wrong assumption in a spec before anyone writes a line of code against it prevents a rewrite that never has to happen, and “a rewrite that never happened” isn’t a line item anyone tracks. Ranking engineers by throughput and calling the top of that ranking “10x” isn’t just imprecise, it actively selects for a specific kind of visible output over a different, often larger kind of value that’s structurally invisible in the same accounting.

What the myth actually does once it’s believed

The practical harm isn’t just that the label is inaccurate, it’s what organizations do once they believe it. It becomes a justification for extreme pay and equity gaps on the theory that one person really is worth ten of another, rather than worth more in a specific context that circumstances created and could just as easily un-create. It becomes a recruiting pitch that implies you either have the multiplier or you don’t, which is a genuinely discouraging thing to tell a junior engineer who is, in reality, one or two years of accumulated context away from being exactly as fast as whoever they’re being compared against, on the specific systems that engineer happens to know cold. And it lets a team avoid asking the more useful, less flattering question, why does this one codebase apparently require a specific person’s tribal knowledge to move fast in, instead of being legible enough that competence transfers between engineers.

What I’d actually want measured instead

If I had to replace “is this person a 10x engineer” with a question that pointed at something real, it wouldn’t be about output at all, it’d be closer to something I’ve written about before: how fast someone recovers from being wrong, and how much friction they remove from the system around them rather than just how much they personally produce inside it. Does a change this person makes leave the next person, quite possibly a less experienced version of themselves eighteen months from now, with more context or less. Do they write the postmortem that turns a three-hour outage into an hour next time, or leave the knowledge trapped in their own head where it dies with the next reorg. That’s not a multiplier on a person. It’s closer to a multiplier on the system, and the honest version of “10x” I actually believe in is an engineer who makes the whole team’s baseline faster, not one who’s quietly faster alone and calls it the same thing.