Every role accumulates a private layer of knowledge that never appears in an org chart or a job description. It lives in the head of the person doing the work: which supplier answers the phone quickly, why a report is built the odd way it is, which client needs a reminder two days early, and what to do when the monthly numbers refuse to balance. When that person leaves, takes extended leave, or simply moves to another team, most of that knowledge walks out the door with them. A handover document is the one artifact that can stop the loss, but only if it is written for the person who inherits the work rather than for the person leaving it.

The trouble is that handover documents are usually written under pressure, in the final anxious week before a departure, by someone whose attention has already drifted to what comes next. The result is a thin list of tasks and a folder of links that quietly assumes the reader already knows what everything means. This piece is about writing the other kind of document: the one your replacement can open on their first confused Tuesday and actually use to do the job.

Why most handovers fail

The core failure is the curse of knowledge. When you have done a job for two years, the daily mechanics feel obvious, so you skip them. You write “run the weekly report” without mentioning that the report only makes sense after you clear three exceptions by hand, or that the totals are always wrong on the first Monday of the quarter because finance has not posted yet. You leave out the exceptions precisely because you have internalized them. To you they are no longer knowledge; they are reflex. To your successor they are the difference between a smooth week and a lost afternoon.

The second failure is structure. A handover written as a long chronological brain-dump forces the reader to hold the entire job in their head at once. They cannot separate the urgent from the occasional, or the critical from the merely nice to know. Even accurate information becomes unusable without a spine to hang it on. A good handover is not a transcript of everything you know. It is an ordered, honest guide to the parts that matter, arranged so someone can find the right piece at the moment they need it.

Start with the map, not the details

Before any procedure, give the reader a single page that describes the whole role from a height. What is this job responsible for? Who depends on its output, and what breaks for them if it stops? What are the recurring rhythms, daily, weekly, monthly, quarterly? Who are the three or four people the reader will interact with most, and what does each of them care about? This map does more than orient a newcomer. It tells them how to prioritize when everything seems to be on fire at once, which is exactly the situation a fresh handover reader tends to walk into.

A useful test for the map is whether a competent stranger could read it and correctly guess what your week looks like. If they would be surprised by how you actually spend your time, the map is hiding something important, usually the invisible maintenance work that keeps everything else running.

Document the decisions, not just the tasks

Tasks tell someone what to do. Decisions tell them why, and the why is what lets them adapt when reality does not match the instructions. Suppose your handover says: “Approve refunds under fifty dollars automatically.” That is a task. Now add the reasoning: “We approve small refunds automatically because chasing them costs more in staff time than the refund itself, and because disputes over small amounts damage the relationship more than they protect revenue.” With the reasoning attached, your successor can handle the case you never anticipated, the sixty-dollar refund from a furious long-term customer, without escalating or freezing.

Wherever the job contains a rule, a threshold, or an odd workaround, write down the thinking behind it. The workarounds are especially valuable because they usually encode a painful lesson. “Always export the file as CSV, never XLSX, because the downstream system silently drops the leading zeros on account numbers” is the kind of sentence that saves someone a week of confused debugging and one very awkward call from a client whose account could not be found.

Write for the reader’s worst day

Most handovers describe the happy path, the version of the job where nothing goes wrong. But people reach for a handover document precisely when something has gone wrong and the author is no longer around to ask. So write a section that only addresses failure. What are the three or four things most likely to break? For each one, what does the symptom look like, what usually causes it, and what is the first thing to check? Who do you call when it is genuinely stuck, and what information will they ask for before they can help?

It helps to list the traps explicitly, the mistakes that look reasonable but cause damage:

• Actions that cannot be undone, such as sending a batch email or closing an accounting period, and how to confirm you are ready before you commit.
• Systems that look identical but are not, such as a staging environment and a live one, and how to tell which you are in.
• Deadlines that are softer or harder than they appear, so the reader does not sacrifice a real one to protect an imaginary one.

A handover that honestly names its landmines earns trust. A handover that pretends the job is simple gets quietly ignored the moment reality proves otherwise.

Test it before you leave

The single most valuable thing you can do is have someone else attempt the work from your document while you are still there to watch. Sit on your hands. Resist the urge to jump in and explain. Every time the reader stops, gets confused, or asks a question, you have found a gap that would otherwise have surfaced after you were gone. Note it, and fix the document rather than the moment. This dry run converts a hopeful document into a proven one, and it is the closest thing to a guarantee that the handover will survive contact with a real successor.

Finally, treat the document as a living thing rather than a farewell letter. Store it somewhere the team controls, not in a personal drive that gets deactivated the day your account is closed. Date it, so the next reader knows how stale it might be. And leave a short note at the top inviting your successor to correct it as they learn, because the person who inherits the job will notice things you stopped seeing years ago. A handover is not the end of your knowledge. Done well, it is the beginning of someone else’s competence, and the quiet proof that the work mattered more to you than the credit for doing it.