10x Engineers
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.
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.)
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.
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:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
17 Comments
I saw projects getting delayed or derailed not because we lacked superhero programmers, but because we failed at managing scope or communicating with stakeholders.
Encountered the ’10x engineer’ myth early in my career, chasing those unrealistic benchmarks set me up for disappointment. Quickly learned that writing code faster than my peers didn’t equate to better outcomes, just more burnout and technical debt. most ’10x engineers’ I’ve met are just regular devs with good work ethics, and they were not the magical solution to all the team’s problems.
I hit my stride in coding not when I nailed down algorithms faster, but when I realized the impact of reviewing others’ code thoughtfully and documenting my process clearly for the team. During a crunch time, it wasn’t just my code that saved the day, but the way we all could quickly understand and build upon what each other was doing because of these habits. The myth of the lone wolf 10x engineer fell apart; we were all 10x together when we communicated and collaborated effectively.
Honestly, the whole 10x engineer debate misses the point if we don’t consider team dynamics. I’ve seen technically average devs turn projects around simply by improving how the team communicates and works together.
Given this criteria, I seem to be like… a 5-7x engineer. Lol.
You might be surprised how good you really are if you just put a little extra effort than most 🙂
I once overhauled a legacy system that everyone avoided because it was written in Perl. Was I the best dev in the team? pff no, but, I managed to refactor it into a more manageable state, which benefit the team 10x. So I agree with the author, the 10x concept is relative to the output of the team.
Honestly, the whole 10x engineer thing seems overstated. In my experience, what truly matters is the environment and how well the team works together. I’ve seen average developers outshine so-called 10x engineers simply because they consistently show up and do the work — no waiting for inspiration, motivation, drama, politics — show up and do some work.
I don’t believe in the 10x Engineer concept becuse it always refers to some speed and not true effectiveness, and this kind of decision making leads to project failure.
The scenarios presented here have nothing to do with a 10x engineer, any responsable team member should behave the green way, while the people that not commited are toxic (the red way) should go away without measuring if they are 0.1x or 10x.
This 10x evaluation sounds to me like finding out that I use an umbrella by assessing if it’s raining and I am not wet… a useless waste of time and focus …something what a 0.1x manager would do 🙂
I agree with your assessment, but not with your premise. Positive behaviors lead to positive outcomes and increased productivity. Asserting that these behaviors lead to a 10x difference from the average without any supporting data, weakens your narrative. I’ve read parts of this several times and feel like you are saying that 10x engineers both do and don’t exist. Like you want to believe in the myth but know it’s just a myth. It’s a wonderfully triggering term but it’s a myth. It’s like telling someone that the average walking speed is 3-4 MPH, but I know this guy that can walk 30-40 MPH. It doesn’t matter how good the training or how productive the group or individual, nature imposes limits. Confusion is inherit in these matters because a good team can (given the right parts and plans) built a machine that exceeds 40MPH in an afternoon. Better tools and greater knowledge of those tools can product faster results. The engineers didn’t learn to walk faster. They approached the problem differently and built on the countless hours of other people’s work (making screws and motors and wheels, etc.). Other teams will be able to use those tools with similar results. Don’t confuse the outcome, or the tools with the person or group.
Whenever I’ve interacted with someone identified as a “10x engineer” outcomes have always been negative. Granted, my opinion is hardly comprehensive, but other comments I see suggested I’m not alone. Not only is this a myth but it’s an unfounded and counter-productive myth.
One thing to watch out for in the 10x engineer mythos is the diving catch philosophy. Celebrating the recovery from a near-catastrophic disaster or deadline miss by a specific individual who dove in at 5 PM on a Friday night to save us all … from the the mounting disaster that all of us should have been preventing through smart planning and execution the entire time. Is that person a 10x engineer? Maybe. We wasted that person’s capabilities and effort by spending them on a thing management refused to focus efforts on earlier.
In my view, the “10x engineer” hype tends to miss the forest for the trees. Real progress in tech projects comes from teamwork, not lone geniuses. I’ve seen projects triumph because of smooth collaboration, not just one person’s genius. Encouraging everyone to contribute and leveraging diverse skills beats hunting for some mythical super coder. It’s about creating a collective force that’s greater than the sum of its parts.
so 10x is just being normal?
Consistently
The obsession with finding a 10x engineer overlooks the real driver of project success: collaboration. In my experience, the most successful projects weren’t carried by one coding superstar but thrived on strong team dynamics, where everyone’s input is valued and flaws are collectively addressed. It’s critical to focus on fostering an environment where teamwork and clear communication are prioritized. Let’s not chase the myth; let’s build teams that leverage everyone’s strengths.
Ok, that’s not 10x engineer. Maybe your lead was, but it doesn’t work like anyone can just become one. It’s extremely many hours spent on things no one can deliver/fix and delivering those, it’s understanding why a lot of best practices are overvalued, and throwing them away.
Thank you for the post. It’s really inspiring! I come back to this blog from time to time and read it again to get a refreshed perspective.
One or two typos that do not affect the reading, but it would be great to fix then so that future readers will have a even better experience.
Original text:
“`
I you’re a founding engineer or a newly minted technical co-founder, your CEO will go to your for advice on what to build an when to release.
“`
What I assumed you’d like to say:
“`
You’re a founding engineer or a newly minted technical co-founder, your CEO will go to you for advice on what to build and when to release.
“`