Handover document: writing down what only you know

A handover document is what one person writes so another can take over their work without rediscovering it. It matters at a resignation, but equally before parental leave, a long absence, a role change, or a project moving between teams — and it is almost always written too late, in the final days, by someone whose attention has already moved on.

The useful structure is not the job description. It is the week: what happens regularly, what is in flight right now, who to talk to, and the accumulated knowledge that exists nowhere else. That last category is the reason the document exists at all.

What belongs in it

• The role in two lines: what it is accountable for, and what would visibly fail without it.
• Recurring commitments — daily, weekly, monthly, annually — with when they happen and what they involve. The annual ones are the ones successors miss.
• Work in progress, each with its current state, the next step, and who else is involved.
• Key contacts: internal and external, what each is for, and any context about how they prefer to work.
• Systems and access: what you use, what your successor will need, and who grants it.
• Where things live — the folder, the board, the shared drive — because half of handover pain is search.
• Recurring problems and how they are handled. This is institutional knowledge and it is the section people skip.
• Deadlines in the next ninety days, so nothing lands unexpectedly on someone new.
• "Things only I know": the workaround, the client who must be phoned not emailed, the report that breaks every quarter. Write this section first, while you can still remember what is unusual.

The hardest content to capture is what has become invisible through familiarity. A practical trick: for a week before writing, note every time you do something a newcomer could not have worked out — a shortcut, a name to ask, an unwritten rule. That list becomes the most valuable section, and it cannot be reconstructed from memory on the last afternoon.

Writing and handing over

1. Start the week the departure or absence is known, not the week before it happens.
2. Draft against the recurring calendar first — it is the fastest way to remember commitments you no longer notice making.
3. Write for someone competent but new. Assume professional skill, assume no context.
4. Link rather than duplicate: point at the procedure, the board, the folder, so the document does not become a stale copy of everything.
5. Have the successor read it and ask questions while the author is still available. The questions are the real gap analysis, and they should be written back into the document.
6. Do at least one working session together on the recurring task that matters most — watching beats reading for anything procedural.
7. Name a fallback contact for after the handover, so the successor has somewhere to go with the question nobody anticipated.
8. Keep the document afterwards, and have the successor update it. The next handover is then a revision rather than a fresh start.

Why handovers fail even when written

Two patterns account for most of it. The document is written but never read together, so the successor discovers it only when they are already stuck and cannot ask the author. And the document describes the formal job rather than the real one — the meetings attended, the systems used, but not the fact that a particular client escalates every quarter and the fix is a phone call to one person. The formal parts can be reconstructed from anywhere; the informal ones leave with the individual, which is precisely why the document should be weighted towards them.

In Ettex, the document lives in Ettex Docs — a template so every handover starts from the same structure, threaded comments so the successor's questions attach to the paragraph that prompted them, version history so the next handover starts from the last one, and share links so the document points at procedures rather than copying them. Recurring commitments are easiest to reconstruct from Ettex Calendar, work in progress from the cards in Ettex Board, contacts from Ettex Contacts, and the systems-and-access inventory belongs as a table in Ettex Records, where it doubles as the checklist for removing access later.

The boundary: Ettex has no knowledge-transfer or succession feature. Nothing here prompts what to document, detects undocumented knowledge, tracks whether a handover happened, or maps who else can do a job. It is a document with comments and history, plus the calendar and board you already use to reconstruct the content. The discipline of writing it early is the part that matters and it is not a software problem.

Common weaknesses

• Written in the last two days, when attention and goodwill are both gone.
• Structured as a job description instead of as a week.
• Annual and quarterly commitments omitted because they were not happening that month.
• Everything duplicated into the document, which is stale within a month.
• No "things only I know" section — the reason the document exists.
• Handed over as a file, with no session and no questions.
• No named fallback contact after the person leaves.
• Never updated by the successor, so the next handover starts from nothing again.

Property handovers have their own version of this, and it runs in the opposite direction. At the end of a commercial lease the landlord produces a schedule of dilapidations rather than the outgoing tenant producing a handover pack — which is why the evidence a tenant needs has to be gathered at the start of the term, not at the end.

A handover document is worth what its "things only I know" section is worth. Start early, structure it around the week, link rather than duplicate, and read it through with your successor while you are still there to answer.