Running a handover — Patter

The case

The problem with handing over a process is that the person doing it usually knows it too well. They know which steps matter and which are formalities. They know the exception that happens every third month. They know that one dependency is unreliable and you work around it on Tuesdays. None of that is written down anywhere, because why would it be — they’re the one doing it.

So the handover becomes a summary of the official version, the other person nods along, and two weeks later they’re back asking questions that couldn’t have been anticipated because the questions only arise when you’re actually running it.

The fix isn’t more documentation. It’s a different sequence: reconstruct the real process first, then write it down, then watch someone else run it before you step back. The watching part is where the gaps surface — and they always surface.

A process hasn’t been handed over until someone else has run it without you. Everything before that is preparation.

Process Handover

List every step in the process from memory. Don't consult documentation yet. What you can recall without prompting is roughly what the other person needs to know.
Check your list against any existing documentation. Note gaps and contradictions. The documentation is often out of date.
Add the undocumented details. Edge cases, exceptions, the thing you do when step 4 breaks. This is the part only you know.
Identify the dependencies. Tools, access, credentials, other people. Everything the process touches.
Confirm the other person has everything they need to run it. Check access before the meeting, not during it.
Write the handover document. Steps in order, dependencies noted, exceptions flagged. Enough that they could run it without you present.
Identify the two or three things most likely to go wrong. What breaks, what the fix is, who to call if it can't be fixed quickly.
Run the walkthrough. Talk them through it once in full. Don't let them drive yet.
Have them run it while you watch. Don't interrupt unless something is actually wrong. Note what they miss.
Cover what they missed. Brief, specific, no more than necessary.
Run it again if there were significant gaps. @9 if so.
Agree on what happens if something breaks after you're gone. A name, a document, a channel. Not "just message me."
Confirm they're ready to run it solo. Their assessment, not yours.

Make it yours

Step 3 is where most handovers fail. The documented version of a process is rarely the version that actually runs — there's always a workaround for the thing that never got fixed, a shortcut that became standard, a check that exists because of one bad incident three years ago. If you skip this step, you're handing over an incomplete picture.

The watch-them-run-it step (9) is non-negotiable if the process has any real complexity. Hearing someone confirm they understand is not the same as watching them do it. What they skip or hesitate on tells you more than any question you could ask.

For a simple process, steps 6 and 7 can be combined into a single short document. For anything with significant failure modes — client-facing, financial, operational — they should stay separate. The "what breaks" document is the one they'll actually open under pressure.

Once you've run a handover this way a few times, step 1 gets easier. You start documenting processes as you run them rather than reconstructing them at the end. That's a different habit, but it makes this one faster.