Succession and single points of failure

You are looking at one engineer on your team you cannot afford to lose.

You cannot ask them to take a real two weeks off without rearranging the next quarter. You cannot give them honest feedback when they dip, because doing so would slow the team before any improvement showed up. You cannot rotate them to the new platform you are building, because you need them on the old one. You cannot promote them out of operational ownership of a system nobody else can run.

You made these staffing decisions eighteen months ago, and you never revisited them.

Sometimes the dependency is a cluster instead of a person. On platform teams, the most common shape I see is a service built by three senior engineers over a few years, sitting on top of a junior-heavy team with no real second tier. You count seniors and tell yourself the team is deep, but those three share every critical piece of context between them, so losing any one of them halves the platform's velocity, and losing two would leave the team unable to ship at all.

Both shapes get the same name, bus factor, and they attract the same standard remedies: pair more, review more, write more docs, rotate on-call. None of that is wrong, but all of it is work the team can do to itself, and it skips the decisions only the leader holds.

Succession in engineering is a constraint you hold at every staffing decision, rather than a ceremony you schedule or a rotation tax you pay. You read the map of single points of failure (SPOFs) and dissolve them through deputization, before the team pays for the gap in burnout or in a hiring scramble after someone leaves.

Read the map every staffing decision

You update the SPOF map every time:

• Someone joins.
• They leave.
• You promote someone.
• You assign a project.
• A system goes from "experiment" to "central piece of infrastructure".

What you are watching:

• Who answers the questions in the team channel about a given system.
• Who owns the on-call rotations nobody volunteered for.
• Where juniors actually get blocked, which is rarely where they say they get blocked.
• Who is in every incident review.
• Who reviewers default to when the change is non-trivial.

Counting heads at a level tells you very little compared with reading how the knowledge is spread across them. On paper, a team of one staff engineer and five juniors looks almost the same as a team of two staff and four juniors. The first is a single point of failure with five witnesses. The second can lose a person and keep moving.

Triage; do not chase every SPOF

You pay a tax for every redundancy you stage:

• Slower features.
• The deputy's time off their own work.
• The SPOF's time spent reviewing instead of building.
• Your time spent designing the transfer.

You cannot afford that tax on every system, so you pick. Three filters:

• Blast radius. What breaks, for whom, on what timescale, if this person goes.
• Cost of redundancy. How hard it is to grow a second on this surface, in months and budget.
• Time pressure. How soon they are leaving, burning out, or being pulled to a new role.

Stage two people on every critical surface and accept a single owner on the rest. Name the gaps you cannot close, because the trouble starts when you stop seeing them rather than when you leave them open.

Sometimes you split the territory instead of staging a deputy. It works when the system has natural seams: two engineers each owning one half gives you real redundancy on the smaller halves, and an honest SPOF on each. Sometimes that is the cheaper shape.

Dissolve through deputization

Docs help, but they are not redundancy. Reading a runbook and running the system in production are different skills, and a team where the docs are good but only one person has run the system in production still has a SPOF on operations.

You cure SPOF status through deputization: pick the second-most-senior person on the surface and start handing them critical pieces of the SPOF's work, with the deputy on the keyboard and the SPOF pulled back to reviewing. It has to be real problems in production, because workshops and scheduled pairing sessions are not enough.

The team's speed dips during the handoff, and you pay that dip on purpose, because nothing else dissolves the SPOF status.

Stage rockstars and superstars differently

Not every SPOF wants the same outcome. Kim Scott's rockstar and superstar distinction is the cleanest way I know to read this.

Some senior engineers are on a gradual trajectory: they want to be central to their current role, paid well, and left alone to do excellent work, and they are not asking to be promoted out. These are the rockstars. For this kind of SPOF you build redundancy around them, so they stay the rock and the deputy is insurance rather than succession.

Others are on a steep trajectory. They will be asking for more in twelve months and will leave if they do not get it. These are the superstars. For this kind you build redundancy out of them, where the deputy is succession and your job is to free them to move up.

The mechanic is identical and the intent is opposite. Confuse the two and you signal "I am replacing you" to the rock who wanted to stay, or "I am locking you in" to the climber who wanted to move.

Break the maintenance trap deliberately

By default, the engineer who built the system gets the maintenance. They know it best, incidents triage faster when they respond, and reviews are more reliable when they handle them, so every quarter the on-call paging tree, the deprecation cleanups, the dependency upgrades, and the migration consolidations all flow to them. Each of those routing decisions is locally correct, which is what keeps the trap stable: nobody had to make a bad call to build it.

And because they are the SPOF, they never get the room to automate the maintenance away. The maintenance burns them out and locks them out of new work at the same time. Engineers describe this as the irreplaceable-engineer career trap; a leader should describe it as a redundancy failure they are responsible for fixing.

Three live options:

• Sponsor protected automation time on the calendar, instead of "when there is a gap".
• Hand a chunk of maintenance to a deputy, accepting the dip.
• Rotate the SPOF off the system entirely once the deputy carries it.

There is a fourth option, which is doing nothing, and it resolves over time into burning them out.

Resist the over-hire reflex

Hiring does not give you redundancy. Adding a person to a team with a SPOF gives you a person, and you build redundancy by transferring knowledge; a new hire only sets up the transfer, which you may not need to set up yet. The reflex persists anyway, because opening a req looks like managing the risk, while staging a knowledge transfer looks, from the outside, like nothing happening.

Before you open a req against a SPOF risk, name two things: which existing engineer is going to teach the new hire, and which critical piece of work the new hire is going to absorb. If neither has an answer, you are buying low-output insurance, and you will be paying the salary for a year while the SPOF status stays exactly where it was.

Pre-bake the cascade before it lands

When a SPOF leaves a small team, you take two hits at once. First the bandwidth gap: the work they did, now distributed across the people who could not do it. Then the hiring drain: weeks of sourcing, screening, looping, and closing a strong replacement for a critical role, which is time you are no longer spending unblocking the team. The team slows on a multiplier.

Pre-baking means you started before you knew the date:

• A deputy who is already absorbing the day-to-day running of the system, rather than a deputy who would have started learning if there had been time.
• A structured handoff plan, rather than a brain dump after notice.
• A buffer week with no new work scheduled.
• An explicit conversation with stakeholders that says "we will be slow for six weeks" before the slowness shows up as missed commitments.

Refuse to bend the performance bar

The repair loop is the conversation you have with someone whose performance is dipping: honest feedback, a clear set of changes, a time horizon, follow-through.

When that person is a SPOF, you bend the loop. The feedback softens, the horizon stretches, and the follow-through dilutes into "let us see how next quarter goes". You can run the soft version for six months without noticing you are running it.

You did not bend it out of weak conviction or weak character. Running the loop honestly means accepting that the person might leave, or be parted out, at the end of it, and that loss would crater the team's velocity in a way you cannot survive this quarter. You bent the loop because you never built the redundancy that would have let you keep it honest.

You cannot fix this inside the repair loop itself. Build the deputy upstream, and the honest version of the loop becomes affordable again.

Be honest about leader-as-SPOF

The hardest SPOF to see is your own. If every non-trivial decision routes through you, you are the SPOF on judgment. The decisions:

• What gets prioritized.
• Who is on what.
• When to escalate.
• What "good" looks like on a review.
• When a customer concern is a blocker.

The team will tell you they are fast, and they will be fast on small things, but anything that needs a call waits for you, and a week of leave from you pauses the team.

Calling for more delegation does not cure this. Write down the rules of thumb you use to make calls. Write decision records when you make non-obvious choices, with the reasoning, so people can run the next call on similar ground without you. Then, deliberately, force the team to make calls without you in the room.

You will sit through calls you would have made differently, and staying quiet through them is the cost of dissolving this SPOF, which is easier to write than to do.

When SPOFs are the right call

Every redundancy you stage costs you something: you slow the SPOF down during the transfer, you spend a week writing heuristics before you see any return, and you carry the SPOF map in the back of your head, where it does not switch off just because a quarter feels stable.

You do not dissolve every SPOF. Some systems are sunsetting in two quarters, and growing a second owner on one of those is wasted work. Some prototypes have a single owner because they should; stage redundancy only after the prototype survives contact with users.

So most quarters end with open gaps still on the map, and that is the working state of this exercise: a short list of named risks you decided you could carry, and nothing on it you would be learning about for the first time from a resignation email.