Handover documents get written at the worst possible moment: when the person with the knowledge is halfway out the door, mentally if not physically. The result is usually a document that lists what exists but not how it works, written for the author rather than the successor. A good handover is different — it's the answer to one question: what will the next person need at 4pm on a bad day, three months from now, with nobody to ask?
Structure for the successor's questions
Skip the org-chart preamble. Order the document by what the incoming person will actually reach for:
- The one-page overview. What this project is, who it's for, what "healthy" looks like, and the two or three things most likely to go wrong.
- Access and accounts. Every system, who grants access, and — critically — anything only you could touch. Orphaned admin rights are the classic handover failure.
- Rhythms and obligations. Recurring meetings, reports due, renewal dates, the customer who emails every quarter. Calendar-shaped knowledge evaporates first.
- Current state. What's in flight, what's blocked and why, what was just decided. Link the live board rather than duplicating it — if the work is tracked in a tool like Axtio, the handover doc should point at it, not race it.
- The undocumented deals. Informal agreements, sensitivities, "we never ship on Fridays because," which vendor contact actually answers. This tribal-knowledge section is the most valuable and the one templates always omit.
- Contacts. Who to ask about what, internally and externally, with a one-line "why you'd call them."
Write for a stranger, not a colleague
The curse of knowledge is the central writing problem. You know what "the usual export issue" means; your successor doesn't. Concrete rules:
- Expand every acronym on first use, even the "obvious" ones.
- Replace "the usual process" with the actual steps or a link to them.
- Name things by their findable names — the exact report title, the actual folder path.
A useful test: could a competent person from a different department follow this? If a passage only works for someone who already knows the answer, rewrite it. This is also where a clarity-focused rewriting tool such as Wrivio earns a place in the workflow — handover prose written in exhausted shorthand can be rewritten for a cold reader, with a visible diff so nothing factual drifts in the process.
Do the walkthrough — the document is not the handover
A handover document that's never been tested is a hypothesis. If any overlap time exists, spend it having the successor do the key tasks from the document while you watch silently. Every place they get stuck is a bug in the document; fix it on the spot. One live walkthrough is worth ten review reads.
Freeze the final version
A handover is a snapshot, and it will be consulted long after you're gone — sometimes in disputes about "what was the state when I took over." When it's final, export it to PDF so there's a dated, unchangeable copy alongside the living version. And resist the urge to pad it: a focused fifteen pages that gets read beats a comprehensive sixty that doesn't. The measure of success is simple — how rarely they need to call you.
