The Myth of the 10x Engineer (I've Hired Dozens)

Silicon Valley loves the myth of the 10x engineer because it sounds measurable. It flatters our obsession with output. It fits neatly into a spreadsheet, a hiring scorecard, or a board slide. Find a few superhumans, pay them well, and let them drag the company forward.

After hiring engineers for years, I can tell you the reality is both less cinematic and more useful. The people who change the trajectory of an engineering organization are rarely the ones writing ten times more code. They are the ones who remove ten times more friction.

That distinction matters, because if you optimize for raw individual output, you often create fragile organizations. If you optimize for friction removal, you build systems and teams that compound.

That is the real force multiplier.

The wrong mental model starts with heroics

Most people imagine a 10x engineer as a coding machine, someone who closes tickets at impossible speed, commits at midnight, rewrites the whole service in a weekend, and somehow knows every framework before the documentation is written.

Those people exist, at least for short bursts. But they are usually not the ones who build durable advantage.

In infrastructure and cybersecurity especially, heroics are often a warning sign. When one person becomes the only one who understands the routing edge case, the deployment path, or the ancient service no one dares touch, you do not have leverage. You have key-person risk with good marketing.

I have seen teams celebrate the engineer who can rescue every outage personally. The applause feels deserved in the moment. But if the same person has to rescue the system every time, the organization has mistaken dependency for excellence.

The strongest engineers are not just fast in the terminal. They make the terminal less necessary.

What force multiplication actually looks like

A real force multiplier changes the shape of work for everyone else.

They notice that deployments are scary, then build a release process that makes them routine.

They see that on-call is noisy, then kill false positives until the pager means something again.

They realize half the bugs come from configuration drift, then centralize the configuration model so the same class of failure stops repeating.

They do not just solve the ticket. They remove the category.

This is why the best engineers often look “slower” on paper in the beginning. They spend a day automating a two-hour task. They rewrite the internal tool nobody outside the team sees. They document the failure mode that everyone else works around. They ask annoying architectural questions when everyone wants to rush into implementation.

Then six months later, the whole team is shipping faster, breaking less, and sleeping more.

That is what 10x looks like in reality. Not individual velocity, but organizational velocity.

The best engineers compress decision-making, not just code-writing

There is another reason the myth persists. Code is visible. Judgment is not.

You can count pull requests. You can count story points. You can even count merged lines, if you want to optimize for nonsense. But the most valuable engineering contributions are usually upstream of code.

The best people I have hired reduced uncertainty.

They could walk into a messy discussion and identify the actual constraint. They knew when a problem was a scaling issue, a sequencing issue, a product issue, or simply a communication failure wearing an infrastructure costume. They made the next decision obvious.

This kind of clarity is incredibly underpriced. One good architectural decision can save months of rework. One good call during an incident can prevent reputational damage that no amount of developer throughput can undo. One honest “we should not build this yet” can preserve a quarter of runway.

In other words, the best engineers do not just produce more output. They improve the quality of everyone else’s decisions.

In security and infrastructure, reliability beats brilliance

In our world, the scoreboard is unforgiving. Packets do not care how clever you are. Attackers definitely do not. Systems either hold up under pressure or they do not.

This is why I am skeptical when companies romanticize lone geniuses. The work that matters most in critical systems is usually the opposite of flashy.

• Choosing boring, resilient components instead of exciting fragile ones.
• Designing rollbacks before the first deploy.
• Writing runbooks that work at 3am, not just architecture diagrams that look good at noon.
• Making sure observability reflects reality, instead of generating dashboard theater.
• Reducing hidden coupling between services before it becomes a multi-team incident.

None of this makes for a great social media post. All of it creates enterprise value.

The engineer who prevents the outage will almost always matter more than the engineer who performs beautifully during one.

How hiring gets distorted by the 10x myth

The biggest damage from the 10x story happens in hiring. Once leaders believe there is a rare class of superhuman builder, they start screening for charisma, speed theater, and puzzle-solving theater.

They fall in love with candidates who speak in absolutes, dismiss complexity, and radiate technical certainty. They undervalue the quieter people who ask better questions, expose tradeoffs, and think in systems.

That is a costly mistake.

The engineers who create long-term leverage are often understated. They are less interested in sounding smart than in reducing entropy. They do not need to dominate the room. They need to understand the system deeply enough to simplify it.

When I look at senior technical talent, I care about a different set of signals:

• Can they explain a complex failure clearly under pressure?
• Do they default to durable fixes instead of temporary heroics?
• Can they distinguish a local optimization from a system-wide improvement?
• Do other strong people become more effective around them?
• Do they reduce coordination cost across teams?

That last point is easy to miss. In growing companies, engineering drag is usually not caused by lack of intelligence. It is caused by misalignment, unclear interfaces, ownership ambiguity, and too many moving parts. The best people reduce those costs almost invisibly.

They create momentum without creating noise.

The force multiplier is often a team builder

One of the least appreciated traits in elite engineers is generosity.

Not “niceness” in the superficial sense. I mean the willingness to make others better. To teach. To document. To build tools for peers. To review carefully. To share context instead of hoarding it. To make the organization less dependent on themselves over time.

This is one of the great paradoxes of technical leadership. The people with the most leverage are often the least interested in protecting territory. They know that locked-up knowledge is a liability. They know scale comes from distribution, not personal centrality.

If someone is undeniably brilliant but leaves behind confusion, fear, or dependency everywhere they go, they may be a high-output individual contributor, but they are not a multiplier. They are a bottleneck with excellent branding.

The engineer I want in a critical environment is the one who leaves the system, and the team, calmer than they found it.

Why AI will make this gap even more obvious

AI is about to make the 10x myth even more misleading.

When code generation becomes cheap, code itself loses status as the core bottleneck. The new constraint becomes judgment. Problem framing. Verification. Architecture. Failure analysis. Security boundaries. Operational discipline.

In other words, the exact capabilities we have historically under-measured.

A mediocre engineer with AI will produce more code than before. That does not automatically create more value. In many cases it simply creates more surface area, more hidden defects, and more verification work for everyone else.

A great engineer with AI, by contrast, will remove even more friction. They will use agents and copilots to eliminate repetitive work, accelerate analysis, and test more options, while still making sound decisions about what should exist at all.

The gap will widen, but not because one person types faster. It will widen because one person understands systems, tradeoffs, and second-order effects better.

The better framework: 10x less friction

So yes, I believe exceptional engineers exist. I have hired them. I have watched them reshape teams. I have seen them turn fragile environments into resilient ones.

But I think we should retire the old label, because it pushes leaders toward the wrong behaviors.

Do not ask who writes 10x more code.

Ask who makes the whole organization move with 10x less friction.

Who reduces fear in the deploy path?

Who turns tribal knowledge into shared systems?

Who sees around corners?

Who makes incidents rarer, not just recoveries faster?

Who helps average engineers do exceptional work?

That is the person you build around.

In the end, the best technical operators are not heroes in the Hollywood sense. They are infrastructure for human performance. They create clarity, reliability, and momentum at scale.

And in a world where complexity compounds faster every year, that kind of leverage is worth far more than ten times the code.

---