The two weeks after your last expert on a service resigns

Not with a documentation sprint. Spend the notice period extracting the decisions still held in one head, in the order a successor needs them, and accept that some will not come out. In a codebase agents wrote, Backthread keeps that reasoning per area of the system as changes merge, so it does not wait on a resignation.

What follows assumes the worst version: one service, one person who holds it, two weeks, and no named successor yet. Stretch it if you have longer. Do not reorder it.

Why the documentation sprint is the wrong instinct

Asked to write down what they know, a departing engineer produces a description of the system. Descriptions are the cheap half: reconstructable later from the code, slowly and annoyingly, but reconstructable.

What cannot be reconstructed is the set of choices that could have gone the other way — the alternative that was rejected, the trade-off accepted on purpose, the assumption the service makes about a neighbour that nobody wrote down. None of that is recoverable from the artefact, because the artefact only records the branch that was taken. Spend the fortnight on the irreversible half.

There is a second reason, specific to code agents wrote. The reasoning you are hunting may not exist in anyone's head either. On our own repository, of 4,302 decisions captured from agent sessions, only 1,613 carry any recorded deliberation, so 62 percent record no alternative and no trade-off. Where a change was cheap and reversible, nothing was weighed, and a leaver cannot hand over a rationale that never formed. Knowing which parts are like that is itself worth extracting.

Week one: the things only they can give you

Time-box each session. A departing engineer has about six useful hours of this per week, and twelve one-hour interrogations produce less than four well-aimed ones.

1. The map, drawn by hand, in one hour. Boxes and arrows, top level only, on a call that is recorded. Ask them to mark the two or three boundaries they do not trust. Those marks are the most valuable artefact of the whole two weeks and they will never appear in a document written to be thorough.
2. The five decisions they would defend in a review. Ninety minutes. Not the five biggest changes. The five choices where a competent engineer would have done something else, and they had a reason. Write the rejected alternative down next to each one; without it the entry is a description again.
3. The trade-offs taken knowingly. Sixty minutes. The shape is "we do X, knowing Y, because Z was out of scope". Prompt with symptoms: what gets slow first, what breaks when a dependency is down, what they would not put behind this.
4. What the service assumes about its neighbours. Sixty minutes. Ordering, idempotency, who owns the write, staleness tolerance, who is allowed to call what. These assumptions are the usual cause of an incident six weeks after a handover, because the breaking change lands in a different team's code.
5. The incident list, with the diagnosis each time. Sixty minutes. Not the postmortems — the ones that never got written up. Ask what has woken them and what they checked first. The order they check things in is a compressed model of the whole service.
6. What they would not touch, and what they have been meaning to fix. Thirty minutes. Both lists. The first is where the landmines are; the second is the roadmap nobody else has.
7. The names. Thirty minutes. Who they ask when stuck, in which team, about which part. A handover that transfers no relationships transfers half the job.

Record and transcribe every session, and put the transcripts in the repository next to the service, not in a wiki space the successor will never find.

Week two: the part the team does, not the leaver

The second week is for turning testimony into something that survives. The leaver's role here is to answer questions, not to produce.

• Route every pull request in that area to the least knowledgeable available engineer, with the leaver as second reviewer. It is the only knowledge transfer that costs no extra meetings, and you have about eight working days of it left.
• Have the successor make one real change, end to end, while the leaver is still reachable. One shipped change teaches more than the seven sessions above. Pick something small and genuinely needed, not a training exercise.
• Turn each decision from day two into a question with a known answer. "Why does this write go through the queue rather than directly" is a question you can put to the next three engineers who touch the area, and the ones who cannot answer it are the gap.
• Write the assumptions down as assertions where you can. An assumption about ordering or idempotency that can be a test should become one this week, while someone can still confirm it is right.
• Name the gaps in writing and accept them. A list of five things nobody now understands is a usable artefact. A claim of full coverage is not, and it stops anyone looking.

What you cannot extract

Two things, and pretending otherwise is how handovers fail quietly.

Judgement about this specific system. The leaver's instinct for which change is risky is built from hundreds of small observations they cannot enumerate on request. You can get the conclusions out of them. You cannot get the function that produced them, and a successor will rebuild it over months of touching the code, or not at all.

Reasoning that was never formed. Covered above, and worth repeating because it is counterintuitive: for a large share of agent-written changes there is no withheld explanation. Asking harder produces a plausible reconstruction, which is worse than a blank, because a confident wrong rationale gets believed and acted on. Let the blanks be blank and mark them as such.

Three things not to spend the two weeks on

• A written architecture overview. It describes the system as understood on the day it was typed, and it ages from that day forward. The hand-drawn map with the untrusted boundaries marked is worth more and takes an hour.
• Runbooks for failures that have never happened. Document what has actually woken someone. The rest is fiction in numbered steps.
• Recorded code walkthroughs. Nobody watches a four-hour screen recording. The code survives their leaving; the reasoning does not.

The structural point is that none of this is really about resignations. A team that waits for a notice period to find out who understands an area is finding out at the worst moment, and when agents write most of the changes, the authorship record stops being a proxy for understanding at all — a merged pull request is not evidence that anyone understood it. Keeping that picture current while people are still there is what Backthread is for, and the two-week version above is what you run when nobody did.

Connect one repo and you get the first honest picture of which parts of your system each person still holds, usually the same day; the trial runs fourteen days.