Succession Planning for Engineers (Yes, Engineers Too)

TL;DR: Your board would never accept "we have no plan if the CFO leaves." Your codebase runs on exactly that plan, times every critical area with one owner. Succession planning for engineers is the boring governance fix: inventory the critical areas from git history, name an owner and a successor for each, keep the successor genuinely warm with one real ticket per sprint plus a review seat, and re-check quarterly. Not because engineers are executives, but because the knowledge they hold is just as unbacked-up.

Ask your leadership team who takes over if the VP of Sales leaves, and someone produces a plan. HR has a document, a name, maybe a development track. Ask who takes over if the engineer who holds the payment system leaves, and you get the honest answer: a pause, a nervous laugh, and "well, probably Marek? Eventually?"

That asymmetry is backwards. The VP's knowledge largely exists in relationships and documents that survive them. The payments engineer may hold the only copy of how a critical system actually works. Avelino et al. (2016) found 34% of 133 popular GitHub systems had a truck factor of exactly 1, and about 65% sat at 2 or lower. Succession planning, the most standard tool in corporate governance, simply never gets applied to the people it would protect most. This article is the application.

What succession planning is (and isn't)

It is a standing, written answer to one question - who takes over if this person is unavailable? - for every critical area of the codebase. It is not a reorg, not shared ownership by decree, and not a judgment on anyone. If reducing bus factor is the toolbox (rotation, pairing, documentation, review policy), succession planning is the program that decides where to point the tools, names the people, and checks that the plan survives contact with each quarter.

And to be precise about the target: the plan protects areas. The unit of risk is the single point of failure, the critical system with one living owner, wherever it sits in the org chart.

Why not just dissolve ownership entirely?

Because the research cuts both ways, and honest planning respects both edges. Bird et al. (2011), studying Windows Vista and Windows 7, found that components with more low-expertise contributors had more pre-release faults and post-release failures, while a higher ownership share held by the top owner predicted fewer. Strong ownership is good for quality. It's only bad for continuity.

So the goal is not "everyone owns everything," which trades continuity risk for quality risk and delivers the worst of collective ownership done lazily. The goal is concentrated ownership with a designated second: keep the expert, cap the downside. One owner, one named successor, per critical area. That's the whole trick.

The program, in four steps

1. Inventory the critical areas

Start from evidence. Your git history already shows where authorship and review concentrate on one name. It's the same map you'd draw calculating bus factor, and the canonical example is the legacy system with one living interpreter. Filter to areas that are actually critical: money paths, deploy tooling, anything customer-facing under active change. A ten-line table beats a wall-sized matrix nobody maintains.

2. Name owner and successor, in writing

For each area: the current owner, the designated second, and the date the plan was last true. Naming matters: "the team backs it up" is how areas end up backed up by nobody. Pick successors for adjacency (they already touch the neighboring code) and for load (the obvious candidate for everything cannot be the successor for everything; that just moves the single point of failure one seat over).

3. Keep the successor warm

A name on a spreadsheet transfers nothing. Warm means working:

• One real ticket per sprint in the area, with the owner reviewing. Real work surfaces the landmines that walkthroughs skip.
• A standing review seat on the area's PRs. Code review is a knowledge pump - Bacchelli and Bird found its actual outcomes lean toward knowledge transfer and team awareness - and it runs on work the team is already doing.
• One drill per year: owner takes a real vacation, successor runs the area, gaps get written down. A successor who has never operated the system alone is a hypothesis, not a plan.

Budget it honestly: about one ticket per sprint plus review time is the premium. The uninsured alternative pays the same learning cost later, at crisis prices, with the expert gone. That's the two-week scramble this program exists to delete.

4. Review quarterly

Ownership drifts: people change teams, new systems concentrate, successors become owners elsewhere. A quarterly pass over the table - is each plan still true? - is an hour that keeps the document from becoming fiction. When a departure does land, the succession table is the first input to the offboarding checklist, and most of its boxes are already ticked.

What this is not

Succession planning names people, so say the quiet part clearly: the succession table is a coverage map, never a performance one. The engineer whose areas need successors isn't a liability to be managed out. They're usually the person who said yes to the hard systems for years while the org concentrated everything on them. The failure being fixed is the system's: it never noticed the concentration. Treat the person holding the risk as someone to protect: this is key-person risk, and the humane response is backup, not blame.

The door

Every quarter without a succession plan, the concentration compounds: the expert gets more expert, the gap gets wider, the eventual transfer gets more expensive. The inventory step is mechanical: a continuously computed ownership map showing which critical areas rest on one head is what Busfactor's knowledge view builds from the git history you already have. Your org already believes in succession planning; it wrote one for the CFO. Extend the same courtesy to the person carrying payments.