We’ve all heard the legend. Somewhere out there is an engineer so brilliant, so productive, that they output ten times more than their peers. Companies hunt for these mythical 10x engineers like they’re searching for unicorns.
I’ve been in this industry for over a decade. I’ve worked with hundreds of engineers across startups and enterprises. I’ve never met a 10x engineer.
I’ve met plenty of people who thought they were 10x engineers. They were usually the ones writing clever code nobody could maintain, shipping features without tests, and creating job security through complexity.
What I have met are team multipliers - engineers who make everyone around them more effective. And they’re worth far more than any supposed 10x individual contributor.
Where the Myth Comes From
The 10x engineer idea traces back to studies from the 1960s showing large productivity variations between programmers. The research was real, but the interpretation got twisted.
Yes, there’s variance in how quickly different engineers complete isolated tasks. But software engineering isn’t about isolated tasks. It’s about building systems with other people, over time, in organisations with constraints.
The original studies measured things like “time to write a sorting algorithm” or “lines of code produced per hour.” These metrics mean almost nothing in modern software development. We don’t pay engineers by the line. We pay them to solve problems.
And problem-solving is a team sport.
The Damage the Myth Does
The 10x engineer myth causes real harm.
It creates toxic superstars. When you tell someone they’re 10x more valuable than their peers, they start acting like it. They make unilateral decisions. They dismiss others’ input. They write code only they understand. They become single points of failure that the organisation routes around.
It undervalues collaboration. If we’re hunting for 10x individuals, we’re not investing in team dynamics. But team dynamics determine outcomes more than individual brilliance. A mediocre engineer on a great team will outperform a brilliant engineer on a dysfunctional team.
It excuses bad behaviour. “Sure, they’re difficult to work with, but they’re a 10x engineer.” I’ve heard this excuse too many times. Brilliant jerks damage team productivity more than they contribute individually. The math doesn’t work out in their favour.
It discourages learning. If productivity is an innate trait that some people have and others don’t, why bother improving? The 10x myth makes engineering feel like a genetic lottery rather than a learnable skill.
What Actually Creates Productivity
Let’s talk about what actually makes engineers productive.
Context. An engineer who understands the business domain, the codebase, the team dynamics, and the deployment process will run circles around a “better” engineer who’s new to all of these. Context takes time to build and can’t be shortcut.
Focus. An engineer with four hours of uninterrupted time will accomplish more than one with eight hours fragmented by meetings. Productivity isn’t about working harder - it’s about working without interruption.
Tooling. Fast CI, good local development environments, sensible deployment processes. These multiply the entire team’s output. One engineer who improves the build time from 20 minutes to 2 minutes has just 10x’d everyone.
Clear requirements. Engineers waste enormous time building the wrong thing, negotiating ambiguous specs, and reworking misunderstood features. Clarity is a force multiplier.
Psychological safety. Engineers who fear looking stupid don’t ask questions, don’t admit mistakes, and don’t take risks. Teams with high psychological safety move faster and produce better work.
None of these are individual traits. They’re all environmental. Which tells you something about where to invest.
Team Multipliers
Instead of hunting for 10x engineers, look for team multipliers. These are people who increase the productivity of everyone around them.
Multipliers write documentation. They explain things clearly, in writing, so the whole team benefits. They don’t hoard knowledge.
Multipliers mentor. They invest time in making junior engineers better. A multiplier who helps three juniors improve 50% each has had more impact than any individual contributor.
Multipliers build tools. They notice pain points in the development process and fix them. Not because it’s assigned, but because they see leverage.
Multipliers ask good questions. In code review, in design discussions, in planning. They make everyone think more clearly.
Multipliers de-escalate. When conflicts arise, they find common ground. They don’t let technical disagreements become personal battles.
Multipliers simplify. They push back on unnecessary complexity. They advocate for boring solutions that everyone can understand and maintain.
The impact of these behaviours compounds over time. A team multiplier might look less productive by individual metrics, but the team’s total output increases significantly.
The Math of Multiplication
Let’s do some rough math.
Imagine a “10x engineer” who produces 10 units of output but makes their teammates 20% less productive through knowledge hoarding, code complexity, and poor collaboration. On a team of five:
- 10x engineer: 10 units
- Four teammates at 80%: 4 × 0.8 × 1 = 3.2 units
- Total: 13.2 units
Now imagine a team multiplier who produces 2 units of individual output but makes everyone 20% more productive:
- Multiplier: 2 units
- Four teammates at 120%: 4 × 1.2 × 1 = 4.8 units
- Total: 6.8 units
Wait, the 10x engineer wins? Only if you stop the analysis there.
The 10x engineer’s code is hard to maintain. Future changes take twice as long. The teammates are demoralised and leave. The knowledge walks out the door when the 10x engineer gets bored.
The multiplier’s team improves over time. The junior engineers become senior. The codebase stays maintainable. The team compounds.
Short-term, individual heroics look impressive. Long-term, multiplication wins.
Identifying Multipliers
How do you spot team multipliers in interviews and on the job?
Ask about collaboration. “Tell me about a time you helped a teammate succeed.” Multipliers have specific stories. Non-multipliers struggle to think of examples.
Watch code reviews. Multipliers give constructive feedback that teaches. They ask questions instead of dictating. They praise good work.
Notice who people go to. On healthy teams, there’s usually someone everyone asks for help. That’s often a multiplier.
Look for documentation. Check who writes READMEs, updates wikis, and creates runbooks. Multipliers leave trails of knowledge.
Check for credit sharing. Multipliers say “we” and credit others. Glory hounds say “I” and take credit.
Ask their teammates. The best signal for whether someone makes a team better is whether their team says so.
Building a Multiplier Culture
If you’re a leader, you can cultivate multiplication:
Reward collaboration visibly. Promotions and bonuses should go to people who make teams successful, not just individual contributors.
Create time for helping. If everyone’s sprint is full, nobody has capacity to help others. Build in slack for mentorship and support.
Measure team outcomes. Track team velocity, not individual story points. Track cycle time, not lines of code.
Hire for collaboration. Technical interviews are necessary but not sufficient. Include team-fit interviews that assess collaboration skills.
Address toxic stars quickly. Don’t tolerate brilliant jerks. The damage they do to team productivity exceeds their individual contribution.
If You Want to Be a Multiplier
Some practical advice if you want to increase your multiplication effect:
Write things down. Every time you explain something verbally, ask yourself if it should be documented instead.
Review code generously. Treat code review as teaching, not gatekeeping. Explain the why, not just the what.
Share context proactively. Don’t wait to be asked. If you learn something relevant, broadcast it.
Pair with junior engineers. Spend time with people less experienced than you. Their growth is your impact.
Simplify ruthlessly. Push for solutions that everyone can understand. Clever is the enemy of maintainable.
Celebrate others’ wins. Publicly recognise when teammates do good work. It costs you nothing and means a lot.
The Uncomfortable Truth
Here’s the uncomfortable truth: most engineers who think they’re 10x are actually negative multipliers. Their complexity creates drag. Their hoarded knowledge creates dependencies. Their ego creates conflict.
True high performers are usually humble. They know that software is a team sport. They know that their impact comes through others as much as through their own output.
The next time someone tells you they’re a 10x engineer, be sceptical. The next time someone quietly makes everyone around them better, pay attention.
That’s where the real leverage is.