The outline is their questions, not your job description
Asked to write a handover, most people start by listing the work they owned. That list feels natural to the writer and has no order for the reader. Your successor opens this document at exactly one kind of moment, when they are stuck, and what they need then is the next click, not a map of your job description.
So derive the outline backwards. Write down what your successor will type into a search box the week after you leave, and who they will ask what, then promote those questions into section headings. Six or seven questions are enough to give the document a spine, and anything that does not attach to that spine is usually something you can leave out.
You are handing over access and contacts, not tasks
The explanation of the work itself is usually already sitting in internal documents and past records. What actually disappears is the hardware around it: which account you log in with, who signs off, which department you call when this stalls. Sweeping through the five categories below makes the empty cells visible.
| Category | What to write | What happens if it is missing |
|---|---|---|
| Work in flight | Progress, the next single step, the deadline | Your successor learns about the deadline after it passes |
| Recurring duties | Cadence, due date, what breaks if skipped | A monthly task vanishes entirely a month later |
| Access and accounts | Which permissions are needed and who grants them | Week one is spent filing access requests |
| People and channels | Who to contact, and for what | A one-line confirmation takes two days |
| Decision history | Why it is done the current way | Your successor retries an approach that already failed |
Two-thirds of projects stop if two people leave
Software teams use a metric called the truck factor: the number of developers who would have to vanish before a project is incapacitated. The name comes from being hit by a truck, or simply quitting. In 2016 a research group proposed a way to estimate it automatically and ran it over 133 popular GitHub projects (Avelino et al., ICPC 2016). Sixty-five percent of them had a truck factor of two or lower, meaning two departures would stop them.
The study covered open-source projects, so the figure does not transfer straight to a company. But these were popular projects with plenty of contributors. The concentration came from few people knowing, not from few people being there.
A handover document is the cheapest way to lower that concentration before anyone leaves. Start it after the resignation and you have a few weeks, and a few weeks of recall reaches back only a few months. Spend thirty minutes updating it twice a year and there is almost nothing left to write in your final week.
The first thing to vanish is why
Procedures stay in the document. The reason a procedure was set that way leaves with the person. So about six months later your successor finds a rule that looks odd, reasonably fixes it, and then learns why the rule existed by way of an incident.
Preventing that is cheap: one line of reason per item. Attach it without fail to anything that looks like an exception, anything you do differently from everyone else, and anything marked do not do. If you cannot remember why a rule exists, write that down too. When your successor weighs whether the rule can change, the fact that nobody knows the reason is itself usable information.
The last section is what you could not hand over
Almost no handover is complete. There is always the inquiry you never resolved, the archive you moved halfway, the question whose owner has been out of the office. Leave those out and the document looks tidy, while your successor steps into the hole alone a few weeks later.
So the last section is titled what has not been handed over. Give each item an owner and a date, and where no owner has been decided, write that no owner has been decided. With this section, your successor can see the edge of what they do not know; without it, they believe the document is the whole territory. A handover whose last section is empty is usually not a well-written document, just an unfinished one.
Frequently asked questions
I only have a week to hand over. What comes first?
Access and contacts first. Your successor can follow an explanation of the work if they spend time on it, but without an account there is no screen to read. Then anything with a deadline inside this month, then the recurring duties. Background and decision history get whatever time is left. Do it in the reverse order and the last day arrives with the most urgent sections still blank.
No successor has been named yet. Should I still write it?
Not knowing is arguably better. Writing with a specific person in mind makes you skip whatever you assume they already know, and that assumption is usually wrong. Write for someone taking this job for the first time and the omissions shrink. Once a successor is named, trimming to fit them is far easier than discovering what you left out.
Do passwords go in the document?
They do not. A handover is opened by many people and lives a long time, so the moment a password lands in it, that account is effectively public. The document records which accounts are needed, who grants the permission and where to request it. The credentials themselves move through whatever secret manager or admin account your company uses, and only the route is written down.
How do I know the finished document is any good?
The surest test is to have your successor run one real task end to end from the document alone, while you are still around. Every question that comes up is a blank in the document, so do not just answer it, fill it in on the spot. If there is no successor yet, handing it to one colleague who does not know this work and asking them to mark where they got stuck catches about half of it.