Knowledge Transfer When Someone Leaves: What Actually Survives

The resignation lands on a Tuesday, and by Thursday there is a plan. A handover document has been requested, two hours have gone in the diary for a walkthrough, and the successor has been told to sit with them for a fortnight. It looks like a process, everybody follows it, and the boxes get ticked before the last day.

Nine months later somebody asks why a particular client is invoiced differently from everyone else, and nobody in the business can answer. The handover document is on the shared drive. It does not mention it.

What a handover is actually being asked to move

The reason handovers underdeliver so consistently is that the word covers two different jobs, and only one of them is difficult.

The first job is moving the record. Passwords, system access, where the templates live, which supplier holds which contract, what is currently in flight and who is waiting on what. This part is genuinely straightforward, it is the part every handover template is built around, and a competent person can produce it in an afternoon.

The second job is moving the reasoning. Why this client is invoiced differently, which enquiries are worth chasing and which are somebody filling in a form, why the escalation threshold sits at that number, which supplier gets called first when the usual one lets you down. This is the part that takes years to build and it is the part that a handover almost never touches, because it does not present itself as knowledge to the person holding it. It presents itself as doing the job properly.

That distinction is the whole subject. When your best operator leaves, the documents stay and the judgement goes, and businesses rarely come unstuck because they skipped the handover. They come unstuck because the handover measured the first job while the whole of the exposure sat in the second.

Four ways to hand over, judged honestly

There are only four methods in common use, and most businesses reach for the cheapest one by reflex rather than by choice. Judged on what each one actually preserves, they behave very differently.

Dimension	Handover document	Recorded walkthrough	Shadowing	Structured capture into a system
Preserves the record	Yes, this is its strength	Yes, but buried in the timeline	Poorly, nothing is written	Yes, and it is the smaller half
Preserves the reasoning	Only what they thought to say	Some, when a real case comes up	The most, while it lasts	By design, that is the point of it
Cost to the person leaving	Low, a few days	Low, they talk over their own screen	High, weeks of their remaining time	Moderate, a few hours of interview
Usable by the third person, not just the second	Yes	In theory, nobody watches it	No, it left with the successor	Yes, that is what it is for
Still useful a year later	Stale, and confidently so	Rarely opened again	Only inside one person's head	If it has owners and review dates
Fails because	They wrote what they knew they knew	An hour of video answers nothing	The clock runs out	Nobody scoped what mattered

Read across the "preserves the reasoning" row and the ranking inverts against cost. Shadowing captures the most and is the only method that reliably surfaces the things nobody knew to ask about, because the questions arrive from real work rather than from a template. It is also the most expensive, it depends on a notice period you rarely have, and everything it transfers ends up inside one person, which means you have moved the dependency rather than reduced it.

Then read the "still useful a year later" row, which is where most handover plans are quietly deciding something they have not thought about.

The row that decides it

A year is the honest test, because a year is roughly when the successor stops being new and starts being the only person who knows.

The government's own guidance on preparing its datasets for AI describes this failure in its own estate, and the description travels well beyond government. It notes that data often remains siloed in respective department systems and with inconsistent documentation, and it puts the consequence plainly. Many datasets lack sufficient metadata, making them difficult to repurpose. That is a statement about government data, not about your handover file, but the mechanism is identical. Something was recorded, the context around it was not, and the recording is now technically present and practically unusable.

This is what happens to almost every handover artefact by month nine. The document exists and nobody can tell which parts of it are still true. The walkthrough recording exists and nobody is going to scrub through fifty minutes of somebody else's screen on the chance that the answer is in there. Neither has an owner, so neither gets corrected, and a wrong answer that looks authoritative is worse than no answer at all, which is the aggregate cost of a business forgetting arriving in a single concentrated dose.

The same UK government AI playbook that departments work to is unusually direct about the maintenance half of this. Alongside the technical guidance it tells teams to establish clear roles and responsibilities to ensure accountability within teams and to set out how the AI model will be maintained and managed over time. Written for AI systems, but it is the same requirement any captured knowledge has, and it is the requirement handover plans skip almost universally. Somebody owns it, and somebody looks at it again on a date that is already in the diary.

What a knowledge transfer checklist should include

Most templates you can download are inventories. They ask where things live, who has access, what the passwords are, and which contracts renew when. All of that is worth having and none of it is what fails.

A knowledge transfer checklist that earns its place asks for reasons. Five categories cover it.

The repeated decisions. Not the process, which is probably documented and was never at risk, but the calls this person makes over and over that the process does not cover. Which quotes get priced aggressively and which get priced properly. Which enquiries are real. When to hold a price and when to move. Each one wants the reasoning attached, because the reasoning is stable even when the specific cases are not.

The exceptions. Every business has customers, suppliers and situations that are handled differently from the stated rule, and the reason is usually sound and almost never written anywhere. The invoicing question from month nine lives in this category. Ask what gets treated as a special case, and what condition makes it one.

The relationships. Not the contact list, which is in the CRM. What each significant relationship is sensitive to. Who needs a call rather than an email. Which client means it when they say the deadline is fixed and which one always says that.

The configured systems. Anybody who has automated anything has encoded judgement into it. The routing rules, the qualification thresholds, the cases that escalate and the cases that get handled quietly. The system will keep executing those decisions perfectly and will never explain them, so the reasoning has to be recorded next to the configuration while the person who chose the numbers is still available to say why those numbers.

The open loops. Anything currently in flight with context that exists nowhere else. This is the only category with a genuine deadline attached, and it is the one most handovers do cover.

Give every entry an owner and a review date. Without those two fields you have produced a document, and the row above already showed you what documents look like a year on.

What four weeks actually buys you

Most of this work is far cheaper done calmly and long before anybody resigns, which is a point worth making once and then setting aside, because you are usually reading this with a leaving date already in the calendar.

Inside a notice period the binding constraint is not the leaver's willingness, it is attention. Their diary fills with goodbyes and loose ends, the successor may not have started, and everybody is trying to run the business at the same time. Full coverage is not available and chasing it is how businesses end up with a broad, shallow record of the things that were never in danger.

What works is narrow and deliberate. Spend the first week deciding what actually matters, which usually means asking which two or three areas would visibly degrade if this person were unreachable for a fortnight. Spend the middle two weeks in recorded sessions on those areas, working through real cases rather than abstract process, with somebody other than the leaver writing up each session within a day of holding it. Keep the final week for the successor to attempt the work while the person leaving is still there to correct them, which is the closest thing to shadowing that a compressed timetable allows.

The recurring mistake is putting all of it in the last week. By then the leaver has mentally moved on, and you are asking the hardest questions of the business at the moment the person answering has the least reason to think hard about them.

The version of this that does not decay

Structured capture sits differently in that table for a reason that has little to do with being more thorough. Its output is built to be asked questions rather than filed, which is what an intelligence system actually holds: decisions with their reasoning, standards with the thinking behind them, and the conditions under which something becomes an exception, all of it findable and each piece owned by somebody.

The practical difference shows up in what happens to the capture afterwards. A document goes into a folder and waits to be found. Material captured into a system sits in the path of the work, gets used often enough that errors surface, and carries the review dates that stop it rotting quietly.

We saw the same mechanism on a marketing team at a global biometrics business, where one person was running marketing, channel and distribution across several regions and every piece of content waited on his attention. His tone rules and messaging guidelines were built into the drafting step, which took output from 1-2 posts a month to 2+ a week and handed back around 115 hours of capacity a year, with the editorial judgement staying firmly with him. The hours mattered, but the more durable result is that the standards he had been applying by instinct now exist in a form that does not depend on him being at his desk.

That is the honest reason to prefer structured capture, and it has nothing to do with software. The judgement got written down in a place other than one person's head, which is the whole of the objective and the part every handover method is really being judged on.

Businesses are also buying capability back from the market less than they used to. The Department for Education's Employer Skills Survey covers 22,712 UK employers, and it puts employer training expenditure at £1,700 per employee, down from £1,960 in 2022 and a 29.5% decrease since 2011 in real terms. Spending less on developing people while relying on the same people to hold the reasoning in their heads is a position that only works until somebody resigns.

And the target keeps moving. IBM put the question to 2,000 chief executives across 33 countries. 54% of CEO respondents say they are hiring for roles related to AI that did not exist a year ago, which means a meaningful share of the roles being handed over in the next few years will not have a predecessor to learn from at all. Whatever the business has managed to write down becomes the only starting position available.

If none of this is currently written anywhere, the starting move is smaller than it sounds. It is writing down what the business knows, in a sensible order, beginning with the areas where the fortnight question already makes you uncomfortable. And if you would rather have somebody map the exposure before committing to anything, that is what a knowledge audit actually involves.

Practical takeaways

1. Separate the record from the reasoning. The record is passwords, access, contracts and open items, and it takes an afternoon. The reasoning is the repeated decisions and their conditions, and it is the only part that was ever at risk. Do not let the first one absorb the time budget for the second.
2. Pick the method by what you need to survive, not by what is cheapest. A handover document is right for procedural work. Where one person's judgement is the asset, a document on its own is a filing exercise.
3. Interview, do not delegate the writing. Somebody other than the leaver should run recorded sessions on real cases and write them up. The person holding tacit knowledge cannot see which parts of it are unusual.
4. Attach an owner and a review date to everything captured. Unowned material is stale within a year, and stale material is worse than missing, because nobody knows to distrust it.
5. Go narrow inside a notice period. Two or three areas covered properly beats a comprehensive document about the parts that were never going to break.
6. Record the reasoning behind every automation you own. Configuration executes decisions faithfully and explains nothing. The thresholds need their justification stored next to them while the person who picked them is still employed.

A handover is not really a transfer of information. It is a test of whether the business ever wrote down why it does things the way it does, and a notice period is a bad time to discover the answer. The businesses that come through a senior departure well are almost never the ones with the best template. They are the ones where a reasonable amount of the reasoning already existed somewhere other than in the head of the person walking out.

Frequently asked questions

What should a knowledge transfer checklist include?

Reasons rather than locations, which is the single change that separates a useful checklist from an inventory. Five things belong on it. The decisions this person makes repeatedly, with the reasoning behind each one. The exceptions, and the conditions that trigger them. The relationships, and what each one is sensitive to. The systems they configured, and why the thresholds sit where they do rather than somewhere slightly different. And the open loops, meaning the things currently in flight that have context nobody else holds. Give every entry a named owner and a review date, because an unowned entry is the one that quietly goes stale. If your checklist is mostly asking where files live, it is measuring the part that was never at risk.

How do you capture tacit knowledge?

By interviewing for it rather than asking somebody to write it down. Someone else runs the session, works through three or four recent real cases, and asks why at every decision point until the answer stops being "it depends" and turns into a stated condition. Record the session and have the interviewer write it up, because the person holding the knowledge is the worst-placed person in the building to know which parts of it are surprising. It is obvious to them, which is exactly why they never wrote it down. Two or three hour-long sessions built on live cases will get you further than a fortnight of somebody documenting alone at their desk. The judgement worth going after is the reasoning behind repeated calls, not the steps of the task, and the sessions are only as good as the cases you choose to walk through.

Is a handover document enough?

It is enough for work that is genuinely procedural, and it is the weakest of the four methods everywhere else. A handover document is cheap, it is the only method that reliably survives a year, and it captures less than any of the others, because a document written by the person leaving records what they think is worth saying. The knowledge that causes trouble later is the knowledge they never classified as knowledge. Use the document for the record, meaning systems, access, contacts and the state of anything in flight, and pair it with a method that goes after reasoning. On its own it is a filing exercise that feels like a handover.

What can you actually get done in a four-week notice period?

Less than the plan assumes and considerably more than most businesses attempt. A realistic four weeks is three or four recorded sessions covering the two or three areas where the exposure is genuine, written up as you go rather than at the end. Do not try for full coverage, because attempting everything is how businesses end up with a broad, shallow record of the things that were never at risk. Spend the first week deciding what actually matters, the middle two recording and writing, and the last week letting the successor attempt the work while the person leaving is still there to correct them. The common failure is scheduling all of it into the final week, by which point the leaver is mentally gone and their diary belongs to everybody else.

What survives a year later?

Whatever somebody had a reason to open. Two things decide it, and neither of them is how thorough the capture was. The first is findability, because material nobody can locate is functionally lost however good it was. The second is currency, and stale material is worse than absent material, since it is confidently wrong and nobody knows it. What survives in practice is anything with a named owner and a review date, anything sitting in the path of work people already do, and anything that answers questions people actually ask. Recorded video survives worst of all, because nobody scrubs through an hour of somebody else's screen share to find one answer they are not certain is in there.