Managing the indispensable engineer
Having a strong engineer who owns a critical system feels like an advantage, but it hurts their career and your team's resilience.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
To accelerate your growth see:
Get Hired as an EM (CV & job search to actually get interviews)
AI Behavioral Interview Coach (the best prep for your interviews)
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
Having a strong engineer who owns a critical system feels like an advantage, but it hurts their career and your team’s resilience.
Most teams I’ve inherited has had one. The engineer who knows the payment system end to end, or the legacy ingestion pipeline, or the gnarly auth flow nobody else has touched in three years. They answer every question about it on Slack within minutes. They’re on every related incident. When a stakeholder asks how long a change will take, you ask them, because nobody else can give you a useful answer.
It feels like a strength. I think that it isn’t.
This usually starts for a good reason. Someone spends more time in an area, gets context others don’t have, and naturally becomes the go-to person. But over time, that convenience turns into dependency. And the cost is carried by that engineer, who gets stuck there, and by the team, which can’t operate without them.
What concentration actually costs you
A simple way to visualise the cost is to imagine that engineer leaves tomorrow. Not as a dramatic exercise, but as a planning question: who will pick up which parts of what they own, and how long will it take them to get there?
If the answer is “we’d be in trouble for six months,” you’re probably in trouble. Your tech lead resigning shouldn’t be a crisis. If it is, the crisis was already there.
Rigby and colleagues studied this using source-code history from Google Chrome and an Avaya project. They treated abandoned source files as a signal of knowledge loss: parts of the codebase where most of the line-level ownership belonged to developers who had left. Their findings showed that these files were rarely picked up by brand-new developers. At Avaya, 81% of abandoned files were taken over by engineers with at least a year of project experience. In Chrome, only 16% were adopted by newcomers in their first quarter.
The implication is that when your indispensable engineer leaves, you can’t replace them by hiring someone new. You load the work onto the next most-experienced person on the team, and over time become the indispensable one.
Will Larson, writing about incident heroes, describes a pattern most managers will recognise: a few long-tenured engineers, who have the access and the implicit permission to use it, end up responding to almost every incident. Their teammates stop developing the muscle, because they don’t get the reps. Over time, the people who could be capable on this system aren’t, because the indispensable engineer always gets there first.
The expert isn’t the problem. The fact that no other person ever gets to learn what the expert knows is the problem.
Why this pattern keeps surviving
Before getting to what to do, it’s worth being honest about why this pattern is so sticky. If it were obviously bad, good managers would fix it. The reason they don’t is that concentrated ownership genuinely produces some good outcomes in the short term.
A very popular Microsoft Research paper by Bird and colleagues found that components with higher concentration of ownership had fewer pre-release faults and fewer post-release failures than components with many minor contributors. Strong ownership produces better code in the short run.
So when you rely on your indispensable engineer to deliver features more than other engineers because they produce more bugs in this area, you’re optimising for code quality. The thing is that you’re doing it on a timescale that ignores the fragility you’re accumulating, and the cost to the engineer that I’ll get to in the next section.
We need to separate two things that look identical and aren’t.
There’s concentration as strategy: a small team owning a bounded, complicated subsystem with documented interfaces, on purpose, with a succession plan.
And there’s concentration as accident: one person who happens to have been there longest, owning a system nobody scoped or budgeted for them to own, with no plan for what happens when they leave.
The first is what Team Topologies calls a complicated-subsystem team, and it’s a defensible choice. The second is what most teams have, and it isn’t.
One more thing worth thinking about is “we don’t have time to onboard others to this system”. That way of thinking has weakened considerably. Meta recently used AI agents to systematically extract tribal knowledge from a four-repo, three-language, 4,100-file codebase, taking context coverage from 5% to 100%. You don’t have Meta’s engineering investment, but you have access to versions of those tools, and the time cost of producing onboarding-quality documentation has dropped a lot over the last 18 months.
What it feels like to be the one
The part most articles on this topic skip is that the engineer in the role usually isn’t enjoying it.
Charity Majors wrote an article directly to engineers in this position, and it’s worth reading as a manager. Her core observation is that what looks like a personal complaint, “I don’t want to be on call any more, I’m tired, I’m the only one who knows this” is almost always an organisational problem. Bus-factor problems, a single person owning a component for too long, insufficient rotation coverage: these are issues of resource allocation and risk.
There are three costs to the engineer:
Their scope stops growing. They can’t take on bigger problems because the existing system needs them. Every quarter that passes is one in which their range narrows, even as their tenure increases.
They become structurally hard to promote. Promotions happen when the business needs a role filled, and the business doesn’t need them in a different role; it needs them exactly where they are. I’ve written before about why senior engineers don’t get to Staff+: when your local indispensability is the most valuable thing about you, the org will not let you become more valuable somewhere else.
They start to resent the team. The engineer is praised constantly and advanced rarely. Teammates ask them the same questions repeatedly. They watch peers with less knowledge get more interesting work, because those peers are easier to move.
What you can do as a manager about it
You can’t fix this in a sprint. You can start it in a planning cycle. Three moves I’d recommend, in roughly this order.
Make ownership a team property, not a person property. Pick the most concentrated system on your team. Assign two or three engineers as named owners, with the current expert as one of them. From now on, code review on that system requires one of the named owners, but the expert is one option, not the only option. This is the single biggest move from Team Topologies that I’ve seen teams get wrong: they keep ownership at the individual level and call it a team.
Change the incentive on incidents. Ask your most senior responders to delay responding when they’re not on call, so other engineers get to attempt it first. Pair this with a change to your promotion criteria: senior engineers should be rewarded for running rotations that succeed without them, not for resolving every incident. If your levels framework rewards heroism, you’ll keep getting it.
Set a transfer plan with a deadline. Pick one part of the system every quarter. The expert and a partner work through it together. Get the partner to a point where they can make a non-trivial change without having to ask questions. This works because the scarce thing isn’t usually getting context, it’s developing judgement and the trust to apply it.
The thing I’d push back on is the temptation to solve this problem by spreading everything across everyone. That’s the opposite mistake. You’ll end up with a team where nobody owns anything. The goal is two or three deeply involved owners per critical system, not 12 people who all kind of know it.
I have explored these ideas in the EM Field Guide with more detail because this is one of the patterns I keep seeing managers walk into and not know how to walk out of.
Closing
That “indispensable” engineer isn’t exceptional by accident. They’re the outcome of a pattern reinforced over time. And although it may have worked, it also created fragility, and it boxed one person into a role that limits their growth and, over time, their motivation.
The good news is you don’t have to fix it dramatically. You have to start by picking one system this quarter, assign it a couple of people, and aim to move the expert on to something different, and give somebody else the chance to grow into the one they’ve been guarding.
If you enjoyed this article, consider subscribing to get:
✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide
You might also like some of my most popular posts:
See you in the next one,
~ Stephane
I was expecting a different article! Indispensable engineers in my experience are the critical thinkers and inventors. The one's who really understand physics, chemistry, and how things work. They know how a magnet can be created out of different materials. Coding and systems will be replaced by AI. These brilliant minds not so easy!