Keep the knowledge when an engineer leaves

Knowledge loss when a developer leaves is mostly the loss of why: which approach was rejected, what the system quietly assumes, which part only works because of a workaround they remember. Code and docs survive; the reasoning does not. Backthread captures that reasoning from each agent session as changes merge, so the why behind the codebase outlives the person, and its coverage map shows the one-name areas before anyone hands in notice.

What actually leaves with the engineer?

Not the code. Not, usually, the runbooks. The three things that leave are narrower and harder to see than "tribal knowledge" suggests.

The rationale. In 2021 Martin Robillard interviewed 27 developers and managers across three companies about turnover-induced knowledge loss. The paper's clearest finding is that documentation, where it existed, rarely held the reasoning. One developer describes the aftermath of a colleague's departure as the team asking "What's the reason behind doing it in such way? So that reasoning here the person would have lost it and we would have to figure it out ourselves." Robillard files this under a known limit of knowledge externalisation: design rationale is "notoriously difficult" to write down, so it is the last thing that gets written and the first thing lost.

The map of what is fragile. Every engineer who has been in a codebase for a couple of years carries a private list of the parts that look fine and are not: the migration that must run in a particular order, the cache that is only correct because a cron job happens to run first. None of it is in a file, because writing "this is fragile" in a comment invites the question of why nobody fixed it.

The knack. Robillard's participants kept separating the overview, which can be handed over, from the "particular knack in that solution", which cannot. One manager put it flatly: "handover session theory is good. But practice is absolutely a different thing." You can transfer the fact that the notification fan-out exists. You cannot transfer the sense of when it is about to misbehave.

Two of the three are reasoning. That is the part a two-week handover is worst at recovering, and the part coding agents are now producing at a rate no human is recording.

The two weeks after the resignation

Robillard's framework sorts departures along three axes: permanent or temporary, sudden or anticipated, complete or partial. The useful observation for a leader is that a resignation with full notice is still experienced as sudden by the team, because "normal expectations about knowledge transfer cannot be met" in the time available. Two weeks is the legal minimum, not a plan.

So plan the two weeks around what can be extracted in that order, and stop pretending the rest can.

Days 1–2: find the one-name areas

Before scheduling a single handover session, work out where this person is the only holder. Do it by area, not by file, and do it against two lists: where they have been the sole author, and where they have been the sole reviewer of everyone else's work. The second list is the one teams miss, and under agents it is the one that matters, because a reviewer who was the only person reading agent pull requests in an area was, in practice, the only person understanding it. The method for building that per-area picture by hand is in who on your team understands each part of the codebase; the who-knows-what page explains why the commit-count version of it stopped being trustworthy.

Days 3–8: record decisions, not tours

The default handover is a screen-shared walk through the code. It produces a recording nobody opens. Robillard's interviewees report exactly this, including a case where "the moment the person leaves [the company], [...] they cleaned up everything, including the recordings."

Ask for decisions instead. For each one-name area, sit the leaver with a colleague who will inherit it and get three things on the record per subsystem:

Write the answers next to the code they describe, in the repository, in merge order if you can reconstruct it. A page in the wiki titled Handover notes, Sept 2026 will be unfindable by Christmas.

Days 9–10: have the inheritor make one real change

Robillard's participants are consistent on this: "When somebody explains to you, you think you understood everything... When it comes that a customer has this issue, this is a different story." The only test of a handover is the inheritor shipping a change in the area, with the leaver reviewing it, before the leaver is gone. Pick the smallest change that touches the fragile part. If that cannot happen in two weeks, the area is not handed over, and you should say so out loud rather than mark the ticket done.

Why coding agents make this worse

The two-week playbook above assumes the leaver holds the reasoning and merely has not written it down. Under agents there is a second, quieter failure: a good deal of the reasoning was never held by anyone.

Two things changed. First, an engineer can merge a module they never read. Wheeler's June 2026 position paper puts it precisely: once an agent writes the change and a person merges it, the attribution "no longer licenses any conclusion about comprehension." That means the sole-author list from days 1–2, if you build it from commits, will show you who was near the code, not who understood it. Second, we measured our own repository and found that most agent-written decisions carry no recorded alternative or trade-off at all: 1,613 of 4,302 session decisions had any deliberation on record. The rest were made cheaply enough that nobody weighed them, so there is nothing for a leaver to hand over, and the inheritor will meet those choices cold.

Both failures are invisible in a handover meeting. The leaver honestly believes they know the area, because they merged it. The inheritor honestly believes they were told the reasoning, because the session ran long. Neither has a way to check.

This is also why the commit-authorship tools built for this moment are weaker than they look. CodeScene's off-boarding simulation, the best-known one, states plainly that "the knowledge metrics are based on the amount of code each developer has contributed", and its own docs concede that after a full rewrite "its original author will still retain some knowledge in that area." That was a reasonable approximation for hand-written code. It is not a measurement of who can explain an agent-written subsystem, and a departure is the one moment you need the measurement rather than the approximation. The full argument is in a merged pull request is not evidence of understanding.

What would you need to have in place before the notice?

The honest answer is that the two weeks are for damage control. What decides whether a departure hurts is what was being captured in the eighteen months before it, and that capture has to cost the engineers nothing, because a team that ships with agents will not write ADRs at agent velocity.

Three properties, in order of how much they matter:

1. The why is recorded at merge, from the session, not reconstructed at exit. The reasoning behind a change exists for about the length of the agent session that produced it. Captured then, it costs nobody a minute; reconstructed at a handover, it is a memory of a memory.
2. You can see the one-name areas continuously, not on the day of the resignation. A per-area view of who holds what, with authorship counted as a capped estimate rather than as proof, turns "who else knows the ingest pipeline?" from a panicked Slack thread into a thing you looked at last month.
3. The reasoning reaches the next person inside their work. A record nobody reads is a recording nobody opens. The inheritor should meet the leaver's decisions in the coding agent while touching the code those decisions shaped, not in a document they were told exists somewhere.

That is what Backthread is built to do: it captures decisions, rejected alternatives, trade-offs and assumptions from the agent session and the pull-request discussion, holds each until its work merges, and shows knowledge coverage per area with the git-inferred part capped at 50% and labelled an estimate. An area with nothing recorded says nothing on record here, which is the phrase you want to read in March, not in the exit interview. When someone does leave, the decisions they made stay attached to the code, in merge order, and the inheritor is taught them in the flow of their first change rather than in a two-hour call. Source never leaves the engineer's machine unredacted, and the redaction fence is open source so your security lead can read it.

What about the 42% figure?

You will find it on every page that ranks for this query: "companies lose 42% of knowledge when an employee leaves." The primary source is a YouGov survey commissioned by Panopto, published 17 July 2018, of 1,001 US workers across all industries. The actual finding is that 42% of the knowledge needed for a role was, by the respondent's own estimate, unique to them and not shared by a co-worker. It is a self-report from 2018 about office jobs generally, not a measurement of software teams, and it predates coding agents by five years. It tells you the problem is felt. It does not tell you how much of your system one name is holding up, and no survey can.

Connect one repo and the per-area picture is there the same day, including the areas that currently depend on one name; the trial runs fourteen days with everything on, and if the map shows nothing you did not already know, you have lost an afternoon.