Your release owner goes on holiday for two weeks. On day two a deploy fails, and nobody knows which config flag she always flips by hand. The team waits. Work stacks up. Someone eventually messages her on the beach.
If you lead an engineering team, you've probably seen some version of this. The instinct is to blame the absence, but the real problem is that knowledge, responsibility, or decisions have pooled in one place. That is a structural problem, and structure can be fixed.
A quick diagnostic: who on your team do you quietly hope never gets sick or quits? Whatever that person uniquely knows or controls is where to start.
1. Make ownership explicit
When ownership isn't explicit, knowledge and responsibility can easily concentrate in one person.
Make ownership visible across the team so everyone
understands who is responsible for each critical function and where their responsibilities begin and end.
This helps identify gaps and areas where too much responsibility sits on one individual.
Write down who owns each critical function.
A simple table is enough. You'll often see gaps and overloaded responsibilities.
More importantly, you'll see where a critical function depends on a single person. That's where to start.
2. Document context, not just steps
Document the work that the team would struggle to continue without. Instructions are not enough; the context should be transferred. People need to understand the decisions behind a process, important dependencies, potential risks, and where to find the information they need. Keep documentation focused on critical knowledge and review it regularly.
Not all dependencies are the same. A team can have three people who know the deployment procedure and still depend on one person to recognize an unusual failure or decide whether a rollback is safe. That is the difference between knowledge, authority, and judgment:
Each type of dependency needs a different fix. Documentation helps with knowledge. Delegation helps with authority. Pairing, rotation, incident reviews, and practice help develop judgment.
3. Decentralize decisions
Teams become fragile when every important decision has to go through one person. Give the team enough context and authority to make decisions within clear boundaries, for example, "anyone can roll back a release without asking," or "changes under X hours of effort need no approval." Keep a lightweight decision log so the reasoning stays visible. People develop judgment by making decisions within clear boundaries, seeing the consequences, and learning from them.
4. Pair a primary owner with a secondary
For each critical function, name two people. The secondary should have the access, context, and decision authority needed to take over, and should actually perform the work sometimes, for instance by rotating who runs the release each month. Pairing and shadowing during normal weeks, not just before someone leaves, surfaces undocumented steps and hidden dependencies naturally.
5. Test it
A backup plan that has never been tested is only an assumption. Run a small game day: pick one function, have the secondary owner handle it while the primary is offline for a day. Note where they got stuck, whether a permission was missing, or whether the docs were wrong. Fix those things, then pick the next function.
What it costs
Pairing slows work down at first, and some duplicated effort is the price of resilience. Spread ownership too thin and you get ambiguity instead of safety. You won't remove every single point of failure, so start with the functions where an absence would hurt most and reduce the risk there.
Why it happens in the first place
Managers are responsible for building team resilience, but culture can reinforce the opposite. Teams often reward the person who always saves the day, while documentation, teaching, and delegation get less attention. Over time, being indispensable can become more valuable than making the team less dependent. Recognize and reward people who share knowledge, develop others, and make critical work easier to hand off. That's how you build a team that can keep moving when someone is away.
A note on AI
It's tempting to build an AI version of your key person, but if the team still depends on one person's knowledge, decisions, or judgment, you've moved the dependency rather than removed it. AI can make shared knowledge easier to find, explain, and use. But it works best when that knowledge is already accessible to the team. Fix the underlying dependency first; then use AI to make the team's shared knowledge more useful.
The bottom line
If your team can't function without one particular person, treat it as a systems problem. Ask where knowledge, responsibility, or decision-making is too concentrated, and spread it out. That is how teams keep moving when someone is unavailable.
Further reading
Operation Resilience
Job Shadowing
Pair work