Someone resigns on a Monday. In their final fortnight they write a handover document, which everybody thanks them for and nobody reads until the first thing goes wrong six weeks later. At that point it turns out the document explains how to run the monthly report and says nothing about why the report exists, who reads it, or what the number is supposed to be compared against. The knowledge left the building on their last day. The document was a receipt for it, not a copy.
Why the final-fortnight handover fails
It is written at the worst possible moment by the worst possible author. The person leaving is mentally elsewhere, has a leaving lunch and an exit interview in the diary, and is being asked to document work they have done so many times it has stopped being visible to them. Expertise is exactly what you cannot see any more.
It is also written for nobody. Their replacement usually does not exist yet, so the author has no reader to imagine, and defaults to describing the parts they find interesting rather than the parts a newcomer will fall over. What comes out is a tour of the job rather than a way of doing it.
The result is the same in every organization: a document that is thorough about procedure, silent about judgement, and out of date the first time anything changes.
What actually walks out with a person
It helps to separate the five kinds of thing a leaver takes, because they need completely different treatment and only one of them is what handover documents usually cover.
| What leaves | How bad | Where it should already live |
|---|---|---|
| Access: logins, keys, admin rights, licences | Recoverable but urgent, and a security risk | An access list held by the organization, not a person |
| Procedure: the steps of a recurring task | Recoverable, slowly and expensively | A written process, kept where the work happens |
| Relationships: who to call, and the history with them | Genuinely damaging, and invisible for months | The contact record, with notes, not an inbox |
| Judgement: why it is done this way and what to watch for | The expensive one, almost never captured | Notes attached to the process, written over time |
| The queue: what is half-finished right now | Immediate, and obvious within a week | Shared task and project records, kept current |
Look down the last column. Every single one of those is something that should already exist before anybody hands in their notice. That is the real conclusion here and it is slightly uncomfortable: a handover document is a symptom. You are writing one because the knowledge was living in a person instead of in the organization, and the fortnight before someone leaves is far too late to fix that.
If a handover document is the first time something is written down, you did not lose the knowledge when they resigned. You lost it years ago and only noticed on their last day.
The version that works, which starts long before the notice
The organizations that survive turnover well are not the ones with better exit checklists. They are the ones where a departure removes a colleague, not a category of knowledge, because the capture happens continuously and cheaply while the work is being done.
- Write the process the second time you do it, not the tenth. The second time is the sweet spot: recent enough that the confusing parts are still fresh, familiar enough that you know what actually matters. By the tenth repetition the difficulties have become invisible to you and the document you write will skip them.
- Capture the why alongside the what. One line is usually enough. “We send this on the 3rd because payroll closes on the 5th.” “Call rather than email, this supplier does not read email.” Judgement is the part that never survives, and it survives in single sentences attached to the step it explains.
- Keep notes on the record, not in the inbox. The history of a client, a donor, a supplier or a family belongs on that contact record where the next person will look. An email thread is a private archive that becomes unreachable the moment the account is closed.
- Maintain an access list as an organizational asset. Every system, who administers it, who pays for it, and how access is granted and revoked. This one document prevents the most common post-departure emergency, which is discovering the domain renewal goes to an address nobody can open.
- Rotate the recurring jobs occasionally. Have someone else run the month-end, the rota, or the newsletter once a quarter. Nothing tests documentation like a second person following it, and nothing else finds the missing steps as reliably.
- Treat every new starter as an audit. The questions a newcomer asks in their first month are a precise list of what is undocumented. Write down the answers as they come rather than answering verbally and losing the finding.
When you did not do any of that, and they leave on the 20th
Sometimes there is no continuous capture and there are two weeks. In that case do not ask for a comprehensive document, because you will get length instead of value. Ask for a small number of specific things, in this order.
- Everything you have access to. Systems, keys, accounts, shared subscriptions, anything registered in their name, anything paid on their card. First, and non-negotiable.
- The live queue, with its true state. What is in flight, what is waiting on someone else, what is quietly overdue. Explicitly invite the awkward items. A leaver is the only person who will ever tell you about them.
- The calendar for the next twelve months. Renewals, deadlines, annual events, the thing that has to happen in March that only they know about. Recurring obligations are the most common thing to be dropped after a departure.
- People, with context. Not a contact list, which you have. Who to call for what, who is difficult, who owes you a favour, which relationship is fragile and why.
- The three things that would go wrong first. Ask directly: if you vanished tomorrow, what breaks in the first month, and what would nobody notice was broken? This question outperforms an entire document.
- A named person for each of the above. A handover with no recipient is a filing exercise. Every item needs an owner before the last day, even if the owner is temporary.
Then sit the two people in a room for an hour with that list. Verbal handover with a written spine transfers far more than either does alone, because the receiver asks the questions the leaver did not know needed answering.
The month after is when you find the gaps
The handover is not finished on the last day. It is finished about a month later, and only if someone is paying attention.
- Keep a log of everything nobody can answer. Every “does anyone know how…” for the first month. That log is your genuine gap analysis, and it is the document worth keeping.
- Revoke access on the last day, not eventually. Not a matter of trust. Dormant accounts with live permissions are the most common way an organization is compromised months after someone amicably left.
- Redirect rather than close the mailbox. Six to twelve months of forwarding to a named colleague catches the annual renewals and the contacts who never got the message.
- Write down what you learned about the role. The gaps you just found are the job description for the replacement, and they are more accurate than the one you advertised with.
- Ask what else is carried by exactly one person. A departure is the only moment when everyone can see the cost of single points of failure. Use it, because the appetite fades within a quarter.
Key takeaways
- A handover document is a symptom. If it is the first time something is written down, the knowledge was already at risk for years.
- Capture judgement, not just procedure. The why behind a step is what never survives, and it survives in single sentences written at the time.
- Ask what breaks first, not for a full document. Two weeks buys you access, the live queue, the annual calendar, relationships, and the three failure points.
- Finish the handover a month later. Log every unanswerable question, and treat that log as both a gap analysis and the real job description.
Questions to ask your team
How long should a handover document be?
Short enough that the receiver reads it in one sitting, which in practice is a few pages. Length is a warning sign: it usually means procedure was documented in place of judgement, because procedure is easier to write.
What if the person is leaving on bad terms?
Prioritize ruthlessly: access first, live queue second, annual obligations third, and accept you will not get the relationship context or the judgement. Then plan for the fact that the first three months will be harder, and put the unanswerable-question log in place from day one rather than week four.
Who should receive the handover if there is no replacement yet?
A named current colleague, as custodian rather than owner. Handing over to a role that does not exist yet means handing over to a folder, and folders do not ask questions or notice when something is missing.
Does this apply to volunteers and short-term team members?
More than it does to staff, because the turnover is faster and the documentation is usually thinner. A volunteer who has run the same thing for six years is one of the largest single points of failure most organizations have, and one of the least examined.
How do we do this without making people feel replaceable?
Frame it as coverage rather than succession, and make it universal. Everyone documents, everyone rotates a recurring job occasionally, and it happens continuously rather than when someone looks like leaving. Capture that only starts when trust drops is correctly read as a threat.
