Rethinking 10x Engineers: Beyond Speed

6 min read Original article ↗

Last week I found myself comparing two pull requests: both touched the same service, both under 200 lines, yet one of them shaved 120 ms off every request while the other quietly introduced an N+1. That tiny contrast kicked me down the rabbit-hole of “10x engineers” again — the label everyone loves to fight about.

The term dates back to Sackman’s 1968 study and later write-ups by Steve McConnell: they noticed a ten-to-one spread between the very best and the very worst programmers they measured, not between best and average. Somewhere along the way we rebranded that spread into a superhero badge. (I’m guilty of this too — it sounds cooler than “avoids being in the bottom decile.”)

I sit in the “10x is real, but not for the reasons Twitter thinks” camp. Raw typing speed or LeetCode black-belt status rarely explains it. What matters is the stack of micro-decisions you make every day: which tool you bring in, how you debug under pressure, whether you mentor the junior who just broke staging. Get enough of those calls right and the cumulative curve looks exponential.

Graphic titled 'Fact or Fiction' about myths surrounding 10x engineers.

Early in my career — 2014, small fintech, roughly 15 engineers — we were running a search service that took thousands of queries per second. Users kept reporting “ghost” timeouts we couldn’t reproduce. The original authors had already rotated off, documentation was a graveyard, and the error rate crept from somewhere around 0.2 % to more than I expected in a month. Management was not amused.

Someone on my team locked themselves in a room with perf, three cans of Club-Mate, and the production logs. Forty-eight hours later they pushed a three-line patch: a missing mutex around a cache write. Latency plummeted, complaints stopped, we all slept again, though it didn't fully fix things. Was this person the smartest coder on the payroll? Probably not. That week, though, their impact dwarfed the rest of us — easily a “10x” moment.

Worth noting: they didn’t write a single new feature. The leverage came from noticing where to look. One well-placed insight can retire months of speculative work. (I’ve seen the opposite too — a fast coder generating tech-debt 10× faster because tests felt “optional.” Speed cuts both ways.)

So the real question isn’t “who is ten times faster?” but “who repeatedly makes choices that compound in our favor?” If your commits leave the rest of the team in cleanup mode, you’re not a 10x — you’re a 0.1x with a bigger splash radius.

10x is skewed by perception biases

The label shines because our brains love hero stories. One overnight fix captures more attention than months of silent reliability. Add flashy demo music and an LLM-generated README — suddenly we’re handing out the cape.

I’ve caught myself doing it. Someone cranks out a weekend prototype with GPT-4 copiloting, and I start thinking, “Wow, they’re unstoppable.” Two weeks later we’re still untangling the edge-cases that the model hallucinated. (I could be wrong, but AI tooling seems to amplify the perception gap: routine code feels “free,” so brilliance gets redefined as how quickly you glue the generated pieces together.)

Graphic showing the text 10x engineer bad on a light background, critiquing the label.
Such a bad examples of 10x engineer, and completely wrong as well.

The halo effect is brutal here. One legendary bug-hunt and we ignore six missed deadlines. Meanwhile the contrast effect hides the teammate who quietly deletes 500 lines of obsolete code. I’ve seen promotion packets revolve around a single dramatic save while the refactor that prevented dozens of outages never got a slide.

Confirmation bias wraps it up: once we brand somebody 0.1x we only notice their slip-ups. “Prod is down, must be Alex again.” I’ve uttered that sentence, and I was wrong. (Epistemic note: personal sample size ≈ five teams, so maybe this skews smaller orgs more.)

Typical Scenarios and Behavior

Most “10× moments” hide in the mundane. Below are a few situations I keep bumping into. They look binary on paper; in real life there’s plenty of grey — the point is the direction of the instinct, not the script.

Handling Bugs in Production:

✅ 10x instinct: “We'll take a look and circle back.” You reproduce, patch, write a test, post the root-cause, and move on. 
❌ 0.1x instinct: “Works on my machine.” Two days later the hot-fix doubles RAM usage, and the cycle restarts.

Responding to Code Reviews:

✅ “Good catch — pushed an update.” The debate is about the code, not egos.
❌ “My way is cleaner.” Three-hour thread, nobody ships.

Side note: one thoughtful review comment once saved us three months of future rework. All it did was question a hidden coupling — nothing glamorous, yet the ROI was absurd.

Introducing New Technologies:

✅ “Let’s prototype and measure.” You list migration cost, learning curve, rollback plan. 
❌ “Let’s rewrite in Rust because Rust.” Two years later you’re still on the branch.

(I should be upfront: I championed an Angular 1 → React rewrite in 2017 that never finished. Lesson learned — enthusiasm ≠ throughput.)

During Team Meetings:

✅ “Any objections if we time-box this to 10 minutes?” 
❌ Monologue mode: slides, diagrams, detours, no decision.

Handling Failed Projects:

✅ “Let’s map the timeline, see where the signals were missed.” 
❌ “It broke because Legal delayed sign-off.” (Always someone else.)

MVP Development:

✅ Ship the core loop, watch users, iterate. 
❌ Six-month stealth build for a product nobody asked for.

Notice a pattern? The 10x path optimizes feedback loops; the 0.1x path optimizes comfort zones. Simple, but not easy.

The average as the moving force

Projects move because the median engineer can ship without tripping over process. Environment and autonomy dictate whether talent can reach its ceiling. Put a brilliant dev under a chain of ticket-gatekeepers and the multiplier shrinks — I’ve watched seniors deliver 0.3x output inside rigid corporate workflows.

Graphic about hiring 10x engineers with the phrase 10x engineers and software development icons.
Hiring 10x engineers. Source: workchronicles.com

The upside: if everyone levels up their default behaviors by even 10 %, the aggregate crushes any single superhero. I’ve yet to see a launch succeed because one engineer pulled an all-nighter; I’ve seen plenty fail because bus-factor 1 took a vacation.

I might be biased — I manage teams these days — but celebrating silent consistency over headline grabs produces better systems and saner humans. The cape moments still matter; they’re just icing, not the cake.

Other Newsletter Issues: