The process that lives in one person's head

Every organisation has at least one. The person who knows how the thing actually works. Not the official version — the real version, with the workarounds and the edge cases and the phone numbers you call when the system does something unexpected. They have been doing it for years. They are good at it. The business depends on them in ways that are not visible until they are gone.

When they leave, the process does not slow down. It stops. And only then does the organisation discover how much of its operational knowledge existed exclusively in one person's memory.

The real cost of undocumented processes

The immediate cost is visible: work grinds to a halt, the wrong people spend weeks trying to reconstruct how something is done, external help gets brought in. But there is a subtler cost that accumulates long before anyone leaves.

When a process is undocumented, it cannot be improved systematically. You cannot audit what you cannot see. You cannot identify inefficiencies in a process that exists only as tacit knowledge. Decisions about tooling, automation, and resourcing get made without accurate information about how the work actually flows. Every change introduces unpredictable risk because nobody has a complete picture of what depends on what.

Undocumented processes also scale badly. The person who holds the knowledge becomes a bottleneck. Everything that requires their involvement requires them specifically — not because the work is genuinely complex, but because the knowledge of how to do it has not been transferred. Growing the team does not help if the new team members cannot do the work without constant supervision from the one person who understands it.

What proper documentation actually looks like

Documentation is not a process manual written in passive voice that nobody reads. That is compliance documentation — it exists to satisfy an auditor, not to transfer operational knowledge.

Proper process documentation captures what actually happens: the inputs, the decision points, the exceptions, the people involved and what they specifically do, the tools used and why, and the failure modes — what can go wrong and how it gets handled. It is written for the person who will have to do this without any help, on a day when the person who previously did it is not available.

The test for whether documentation is adequate is simple: give it to someone who has never done the process and ask them to do it. If they can, the documentation is working. If they cannot, it is incomplete. Most process documentation fails this test immediately.

The difference between documenting a process and documenting what is supposed to happen

This distinction matters more than most people realise. Documentation that describes the intended process is almost useless for operational continuity. It does not tell you what to do when the supplier portal is down, or when three submissions arrive in the wrong format, or when the approval chain includes someone who is on leave.

The real process includes all of those things. It includes the informal fixes and the manual workarounds and the judgment calls that experienced people make without thinking. Capturing that knowledge is harder than writing up a flowchart, but it is what actually makes a team resilient.

The practical approach is to document processes while the person who runs them is still available to contribute. Walk through the process with them, step by step, and ask specifically about exceptions: what happens when this goes wrong, what does someone need to know that is not obvious, who else is involved and when. Record the answers. Then test the documentation with someone else before the original person is no longer available.

This is not a large project. For most operational processes, a thorough documented version takes a few hours to produce. The cost of not doing it is measured in weeks of disruption and, sometimes, in processes that are simply never recovered.