Your Senior Engineer Quit. Now What?

TL;DR: The notice period is a knowledge-transfer budget with a hard deadline, and most teams spend it on a farewell lunch and a wiki page nobody will read. The plan that works: map what the leaver actually owned from git history, rank those areas by blast radius, then spend every remaining day pairing on the top of the list and writing down only the "whys" that live nowhere else. Research puts a third of studied codebases one departure from a stall. This is the fortnight that decides whether yours is one of them.

The resignation lands on a Tuesday. By Wednesday, three things are true: everyone is being very professional about it, someone has scheduled a "knowledge transfer" meeting with no agenda, and the quiet question in every planning thread is who's picking up payments?

The math is uncomfortable. Avelino et al. (2016) measured truck factors across 133 popular GitHub systems and found 34% at exactly 1, one person's departure away from orphaned code. Those are thriving open-source projects. If your senior engineer was the kind everyone routed questions to, the odds that some part of your system just went from bus factor 1 to bus factor 0 are not small. What happens in the next two weeks decides whether that's a bruise or a fracture.

Step 1: Map what they actually owned

Not what the org chart says. Not what they remember to mention. What git history shows.

Pull the last 12 months and list every area where the leaver authored or reviewed most of the meaningful changes. The honest weighting method (authorship, not raw commit counts) is the same one used in calculating bus factor, and it matters here: the person who typed the most lines in a directory isn't always its real owner, and a senior engineer often owns areas mostly through review, holding context on code they never typed.

Then add the layer git can't show: the operational ownership. Which duties always routed to them? Deploys, migrations, the flaky vendor integration, being first responder when a particular service pages. Ask the team, not the leaver: "what would you have asked them next?" surfaces the real map faster than any handover template.

What you now have is their section of the ownership map - the list of areas that were key-person risk yesterday and are orphan candidates today.

Step 2: Rank the orphans by blast radius

You cannot transfer a decade of context in ten working days, so stop pretending the handover doc will hold it. Rank instead. For each area on the map, two questions:

• What stalls if this goes dark? Money paths, deploy tooling, and anything in the critical path rank first. The internal tool nobody's touched since 2024 ranks last.
• How actively is it changing? Hot areas will force the knowledge question within weeks; dormant ones give you months of grace.

Hot and critical goes in the notice period. Critical but dormant gets a runbook. Everything else gets explicitly - write it down - accepted as a loss. An honest short list beats a fiction that covers everything. This is the same triage you'd run on any bus-factor-1 inventory; the departure just picked the deadline for you.

Step 3: Spend the notice period on transfer that sticks

The default - the leaver writes documentation alone at their desk - is the worst use of the time. You're asking someone whose motivation has already left the building to guess what future strangers will need, in prose, unverified. Some of it will be useful. Most of it will join the documentation nobody reads.

What sticks, in order:

1. Pair on live work in the critical areas. Route the current tickets in the top-ranked areas to their successor, with the leaver reviewing or navigating. Real tasks surface the real gotchas: the config nobody mentions, the test that must run locally, the deploy step that isn't in the script.
2. Swap review duties now, not on the last day. Reviews are one of the strongest knowledge-transfer mechanisms a team has: Bacchelli and Bird's study at Microsoft found that while finding defects is the top stated motivation for code review, the actual outcomes lean toward knowledge transfer and team awareness. Put the successor on every PR in the area today, with the leaver as second reviewer while that's still possible.
3. Record the "why" walkthrough. One or two hours of the leaver narrating each critical area: why it's built this way, what they'd change, what breaks and how they fix it, which alerts are noise. Record it. Imperfect and searchable beats polished and never written.
4. Runbooks for the operational duties only. Skip the architecture essays. Write the deploy steps, the incident checklist, the vendor contact, the backfill warnings. Short, close to the code, verified by having the successor run one while the leaver watches.

Step 4: After they're gone, watch the queues

The knowledge gap shows up in the work, not in a survey. Watch the orphaned areas for the telltales: PRs waiting because no one feels qualified to approve, estimates ballooning, questions in chat going unanswered. In the 2024 Stack Overflow Developer Survey, 61% of developers reported spending over 30 minutes a day searching for answers. Expect that number to spike locally in the areas you just lost, and treat the spike as your signal for where the transfer didn't take.

If a successor is inheriting the area cold, treat it as onboarding, because it is one. The route in through review rotation and deliberately assigned tickets is covered in knowledge transfer for engineering teams and onboarding time to productivity.

Step 5: Make the next one boring

The real lesson of a scramble is that it was scheduled by someone else. The two-week panic only exists because the ownership map was invisible until a resignation rendered it. Every departure at a well-instrumented org is just a plan being executed a little early.

That means measuring continuously: which areas are single-owned, how critical, trending which way. It's the difference between "who's picking up payments?" asked in a crisis and answered calmly in a planning meeting six months prior. A continuously computed ownership and bus-factor map is exactly what Busfactor's knowledge view builds from the git history you already have, so the next departure triggers a plan you already wrote.

One more thing, because it needs saying: the engineer who just quit is not the problem. They said yes to the hard areas for years while the system happily concentrated everything on them. The problem is the system that never noticed. Fix that one.