The Workflow's Real Documentation Is a Person: Surviving the Builder's Notice Period

Someone on your team hands in their notice. Within an hour, a calendar invite appears: Handover Notes. There will be a shared document. It will contain a list of links, a few file paths, maybe a line about the monthly report, and a sentence that says something like “ask me about the exceptions”. Then the notice period runs out, the leaving card gets signed, and the workflow starts to wobble in ways nobody predicted.

This is not a failure of professionalism. It is a failure of format. Most handovers are written as if a workflow were a set of instructions. In reality, it is a living arrangement of habits, workarounds, vendor contacts, calendar reminders, naming conventions and small acts of memory. The person leaving did not just operate the workflow. For a while, they were the workflow.

The workflow was never in the doc

Standard handover documents are good at the visible bits: where the files live, who to email, which dashboard to check. They are terrible at the bits that keep the thing running on a wet Tuesday in February when a supplier has sent the wrong CSV and the finance system has decided it no longer recognises a cost centre.

Those bits live in someone's head. They are the reason the workflow survived the last reorganisation, the last software migration and the last attempt to “streamline the process”. They are also the first things to disappear when someone leaves, because nobody thinks to write them down until they are needed.

In UK teams, the notice period can be four weeks, three months, or something stranger if garden leave is involved. That sounds like plenty of time. It rarely is, because the person leaving is still doing their day job, still attending meetings, and still being pulled into the same small fires. The handover gets squeezed into the gaps. The gaps are not where the useful knowledge lives.

What actually hides in someone's head

Before you book anything, it helps to know what you are trying to extract. The hidden dependencies usually fall into a few familiar categories.

There are the workarounds. The official process says one thing; the working process says another. A spreadsheet that started as a temporary fix is now load-bearing. A rule in the automation tool has been muted because it kept firing false alerts. Someone manually checks a report every Friday because the integration has never quite trusted itself.

There are the exception paths. What happens when a request arrives after the cut-off? Who approves the thing when the usual approver is on leave? Which supplier gets a phone call rather than an email? These are not edge cases. In most workflows, they are the weather.

There are the relationships. The person who knows which IT engineer can unblock a sync issue. The contact at the vendor who actually answers. The colleague in another department who will quietly fix a data mismatch if you ask nicely. None of this appears in a process map, and all of it determines whether the process works.

And there are the personal automations. The calendar reminder, the saved email template, the browser bookmark, the little script that runs on a laptop nobody else has looked at since 2024. These are the workflow's nervous system. When the laptop goes back, they go with it.

Run the handover hour properly

The phrase sounds modest: one hour. That is the point. A handover hour is not a grand documentation project. It is a structured, recorded walkthrough of the workflow as it actually runs, with the person who knows it best narrating the decisions rather than just the steps.

Book it early in the notice period, not in the final week. Then book a second one. The first session is for the map; the second is for the exceptions that surface once someone has tried to follow the map.

During the hour, do not ask for a tour of the software. Ask the person to process a real piece of work from start to finish while someone else watches and asks “why?” at every fork. Why this field? Why that approval? Why does this one get flagged and that one not? Record the session, with permission, so people can rewatch it later. Screenshots are useful; a voice explaining a judgment call is better.

Keep a live list of every external dependency: logins, integrations, vendor contacts, scheduled jobs, shared inboxes, licence renewals. Assign an owner to each one before the session ends. “Someone should check” is how workflows die.

Make the hour count twice

The most useful output of a handover hour is not a document. It is a named successor. Someone who has watched the work, asked the awkward questions and will now run it while the original owner is still around to correct them. Shadowing beats note-taking because it exposes the gaps in real time.

Use the notice period to run a live swap. The successor handles the next cycle; the leaver observes. When something goes wrong, the leaver explains the fix. That explanation is the handover. It is also the beginning of the new runbook, written in the language of the team rather than the language of the vendor's onboarding guide.

Finally, schedule a check-in for four to six weeks after the leaver has gone. Not a farewell drinks reminder, but a short review: what has broken, what has been missing, what did the handover doc get wrong? Update the document then. A runbook that has never been tested by the person who inherited it is just a hopeful guess.

The test after the leaving card

The real measure of a handover is not how thick the document is. It is whether the workflow still moves when the builder is no longer in the room. That does not require a perfect process map or a six-month knowledge management programme. It requires an hour, a real piece of work, a recording, a named owner and the honesty to admit that the most important parts of the job were never written down in the first place.

The laptop will go back. The workflow does not have to go with it.