When the Person Who Knew Leaves
Handover documents fail for a reason that is not laziness: the departing person does not know what they know. Expertise is retrieved by situation, not enumerated on request.
Every engineering organisation has a version of this conversation. Someone gives notice, and within a day a quiet question circulates: who knows the billing system now?
Occasionally the answer is nobody. More often it is worse — the answer is "sort of, several people, partially" — and it takes eighteen months and one incident to discover which parts nobody actually had.
This is usually filed as a knowledge-transfer problem to be handled during a notice period. It is not. It is a structural feature of how software organisations store what they know, and notice periods cannot fix it.
Where the knowledge actually lives
For any system of consequence, understanding is distributed across four places, and only one of them is durable.
The code. Complete, authoritative, and expensive to read. It says what happens. It does not say why, and it does not say which parts matter.
A few people's heads. Fast, contextual, includes intent — and walks out of the building at will.
Documents. A snapshot of an understanding at a moment, competing against shipping for maintenance, describing a product that no longer exists within a quarter.
Nowhere. The largest category. The reasoning behind a decision that was obvious to everyone in the room in 2023 and has never been written down since.
When someone leaves, you lose category two entirely and much of category four with it — because the things in "nowhere" were usually retrievable only by asking a specific person a specific question.
Why notice periods do not work
The standard remedy is a handover: documents written, sessions recorded, a wiki page per system.
It fails for a reason that has nothing to do with effort. The departing person does not know what they know. Expertise is largely tacit. Ask an expert to write down what they understand about a system and they produce the parts that are consciously accessible — architecture, main flows, known gotchas. The valuable knowledge is retrieved by situation: they know the answer when a question is asked, and cannot enumerate the questions in advance.
So handover documents are systematically biased toward what was easy to recall and away from what will actually be needed, which is the odd interaction discovered at 2am eight months later.
This is why teams do handover diligently and still get surprised. The process is not being done badly; it is being asked to do something people cannot do.
What it costs
The costs land in three places, and only the first is ever attributed to the departure.
Replacement. Recruit, hire, ramp. Three to six months to productivity for a senior engineer is common, and almost all of it is acquiring context rather than learning to code.
Decision quality, everywhere. With the expert gone, "is this risky?" is answered by whoever has been there longest. Sometimes right, never checkable, and now with less basis. This is the largest cost and it never appears in any report — it shows up as slightly worse decisions, quietly, hundreds of times a year.
Deferred change. Teams stop touching the area nobody understands. It becomes the part of the product that does not improve, then the part that blocks the roadmap, then the migration nobody can scope. Deloitte attributes 64% of software defects to the requirements and design phases — decisions made with incomplete understanding — and losing your best-informed person makes that number worse.
Why AI has not solved it either
An assistant that has read the whole codebase looks like the answer. Partly it is: nobody has to grep any more.
But what left with the expert was not code knowledge. It was why — intent, history, which oddities are load-bearing, what was tried and abandoned. Almost none of that is in the code, so almost none of it is available to a tool reading the code.
There is a subtler risk. An assistant will answer confidently about the area nobody understands, and the team has lost the one person who could have said "that is wrong". Removing your best verifier while adding a confident, unverifiable source is a genuinely worse position than before, and it is easy to walk into because the tool feels like a replacement.
METR's trial is relevant here too: experienced developers on familiar repositories were 19% slower with AI while believing they were faster. If the tool does not reliably help those who have context, treating it as a substitute for someone who had it is a large assumption.
What actually helps
Nothing here depends on people staying.
Capture the why at the moment of the decision. Not in a quarterly documentation sprint. When somebody explains in review why a guard exists, that explanation is at its most complete right then. A sentence in a durable place beats a page written a year later from memory.
Make explanations reusable. Every time an expert answers a question in Slack, that answer dies in a channel. The same question will be asked again by someone else. The gap between "answered once" and "answerable by anyone" is where most institutional knowledge is lost.
Insist on evidence. An answer that cites its source can be checked by someone with no context. That is the property that lets knowledge survive the person — because the next reader does not have to trust, they can verify.
Measure the bus factor per area, not per company. For each significant part of the product, how many people could confidently make a change? Anywhere the answer is one, you have a scheduled outage with no date on it.
Rotate deliberately. The cheapest insurance is having a second person work in each critical area occasionally. It is slower this quarter and much cheaper the quarter someone resigns.
The question to ask this week
Pick your most critical system. Ask: if the person who knows it best gave notice tomorrow, what would we not be able to answer in ninety days?
Write that list. It is the most valuable engineering document your organisation does not currently have — and unlike a handover written under time pressure, it can be worked on while there is no emergency, which is the only condition under which this problem is cheap to solve.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
Why do knowledge handovers during notice periods fail?
Because expertise is largely tacit — the departing person does not know what they know. Asked to write it down, they produce what is consciously accessible: architecture, main flows, known gotchas. The valuable knowledge is retrieved by situation, meaning they know the answer when asked but cannot enumerate the questions in advance.
What does losing a key engineer actually cost?
Three things, and only the first gets attributed to the departure. Replacement and ramp, which is three to six months for a senior. Decision quality everywhere, because "is this risky" is now answered with less basis. And deferred change, as teams stop touching the area nobody understands until it blocks the roadmap.
Can AI tools replace an engineer who left?
Not for the part that mattered. What left was intent, history and which oddities are load-bearing — almost none of which is in the code, so almost none is available to a tool reading code. There is also a risk: the assistant will answer confidently about the area nobody understands, and you have just lost the person who could have said it was wrong.
How do we measure bus factor properly?
Per area, not per company. For each significant part of the product, count how many people could confidently make a change to it. A company-wide average hides exactly the concentration you are looking for. Anywhere the count is one, you have a scheduled outage with no date on it.
What is the cheapest insurance against key-person risk?
Capturing the reason at the moment a decision is made rather than in a later documentation effort, making answers reusable instead of leaving them in chat threads, requiring that every answer cite a source so it can be checked by someone without context, and rotating a second person through each critical area occasionally.
Related articles
MCP, Explained for Engineering Teams
What the Model Context Protocol actually is, why it turns an N×M integration problem into N+M, and the question to ask a vendor that 'we support MCP' does not answer.
The 19% Problem: What a Controlled Trial Revealed About AI and Developers
A randomised controlled trial found experienced developers were 19% slower with AI — while estimating they were 20% faster. The detail everyone skips explains why.
Everyone Is Speaking a Different Language About the Same Product
Support, product, engineering and finance describe one fact in four vocabularies with no shared object connecting them. Every handoff is a translation, and 64% of defects originate there.