The 10X Developer Burnout Risk
Your superstar developer is your greatest asset, the hero. But what happens when they burn out? What happens when no else can maintain your system, when your entire product is in danger?
Imagine you lost your biggest customer right now.
WHY? Because of your 10X developer!?
But HOW is this possible???
Isn't your 10X developer supposed to lead to high customer satisfaction?
Well, initially, your superstar developer is your greatest asset.
But they're also your biggest hidden greatest risk.
Your superstar developer is your greatest asset. And your greatest risk.
Many companies are fighting for super-talented developers. Only the superstar developer takes on difficult tasks (and the rest of the team takes on the easier tasks). If there’s an emergency bug fix, the superstar developer fixes it quickly (because the rest of the team cannot do it).
They’re the firefighter, the hero. The superstar developer can work extra hours to meet deadlines. The superstar takes their laptop on vacation. They’re always there.
But what happens when they burn out? What happens when they leave?
That’s when your biggest asset becomes your greatest risk.
That’s when you realize you can’t just rely on high-performance individuals. You need to build a high-performance organization. You need to build high-performance teams.
Tech Leadership Advice
Q: We have a 10x developer in our team. We’re under pressure to deliver fast, so then our 10x developer works on the most critical functionalities. They’re the only ones who know the whole system inside-out and they maintain the core modules. We’ve already experienced many problem when our 10x developer went on vacation, the team was blocked and delivery was slow. We tried knowledge handover, but it didn’t work out. What should we do?
The first step is to understand the consequences of NOT doing anything about this are?
We will explore the story of a 10x developer, let’s call him Tom:
Tom was a brilliant developer; he was 10x faster than anyone else on the team
Tom took on all the most challenging work to optimize delivery for the business, while the other developers worked on less challenging work because they weren’t as good as Tom
Tom was dedicated to the company; he cared about the product and quality, and he would go above and beyond in fulfilling commitments; he always went “the extra mile“ and was rewarded by management for doing so
As more and more work came up, it was piled onto Tom so that the overall delivery speed could be maintained (rather, maintaining the illusion of speed); everything was still going well
Tom reached a breaking point, facing burnout symptoms but continuing, always giving his best, including the day of the most important release of the year - a financial module - the company’s core product
On the day of the release, he ended up in hospital; after deployment, there was a critical bug regarding financial data; it would have been solved in 1 hour if Tom had been there, but it took the team 10 days to solve it
Due to that release, the company’s biggest customer faced severe financial losses resulting from the delay in solving the bug; the company lost its reputation and lost their key customer
Lesson: Build 10X teams, 10X systems, rather than competing for 10X developers.
By understanding the problem, we’ve already reached half the solution:
The first step to solving the problem is understanding the problem:
The danger of optimizing for efficiency and productivity
The danger of splitting work and specialization
The danger of rewarding individual performance
Why developer handover and knowledge sharing fail
After that, we will explore some solutions and their impact on reducing business risk:
How Pair Programming can reduce the damage when critical members leave
How Mob Programming extends on Pair Programming to further reduce risk
Key Lesson: Build 10X teams, 10X systems, rather than competing for 10X developers.
Commentary & Discussion
In this story, we saw how the 10x developer led the company to lose its biggest customer.
But is it the fault of the 10x developer? Why did they say “yes“ to all the piling tasks until they burnt out, is it their fault why didn’t they distribute their knowledge? Are they “guilty“ because no one could maintain the core module aside from themselves?
This is where I found the comment by Huseyin Caglayan very insightful:
Perhaps the company would not have gained the customer if it was not thanks to the 10x developer.
It is not the fault of the 10x developer if the organisation failed to support him and failed to retain other engineers who could take over.
Indeed, a startup's early success depends on some brilliant 10x all-rounder who can deliver fast. Initially, it’s great, but it’s not sustainable.
In this story, we see a major organizational problem. The organization continued to just rely on the 10x developer without doing anything to solve the organizational risk.
Even though this story goes to the worst-case burnout scenario, the organizational risk is faced even when the 10x developer goes on vacation (thanks, Georges DEFO, for your insightful comment about that!)
Our focus in this article is just one risk regarding 10x developers - the risk of knowledge centralization, the risk that they become the gatekeepers to the heart of your system, and no one can maintain the system without them. But there’s generally (often) another negative - the risk that they bring down the team performance; thanks to Alexander Pushkarev for his comment:
Another risk of 10x developers is the impact on team morale. Usually 10x Devs don't work well together, so it's either one or two 10x in a team intimidating and demotivating the whole team.
A story about Tom - the 10X developer
Tom was a superstar developer, the 10X developer (or even more). Here I mean 10X in the full sense, so not just technically superior but an all-rounder top performer.
Tom was able to implement features much faster than anyone else. He knew the whole system inside-out. He could also fix production bugs quickly.
He was the most dedicated developer in the company. Everyone trusted him; you knew you could rely on him.
When he “committed“ to something, it would get done, no matter what.