You have four weeks left and someone has asked for a handover document. So you write a list of your responsibilities, a list of the systems you look after, and a list of the meetings you attend.
Nobody will read it. Not through rudeness — because a list of responsibilities does not answer any question a person actually has, and the questions only arrive later, when you are gone and something has broken.
Write it as answers, not as an inventory
The reframe that makes handover documents useful: write down the answers to the questions people will ask you after you have left.
That is a genuinely different document. It is not "I am responsible for the billing pipeline". It is "when billing fails overnight, it is almost always the currency conversion job, the logs are here, and Priya knows the manual fix."
You already know what those questions are, because you have been asked them. The list of things people interrupt you about is the handover document, and it is much shorter than an inventory of your role.
The five things worth writing down
The undocumented facts. Things that are true, that matter, and that exist nowhere but in your head. The service that must be restarted in a particular order. The client who needs a phone call rather than an email. The report that looks broken and is not. These are the highest-value lines in any handover and they are invisible to everyone except you, because to you they are simply how things are.
Who to ask, for what. Not the org chart — the real map. Who actually knows the payment system. Who to go to when the official route is stuck. Who will say yes to a small exception and who will not. This is the knowledge that takes a new person a year to acquire and ten minutes to write down.
What is in flight, and where it actually is. For each open thing: what state it is genuinely in, what the next step is, and what nobody else knows about it. Be honest about the ones that are stalled, including the ones stalled because you were avoiding them. That is the kindest thing in the whole document.
What will break, and when. The certificate expiring in March. The contract renewing in June. The thing that always fails in the last week of the quarter. Known future events with dates on them are the single easiest thing to hand over and the most commonly forgotten, because they are not on anyone's list yet.
What you would fix next. Your judgement about the shape of the thing, which is worth a lot and which nobody will ask for. Two or three lines about where the real problems are. Whether they act on it is not your concern; leaving it is a courtesy to whoever inherits the same frustrations.
Where to write it
In the shared system, not in your personal notes. This is the one document that belongs on the company's infrastructure — a wiki, a repo, wherever the team's knowledge lives. A handover in a personal file is a handover nobody can find.
Which is the other half of the split worth keeping deliberately: your own work log and your own notes go with you, and the operational knowledge stays. Deciding that consciously in your final weeks avoids both failure modes — taking things you should have left, and leaving things that were yours.
The two weeks before
Start now, not in the last week. The final week is meetings, goodbyes and access being revoked. A handover written then is thin, and it is written in a state of already having left.
Write it as you get asked things. For your remaining weeks, every time someone asks you a question, write the answer into the document rather than only replying. This produces a document about the things people genuinely ask, which is exactly what you want and impossible to guess in the abstract.
Do the walkthrough, and let them drive. Sit with whoever is taking over and have them do the task while you watch. This is the step that finds the gaps — everything you forgot to mention surfaces in the first ten minutes, and nothing else surfaces it. A walkthrough where you drive and they watch teaches almost nothing.
Say where the accounts and access are. Not credentials — where they live, which password manager, who administers them, what will need transferring. Access is the most common thing to break after somebody leaves, and it is the easiest to prevent.
Being honest about the stalled things
The section people write badly, and it is worth doing well.
There is always something you have been avoiding. A conversation not had, a decision deferred, a bug you keep deprioritising. The instinct is to leave it out of the handover, or to describe it in language that makes it sound like an ordinary open item.
Do not. Write down what is actually true, plainly: this has been open for five months, here is why, here is what I would do. Nobody is going to think less of you on the way out, and the alternative is that someone discovers it in three weeks with no context and forms a much worse impression than the honest version would have created.
What this is also for
Two things beyond the obvious.
Writing it is the clearest picture you will ever have of your own job. People are routinely surprised — by how much they were holding, by how much was undocumented, by how much of the role was not in the job description. That is worth knowing at exactly the moment you are deciding what to look for next.
It is CV material. Not the document itself, but the process of writing it surfaces everything you did and everything that depended on you. Copy the useful parts into your own work log before you lose access.
The honest version
Some handovers do not matter. If the role is genuinely replaceable and well documented, an afternoon is plenty and a thorough document is effort spent on nobody's behalf.
Where it matters is where you were the only person who knew something — which is far more common than organisations like to admit, and which you are the only person in a position to notice. If there are five facts that exist only in your head, writing those five down is the whole job, and everything else in this post is optional.
Cyanote holds the half that is yours: your work log, your record of what you were promised, your judgement about what was actually going on, in one local database on your own Mac that does not need a company account to keep working. The handover itself belongs in whatever the team uses — but writing it is much easier from a set of notes you have been keeping all along than from four weeks of trying to remember.