Software engineers have an almost superstitious fear of single points of failure.
We don't trust servers. We don't trust hard drives. We don't trust data centers. Given enough time and enough caffeine, we eventually stop trusting entire geographic regions. Every reasonably mature engineering organization has accumulated an entire vocabulary dedicated to the assumption that things fail. Replication. Redundancy. Failover. Disaster recovery. High availability. The words themselves are almost comforting because they imply that somewhere, someone has already imagined the disaster you're currently imagining.
This way of thinking eventually becomes instinct. If removing one machine can take down the system, the machine isn't the problem.
The design is.
Curiously, many of these same organizations have exactly one engineer who understands payroll. Or exactly one accountant who knows why a seemingly absurd spreadsheet formula has survived six CFOs and three ERP migrations. Or exactly one operations manager whose vacation requests produce the sort of silence usually associated with production outages.
Nobody treats this as a design flaw.
Quite the opposite.
We usually congratulate ourselves for hiring exceptional people.
Which is interesting, because "exceptional" and "indispensable" are not synonyms, even though organizations behave as if they were.
One describes the quality of a person. The other describes the fragility of a system. That distinction matters more than it first appears.
This isn't about me, before anyone mistakes the article for a public negotiation with my employer. I've been unusually fortunate throughout my career. Most of the opportunities I wanted eventually arrived, sometimes before I'd accumulated enough evidence that they should. But I've seen this pattern often enough, in enough organizations that had almost nothing else in common, that it eventually stopped looking like coincidence.
Something was being optimized. Just not the thing everyone assumed.
At first, I thought the explanation was the usual one. Maybe these people weren't advocating for themselves. Maybe they disliked office politics (who could blame them?). Maybe they had confused being excellent at their jobs with managing their careers.
Those explanations certainly account for some cases. They don't account for the interesting ones. The interesting ones are the people everybody agrees deserve to move. The people everyone trusts. The people everyone depends on. The people whose promotion somehow never quite becomes this quarter's priority.
It took me a while to realize that organizations don't merely discover these people.
They manufacture them.
How Organizations Manufacture Experts
Nobody sets out to build an organization full of indispensable people.
Or at least I hope they don't.
I've never seen a quarterly planning document that included an objective like, "Concentrate fifteen years of operational knowledge inside Craig's brain and make sure nobody else understands the payment system." If such organizations exist, they deserve whatever happens next.
What organizations actually optimize for is something much more reasonable.
Speed.
Imagine two engineers.
One solves a difficult production incident in three hours, spends another two documenting the failure mode, updates the runbook, automates part of the recovery process, and walks a junior engineer through what happened.
The other solves the same incident in three hours and immediately picks up the next ticket.
Which engineer appears more productive on Friday afternoon?
It's a trick question, because the answer depends entirely on when you stop measuring. Tomorrow, the second engineer almost certainly looks more productive. Six months later, the first engineer may have quietly eliminated dozens of interruptions that nobody will ever count because they never happened.
Organizations are notoriously good at measuring work that occurred. They're considerably worse at measuring work that permanently prevented other work from occurring.
The consequence is subtle. The fastest person gets the hardest ticket. The hardest tickets contain the rarest knowledge. Which means the fastest person accumulates even more knowledge. Which makes them the obvious choice for the next difficult ticket.
What begins as a perfectly rational allocation of work gradually becomes a feedback loop.
Expertise attracts opportunities to become even more expert.
Meanwhile, everyone else becomes progressively less qualified to help because they never receive the work that would let them catch up.
The organization interprets this widening gap as evidence that it made the right decisions all along. In reality, it may simply be observing the consequences of those decisions.
This is one of the peculiar properties of positive feedback loops. Once they're established, they become excellent at producing evidence that they should continue existing.
By the time someone is described as "the only person who understands this system," the organization usually treats that fact as though it were a remarkable achievement.
More often, it's a historical record.
It's the accumulated result of hundreds of individually sensible decisions, each one made under the entirely reasonable assumption that the fastest person should probably handle the hardest problem.
None of those decisions were wrong, but, collectively, they built exactly the dependency everyone now claims to regret.
Why Promotions Become Expensive
By this point, the organization has accidentally created an accounting problem.
Not a financial one. An informational one.
Years of decisions have quietly transformed one employee from "someone who knows the system" into "part of the system." That's an important distinction. Expertise is an asset. Dependency is a liability. The frustrating thing is that, from a distance, they often look identical.
This is one of those situations where language quietly betrays us.
When someone says, "Sarah is critical to the business," what exactly do they mean? Do they mean Sarah consistently creates extraordinary value? Or do they mean the business has become unusually vulnerable to Sarah's absence?
Those are radically different statements masquerading as the same compliment.
The first describes a person. The second describes an organizational weakness.
Unfortunately, organizations often discover which one they meant only after Sarah resigns. Or gets promoted. Or burn out. Or decides to spend two uninterrupted weeks somewhere without Wi-Fi.
This is why promotions become strangely complicated.
People like to imagine promotions as rewards, as though organizations maintained an invisible scoreboard and eventually handed out titles once enough points had been accumulated.
Operationally, promotions are something else entirely. They're subtraction.
Every promotion removes someone from the role in which they've become most valuable.
The organization now faces a choice it has spent years postponing.
Someone else has to acquire that knowledge. Someone else has to inherit those responsibilities. Someone else has to make decisions without fifteen years of accumulated intuition whispering in the background.
Notice how none of these costs appear on the promotion letter.
The salary increase is hopefully visible. The vacancy isn't. The title is visible. The years required for somebody else to become equally effective are not.
Perhaps that's why organizations so often underestimate the cost of creating dependencies while simultaneously overestimating the cost of breaking them.
Because one appears on a spreadsheet. The other doesn't.
And organizations, like all of us, have a tendency to confuse what is measurable with what is important.
Which brings us to a rather uncomfortable irony.
The very employee who appears to have earned a promotion beyond any reasonable doubt has also become the employee the organization can least afford to lose.
Not because they lack potential. Because they've accumulated too much value in exactly the wrong place.
Inside their current role.
A Theory That Accidentally Explains Something Else
One of the charming things about academic research is that it occasionally solves problems it wasn't trying to solve.
Take the phrase competency trap.
It's now floating around LinkedIn and management blogs as shorthand for "being too good at your job to get promoted." That's not actually what the people who coined the term meant.
Originally, the competency trap described organizations.
Imagine a company that discovers a process that works reasonably well. Because it works, the company invests more time refining it. Because it invests more time refining it, the process becomes even more efficient. Eventually the organization becomes so practiced at doing one thing that trying something else feels irrational, even when something else might ultimately be better.
Success creates inertia.
The trap isn't incompetence. The trap is becoming so competent at today's solution that tomorrow's solution never gets a chance.
The delightful irony is that this wasn't supposed to describe careers at all.
Yet the metaphor escaped.
Replace "process" with "employee" and the mechanism barely changes. The organization discovers someone exceptionally good at solving difficult problems. So it gives them more difficult problems. Which makes them even better at solving difficult problems. Which justifies giving them even more difficult problems.
By now the pattern should feel familiar.
The employee isn't trapped because they're indispensable. They're indispensable because the organization keeps reinforcing the same behavior that made them valuable in the first place.
Then there's the Peter Principle, which somehow manages to describe the mirror image of the same phenomenon.
The Peter Principle argues that organizations promote people because they're good at today's job until they eventually reach tomorrow's job, where those same skills no longer predict success. The best salesperson becomes a mediocre sales manager. The brilliant software engineer becomes an exhausted engineering manager who now spends Tuesday afternoons discussing quarterly hiring forecasts instead of writing software.
Interestingly, there's good empirical evidence that organizations really do promote this way. Researchers studying tens of thousands of employees found that companies systematically favored current performance over observable indicators of future managerial ability. Put differently, organizations often promote the person who's best at today's work instead of the person who's best suited for tomorrow's work.
At first glance, that seems like the exact opposite of the phenomenon we've been discussing.
It's not.
It's the same mistake wearing different clothes.
Sometimes organizations promote the highest performer because they're measuring the wrong thing. Sometimes they refuse to promote the highest performer because they're measuring the wrong thing.
The outcomes are opposite. The logic is identical.
In both cases, today's performance becomes a poor proxy for tomorrow's contribution.
Which raises an uncomfortable possibility.
Perhaps promotions fail for the same reason many systems fail.
Not because the people involved are irrational. Because they're optimizing the wrong variable.
Organizations That Don't Need Heroes
Every engineer has experienced some version of this conversation.
"Don't worry. Only John knows how this works."
It's usually intended as reassurance. It should have exactly the opposite effect.
One of the stranger cultural quirks in software is that we celebrate heroics while simultaneously insisting we don't want heroes.
Postmortems are full of statements like, "The incident was resolved quickly thanks to Alice's deep knowledge of the system." Everyone nods approvingly because Alice just saved the day.
Then, somewhere near the bottom of the document, usually under "Action Items," someone quietly writes, "Reduce dependency on tribal knowledge."
It's an odd contradiction.
We applaud the hero. Then we assign someone the task of making sure the hero is never needed again.
The second objective is the correct one.
Engineering has understood this for decades.
Reliable systems aren't built by hiring mythical engineers who never make mistakes. They're built by assuming ordinary engineers will eventually make every imaginable mistake, then designing systems that continue functioning anyway.
Organizations deserve the same humility.
A healthy engineering organization shouldn't ask whether it has talented people.
That's table stakes.
It should ask a much more uncomfortable question. If one of our best people disappeared for three months or give up their job to pursue a career as a monk, would we lose velocity? Or would we lose the ability to operate?
Those are completely different failures.
The first is unavoidable. The second is optional.
The organizations I've admired most all shared a habit that initially looked inefficient. They treated knowledge as something that depreciated if it wasn't copied. Senior engineers weren't expected merely to know things. They were expected to leave behind other people who knew them too.
Architecture decisions were written down, not because documentation is exciting, but because memory is a terrible persistence layer.
Ownership moved.
People rotated between systems.
Junior engineers were deliberately allowed to solve problems slowly that senior engineers could have solved immediately. From the perspective of this sprint, all of this looked wasteful. From the perspective of the next five years, it was probably the highest return on investment in the building.
The remarkable thing is that none of these organizations were trying to make promotions easier.
They were trying to make themselves harder to break. The promotions happened almost as a side effect.
That's the interesting inversion.
Most organizations think succession planning exists to support promotions.
I suspect promotions exist to test whether succession planning was real.
Escaping the Trap Without Becoming Less Valuable
If you've read this far and recognized yourself somewhere in the article, there's a temptation to draw exactly the wrong conclusion.
"I should stop being so useful."
That would be a mistake.
The problem was never becoming valuable. The problem was allowing your value to become inseparable from your presence.
There's a subtle transition that happens in almost every technical career, although not everyone notices it while it's happening.
Early on, you're paid to know things. Later, you're paid to improve things.
Eventually, if your career continues, you're paid to improve the organization's ability to improve things.
Those sound similar, but they're completely different jobs.
The first engineer answers questions. The second engineer changes systems so the same questions become less frequent. The third engineer changes the organization so more people can answer the questions.
Notice what disappeared. Knowledge didn't. Scarcity did.
This is why some engineers appear to accelerate almost effortlessly into staff, principal, or architecture roles while others plateau despite being equally intelligent.
The difference often isn't technical ability. It's where they choose to invest it.
One engineer spends ten years becoming the world's foremost expert on a particular subsystem. Another spends ten years making sure that subsystem gradually requires fewer experts.
One accumulates knowledge. The other converts knowledge into organizational capability.
The distinction is almost invisible when you're looking at today's sprint. Over several years, it becomes impossible to miss.
Practically speaking, this changes how you spend your time.
If you're still the person everyone interrupts for answers, you've solved today's problem. If people stop interrupting you because they already know the answer, you've solved tomorrow's.
If every difficult production incident still requires your personal attention, congratulations. You've become extremely good at firefighting.
If production incidents gradually stop requiring heroes because you changed the architecture, the tooling, the documentation, or the team's understanding, you've started operating at an entirely different level.
Organizations often describe seniority as the ability to solve harder problems.
I think that's incomplete.
Real seniority is reducing the number of hard problems that still require senior people.
There's a peculiar irony here.
The fastest way to become indispensable is to keep proving you're indispensable. The fastest way to become promotable is to keep making indispensability disappear.
Those sound contradictory.
In healthy organizations, they're almost the same thing.
The engineer who creates dependency scales linearly. The engineer who creates capability scales exponentially.
One becomes busier. The other becomes unnecessary.
Oddly enough, organizations usually end up paying much more for the second one.
The Load-Bearing Employee
There's a phrase engineers use that I find myself thinking about more often than I probably should.
Load-bearing.
A load-bearing wall isn't necessarily the most impressive wall in the building.
It isn't prettier. It isn't thicker. It isn't even the wall people notice.
It's simply the one whose removal causes the rest of the structure to reveal what it has secretly depended on all along.
Organizations produce load-bearing employees in exactly the same way.
Not through malice. Not through incompetence. Through thousands of perfectly sensible decisions.
Route the difficult problem to the person most likely to solve it. Ask the experienced engineer to review one more pull request. Delay documentation because the release is Friday. Skip the cross-training because everyone is already busy.
Repeat that process for five years and you've quietly embedded one human being into the structural integrity of the organization.
The remarkable part is that everyone involved was behaving rationally. Every individual decision improved efficiency. The system those decisions created did the opposite.
Economists have a name for this sort of thing. Local optimization producing global inefficiency.
Software engineers have another.
Technical debt.
The debt, in this case, isn't in the code.
It's in the org chart.
That's why I don't think this is ultimately an article about promotions.
Promotions merely expose the architecture that was already there.
Just as a server failure doesn't create a resilience problem. It reveals one. Just as deleting a database replica doesn't create a single point of failure. It reveals one.
The promotion isn't the event.
It's the stress test.
Healthy organizations don't pass that test because they have smarter managers or more talented employees. They pass because they've spent years designing themselves under the assumption that every important person will eventually leave their current role.
Sometimes they'll leave because they resign. Sometimes because they burn out. Sometimes because they retire.
If you're lucky, they'll leave because they grew.
That last possibility should never be the one your organization fears most. Because if promoting your best people feels dangerous, the promotion isn't the problem.
It's merely the first honest measurement of a design decision the organization has been making for years without realizing it.
The software industry likes to say that every system is perfectly designed to produce the results it produces. Organizations are no different.
If your highest performers become increasingly difficult to promote, perhaps the organization isn't failing to recognize talent. Perhaps it's producing exactly the kind of organization it was designed to produce.
That's a much harder problem.
It's also the right one.