The job handover checklist: what to hand over when a role changes hands

Why handovers fail, and why it is not about effort

The handover documents I have read were rarely lazy. Most were long. They listed the projects, linked the folders, named the clients. And two weeks after the person left, the new one was still messaging them to ask why the Acme renewal had never been confirmed.

The document existed. The reason was not in it.

That is the pattern. Handovers do not fail because nobody wrote anything. They fail because what gets written is an inventory of things, and what the next person needs is the reasoning around the things. Where the inventory says "Acme renewal, 30 November", the successor needs "Acme renewal, 30 November. Not confirmed yet because their legal team wants the liability clause reopened. Sam on their side knows. Do not send the standard renewal email."

Three habits produce inventories instead of transfers.

• It is written too late. In the last week the leaver is wrapping up, saying goodbye, and mentally already somewhere else. What they write in that state is a list.
• It is written alone. The leaver decides what matters, nobody reads it while there is still time to ask questions, and the successor, if one exists, never gets to say what they are worried about.
• It is written for the wrong reader. Most handover documents are written to prove that a handover happened. They should be written for one specific person opening them on a Tuesday afternoon with a problem.

Fix those three and the rest of this article is detail. One word before we get to it: I will say "leaver" for the person leaving the role, whether they are leaving the company, going on leave for six months, or moving two desks over to a new team. The handover is the same job in each case. Only the deadline changes.

Decide who you are writing for

Before anyone writes a line, name the reader. There are only three cases, and they change what you produce.

A named successor is already on the team. The best case. Write less, talk more. The document is a spine for two or three working sessions, and its most valuable part is the successor's own questions, written back into it.

Someone is covering temporarily. Parental leave, a long sick leave, a sabbatical, a manager holding two roles for a quarter. The cover needs to keep things running, not to own them. Write what must not stall, what can wait, and which decisions they may take without the person who is away. Then plan the hand-back now, because the return is a second handover and almost nobody prepares it.

Nobody has been hired yet. The document will sit in a drawer for weeks or months. It has to survive without its author, so everything in it needs the "why": there will be no one to ask. This is the case where the manager has to become the reader and check the document as if they were starting the job on Monday.

If you cannot name the reader, write for the manager. They are the one who will get the call.

The timeline

Four weeks is comfortable. Two is workable. Three days is what most people get, and you can still do the essentials in three days if you know which ones they are. Here is the four-week version. Compress it by dropping the walk-through, never the review.

1. Day 0
   The change is confirmed

   Open the handover, name the reader, and agree on the end date. For leave cover, agree on the return date too.

2. 4 weeks before
   Projects and people

   The leaver writes down what they own, what they promised, and who they talk to about what. Thirty minutes a day beats a Friday afternoon.

3. 3 weeks before
   Access and rituals, first review

   Accounts, shared inboxes, recurring meetings, licences, the calendar entries nobody else sees. The manager reads it once and lists what is missing.

4. 2 weeks before
   The unwritten parts, second review

   Decisions and the reasons behind them, workarounds, what breaks on the first of the month. The manager reads again, this time as the successor would.

5. 1 week before
   Walk-through

   Leaver and successor (or manager) go through the document together and rewrite whatever only made sense to its author.

6. Last day
   Freeze and sign off

   Sign-off means "I have read it and I can find things in it." Agree how questions get answered afterwards, and until when.

7. 1 to 2 weeks after
   Questions, written back

   Every question the successor asks is a gap in your checklist. Add the answer to the document and the question to the list.

Two variants are worth knowing. For an internal move, the person is still in the building, which sounds easier and is worse: the old role keeps a fifth of their attention for months and nobody puts an end date on it. Set one. For a sudden departure with no leaver at all, skip to the section on reconstructing a handover below.

The four areas

Every handover I have seen go well covered the same four areas, and every one that went badly skipped the fourth. The questions under each are meant to be asked out loud, in a conversation, before anyone writes anything down.

1. Projects and commitments

Not a project list. A statement of where each thing is and what was promised.

• For each project or recurring responsibility: where does it stand today, and what is the next thing that has to happen, by when?
• What is at risk, and what would you do about it if you were staying?
• What have you promised, to whom, that is not written anywhere? A date mentioned in a meeting counts.
• What would surprise the next person in their first month?

2. People

The relationship map is the part successors ask about most and documents cover least.

• Who should the successor meet in their first week, and what should they talk about? Five names, not fifty.
• Who are the people outside the team this role depends on, and what does each of them care about? The client contact who only answers the phone. The finance partner who needs the form by the 25th.
• Who do you go to when you are stuck, and for what?
• Is there a relationship that needs care right now, and why?

3. Access and rituals

Boring, and the first thing that stops someone on day one.

• Which accounts, tools, and shared inboxes does the role use, and who owns each one? Ownership matters more than the password: the owner is who you call when it locks you out.
• Where are the credentials actually kept, as opposed to where the policy says they should be?
• Which recurring meetings, reports, and deadlines belong to the role? Which ones can be dropped?
• What is tied to the leaver personally that should not be? An automation running under their account, a domain renewal on their card, a two-factor device in their pocket.

4. How things actually work

The unwritten parts: decisions and why they were made, workarounds that hold the place together, and the history behind processes that look strange from the outside.

• What decisions from the last year will someone want to reopen, and why were they made that way?
• What do you do by hand that everyone assumes is automated?
• What breaks predictably, and what do you do when it does?
• What would you never do in this role that a reasonable newcomer might do?

If you only have three days, do the fourth area first. Projects and access can be rebuilt from systems. This cannot.

Write the why, not just the what

The most useful editing rule I know for a handover: every line that matters gets one sentence of context. Why it is like this. What happens if it is ignored. Who else knows.

The second version is four sentences longer and saves a week. It also passes the only test that matters: a stranger could act on it.

A few more rules that hold up.

• Write "I", "you", and names. "The team usually" hides who actually does the thing.
• Link, do not paste. Point to the living folder, ticket, or dashboard, and say what to look at in it.
• Dates over adjectives. "Urgent" means nothing in six weeks. "Before 15 October" still does.
• If something is sensitive, say who can discuss it instead of leaving it out. Silence in a handover reads as "nothing to see here".

The manager's job: review, do not just receive

A handover nobody reads before the person leaves is a diary. The manager's review is what turns it into a transfer, and it is the step most often skipped, because the manager is busy replacing the person.

Reading it takes an hour. Do it twice: once around week three, looking for what is missing, and once in the last week, reading as the successor would. A few questions expose gaps quickly.

• What would I need to call you about in month two?
• Which line in here only makes sense if you already know the story?
• What is in your calendar for the next quarter that is not in this document?
• If the successor does nothing for two weeks, what breaks first?

Signing off is a real act. It means "I have read this, I can find things in it, and I know what is still missing." Write the missing items down too. A known gap is far cheaper than a hidden one.

Special cases

Leave cover

The person is coming back, so two things change. First, the cover is not meant to take every decision, and you should say which ones. A short list works: decide without me, decide with the manager, wait for me. Second, plan the hand-back before the leave starts: a return date, a note the cover keeps of what changed and why, and an hour blocked on the first morning back.

Internal move or promotion

The leaver is still around, so the handover turns into a slow leak. Old-role questions arrive at all hours and nobody calls it a handover anymore. Set a date after which the old role's questions go to the new owner, put it in writing, and let the leaver enforce it politely. Promotions are the worst version: the person is handing over their old role while learning a new one, and the old one always loses. Give it a fixed slot in their week until the date.

Reconstructing a handover when the person is already gone

Sometimes there is no leaver: a sudden resignation, a dismissal, an illness. You can still build most of a handover. The calendar tells you the rituals and the relationships. The shared inbox tells you the commitments. The last quarter of tickets, pull requests, or deals tells you the projects. Then interview three people: the closest peer, the most frequent external contact, and whoever has been complaining. Write down what you could not find, and give the successor permission to break the rules nobody can explain.

What a good handover feels like on day one

The successor opens one place. They see what is urgent this week, who to meet, what they can log into, and why things are the way they are. When they hit something odd, the answer is a paragraph away, in the leaver's words, with a name attached.

And when they do have to message the person who left, treat it as a bug report against your checklist. Write the question down. Add it to the list. The next handover in your team starts from a better one.

The checklist

Copy this into whatever your team already uses. Tick what applies, delete what does not.

A note on tools

You do not need software for any of this. A shared document and two calendar blocks will get you most of the way, as long as someone names the reader and someone reviews. We built Handov because we kept watching the review and the "why" get skipped under time pressure, and wanted the structure to do the nagging instead of the manager. If a document works for your team, use the checklist and skip us.