Someone on your team just resigned. After the initial gut-drop, your brain jumps to the obvious question — who covers their work? — and your first instinct is probably to ask them to "write up a handover doc." Four weeks later they walk out the door, you have a tidy document, and within a fortnight things start quietly falling over: a report nobody knew was manual, a vendor who emails a person who no longer exists, a script that runs every Tuesday and now doesn't.
Here's the takeaway up front: a handover is not a documentation exercise, it's an extraction exercise — and the work that breaks your team is never the work someone thought to write down. People document their job description. What actually leaves with them is the accumulated, invisible layer: the recurring obligations, the informal relationships, the workarounds, the "oh, I always just check that on Fridays." Your job in the notice period is to drag that layer into daylight, decide what really needs to survive, and put a named human on each piece before the leaver's last day.
Here's a process you can run, in order, starting today.
Days 1–2: stabilise before you plan
Before any handover work, three things need handling.
Respond well to the person. Whatever you feel, say a version of: "Thank you for telling me directly. I want you to leave well, and I'd like your help making the handover clean." Someone who feels respected on the way out gives you the good stuff — the caveats, the risks, the "honestly, this process is held together with tape." Someone who feels punished gives you a document.
Talk to HR before you talk to anyone else. Notice periods, final pay, references, restrictions, and what you may and may not say to the team are governed by your contract and by local employment law, and both vary. Get your HR or legal contact to confirm the boundaries first rather than improvising them.
Tell the team deliberately, not accidentally. Agree with the leaver what will be said and when, then say it yourself, once, to everyone at the same time — before the corridor version gets there. Keep it short, warm, and free of speculation about why. Then immediately follow it with the thing your team actually wants to know: what happens to the work. Even "I don't know yet, I'll have a plan by Friday" beats silence, because silence gets filled with "are more people leaving?"
Step 1: Build the inventory (not the documentation)
This is the step that decides whether the handover works. Book 45–60 minutes with the leaver, sit down together, and build a list — not prose. Prompt them across four buckets, because each hides a different kind of invisible work:
Recurring commitments. Anything that happens on a rhythm: the weekly report, the monthly reconciliation, the standing meeting they run, the on-call rotation, the quarterly access review. Ask literally: "Walk me through your typical week. Now your typical month. Now anything that only happens once a quarter or once a year." That last question catches the annual renewal that will otherwise surprise you in eight months.
In-flight work. Everything currently open, with an honest status. Not "on track" — actual status, what it's waiting on, and what they're worried about.
Access, accounts, and systems. What they can get into that others can't. Shared mailboxes, admin rights, vendor portals, a domain registered under their name, the phone number on an account, scheduled jobs running under their login. This bucket is boring and it is the one that bites hardest three months later.
Relationships and context. Who they talk to outside the team to get things done — the person in finance who fast-tracks things, the supplier contact, the colleague who knows the old system. Also the unwritten context: which decisions were already tried and rejected, and why.
Do this together, in one sitting, not as homework. Asking someone to write it alone gets you their job description. Asking questions in the room gets you "…oh, and I suppose I'm the one who approves those."
Step 2: Triage — what transfers, what stops, what waits
Now resist the urge to redistribute everything. A departure is one of the few honest opportunities you'll get to audit a role, and some of what's on that list shouldn't survive.
Sort every item into three piles:
- Transfers. It matters, it's ongoing, someone must own it from day one.
- Stops. A report nobody reads, a meeting that outlived its purpose, a manual step that exists because of a problem fixed a year ago. Kill it deliberately and say so out loud, so it doesn't get silently resurrected.
- Waits. Real but not urgent, and better handled by the replacement than by a stressed teammate covering two jobs. Park it with a date, not a vague "later."
The test for "stops": if this simply didn't happen for a month, who would notice and what would break? If you can't name the person or the consequence, it's a candidate. Be honest that some things will get worse for a while — that's the cost of a departure, and pretending otherwise is how you burn out whoever absorbs the slack.
Step 3: Name an owner for every transfer — before anything gets written
Every item in the "transfers" pile gets a named person, not a team. "The ops team will pick this up" is how things fall through, because shared ownership is nobody's ownership.
When you assign, state the level of authority along with the task — whether they decide alone, recommend and check with you, or just execute. That single sentence prevents the new owner from bouncing every judgement call back to you during the exact weeks you're least able to absorb it; the mechanics are in our guide to delegating at the right level.
Do this before asking for documentation, because it changes what gets written. A doc written for "whoever ends up doing this" is generic and useless. A doc written for Sam, who already knows the system but has never touched the vendor portal is short, specific, and actually gets read. Have the leaver write to a named reader.
Where should it all live? Wherever your team already looks — the shared task tool, the team workspace, the runbook folder. The one rule: it must not live in the leaver's personal drive, notebook, or inbox. A handover stored somewhere only the leaver can reach is not a handover.
Step 4: Shadow, then solo — the only transfer that sticks
Reading a document teaches you that a process exists. Doing it teaches you to do it. So for anything genuinely important, run two passes inside the notice period:
- Shadow. The new owner watches the leaver do it and asks questions.
- Solo. The new owner does it, the leaver watches and stays quiet unless something's about to break.
That second pass is where the gaps surface — the undocumented login, the step that only works if you refresh first, the approval that has to come before the other approval. Better to find those while the leaver is still sitting next to you.
Schedule the solo pass early enough that the recurring item comes round at least once more before the last day. If the report runs monthly and there are four weeks of notice, that's your calendar planned for you.
Step 5: The last week
Three things, and then you're done.
The access sweep. Walk the systems list with the leaver and with whoever runs IT and HR. Transfer ownership of anything registered to them personally, reassign shared mailboxes and calendar invites, redirect their email to a real person rather than to a void, and note anything scheduled to run under their account. Set an auto-reply that names a successor instead of saying "no longer with the company," full stop.
The final sweep question. Ask, plainly: "What are you worried will break after you leave? What do you know that nobody else knows? What would you fix if you were staying?" Asked in the last week, when the person has nothing left to protect, this reliably produces the most useful five minutes of the entire handover.
A short, human goodbye. Say thank you in front of the team. The people staying are watching how you treat someone leaving, and it tells them what to expect if it's ever them.
Step 6: The 30-day check
Put a reminder in your calendar for a month out and ask the new owners three questions: What have you hit that wasn't in the handover? What's taking longer than expected? What are you still guessing at? This is when the real gaps appear, and it's your last chance to fix them cheaply — while a former colleague might still answer a friendly message, and while the pain is fresh enough to be worth documenting properly.
Then close the loop: fold what you learned into the onboarding plan for the replacement. The handover inventory you just built is, almost line for line, the ramp-up map for whoever comes next.
FAQ
How long should a handover take?
Use the notice period you have, but front-load it. Build the inventory in the first few days rather than the last week — everything else (triage, assigning owners, shadow-then-solo passes) depends on it, and recurring tasks need to come round at least once with the new owner driving. A handover squeezed into the final three days is a document handoff, not a transfer.
What if the person leaving is disengaged or unhelpful?
Lower your ask and raise the structure. Instead of "write up your handover," run short, specific working sessions with direct questions you've prepared. Most disengagement is about feeling written off, so being straightforwardly respectful helps more than escalating. Where behaviour genuinely breaches obligations, that's a conversation for HR rather than something to manage alone — and in the meantime, prioritise the access sweep and the recurring commitments, which are the items that hurt most if missed.
Should I tell the team before or after I have a plan?
Before — but pair the news with a commitment to a date. People fill silence with worse stories than the truth. Say what's happening, say you're working out coverage, and name when you'll come back with specifics. Then actually come back on that date, even if the answer is partial.
How do I stop the rest of the team burning out covering the gap?
Use the triage step honestly. If everything in the leaver's role gets redistributed, you've quietly given people a second job. Kill what can be killed, park what can wait, name what's being consciously dropped, and say out loud which things will be slower until a replacement is in. Making the trade-off visible is what stops it landing as resentment. The broader habits for protecting a team under pressure are in our guide to leading people.
Do I need an exit interview as the manager?
Formal exit interviews usually sit with HR, and there's a good reason to keep them separate — people are more candid with someone who isn't their manager. What you should do is your own version: a short, low-stakes conversation about what would have made the job better. Ask it because you want the answer, not to change their mind about leaving.
Next step
Handovers don't fail for lack of goodwill; they fail because "write a handover doc" outsources the hardest part — noticing the work nobody thinks to mention. Sit down together, build the inventory across the four buckets, cut what shouldn't survive, put a name on everything that should, and make the new owner do it once while the leaver watches. That's the whole method, and it fits inside any notice period. To keep ownership visible after the handover — and to compare the project-management, HR, and team collaboration tools that make "who owns this now?" answerable at a glance — browse the compared shortlists at YouManageIt.
