Handing over to someone who has done your job before is one problem. Handing over to someone who has never done it — a new hire, a junior colleague stepping up, or a generalist absorbing your role — is a different problem entirely. They don’t know what they don’t know. This guide shows you how to write a handover that actually works for someone starting from zero.
Why this handover is different
When you hand over to a peer, you can rely on shared context. They already know how the team works, who the difficult clients are, and which tools matter. You can write “the usual QBR process” and they’ll fill in the blanks.
When you hand over to someone new, every assumption you make becomes a gap. They will read your document, hit something they don’t understand, and either guess or get stuck. Both outcomes are bad. The whole point of writing this handover is to prevent that moment.
Start with context, not tasks
Most handover documents jump straight into projects and to-dos. For a new person, that’s the wrong order. They need a frame first. Without it, every project description sounds equally important and equally confusing.
Open with three short sections before any task lists:
- What this role exists to do. One paragraph. Why does the company need someone in this seat?
- Who this role works with. The team, the manager, the cross-functional partners, the external contacts. Name them and say what each relationship is for.
- What a normal week looks like. Mondays are X. Wednesdays you do Y. End of month is Z. This single section saves more confusion than any other.
Explain the things you think are obvious
The hardest part of writing for someone new is noticing your own assumptions. You’ve been doing this job long enough that “just check the dashboard” feels like a complete instruction. To a new person, it’s three questions: which dashboard, where, and what am I looking for?
A useful exercise: read each instruction in your handover and ask “could someone do this on their first day, with only this document?” If the answer is no, add the missing piece. Usually it’s one of these:
- Where the thing lives (link, folder path, system name)
- Who to ask if it breaks
- What “done” or “normal” looks like
- What to do when the standard process doesn’t apply
Document the unwritten rules
Every team has them. The Friday meeting that’s technically optional but actually mandatory. The director who needs decisions in writing, not in Slack. The client who responds to email but ignores calendar invites. A peer would pick these up by osmosis. A new person won’t.
Write a section called something like “How things actually work here” and put the unwritten rules in plain language. This is the section that will save your successor the most embarrassment.
• Marcus (CFO) wants any spend over £5k flagged in advance, even if it’s in budget.
• Engineering standups start late by ~10 minutes. Don’t join exactly on time.
• The “monthly numbers” deck is due the Tuesday after month-end, not the first of the month.
• Don’t bring up the 2024 platform migration in front of the leadership team. Long story.
Prioritise the first month
A new person can’t absorb everything at once. If your handover treats every project equally, they’ll spend their first week paralysed. Help them by ranking what matters.
Add a section near the top called “What to focus on in your first 30 days.” List five to seven things, in order. Be specific:
- Week 1: meet these five people, get access to these three systems
- Week 2: shadow the Tuesday client call, read the Q1 strategy doc
- Week 3: take over the weekly status report
- Week 4: own the next QBR, with the manager backstopping
Everything else can wait. A ranked list of “not urgent yet” items is fine, as long as it’s clearly labelled.
Give them a safety net
However good your document is, the new person will hit something it doesn’t cover. Plan for that explicitly. End the handover with a section called “If you’re stuck” and list, in order:
- The colleague who knows the most about each major area (one name per area, not a committee)
- Your manager, for anything that needs a decision
- You — if you’ve agreed to be available for questions for a defined period
Walk through it with them, live
For a new person, the document is necessary but not sufficient. Block 60 to 90 minutes to walk through it with them on a call or in person. They will ask questions you didn’t think to answer, and those questions reveal the gaps you should fix before your last day.
If they haven’t started yet, walk through it with your manager instead. Your manager can’t do the role, but they can flag the parts that aren’t clear and surface them with the new person on day one.
If you’re working in Google Workspace, OneLast.Day reads your Gmail, Calendar, and Drive and drafts the handover for you — surfacing the projects, contacts, meetings, and recurring commitments a new person would otherwise have to discover the hard way. It gets you to a strong first draft in minutes, so the time you have left can go on the parts only you can write: the unwritten rules, the priorities, and the live walkthrough.
Build the first draft in minutes
OneLast.Day reads your work data and drafts the handover, so your time goes to the parts only you can write.
Create my handover documentOne-time payment · $20 USD · No subscription