Every business has one person who cannot go on holiday, the quiet cost of a process that lives in someone's head

Ask a business what would break if a particular person were away for two weeks, and watch the pause. There is almost always a name. Sometimes the person says it about themselves.

It is rarely the most senior person. More often it is whoever has quietly absorbed the awkward middle of the operation, the part between the sale and the delivery where the exceptions live. They know which supplier needs the order split into two emails. They know the customer who always pays late but is worth keeping. They know that the figure in column H is wrong on the fourth week of the month and needs adjusting by hand.

Nobody wrote it down, and there is a reason

The obvious response is to tell them to document it. This almost never works, and the reason is not laziness.

A process that lives in someone's head is not a list of steps. It is a set of judgements, most of them about exceptions, learned over years and stored as instinct. Asking someone to write it down asks them to convert instinct back into rules, which is genuinely hard work, on top of a full workload, for a document nobody will read while they are still there to ask.

So it stays where it is. And the business carries a risk it never priced. Not just holidays. Illness, resignation, a better offer, a bad week. The process does not degrade gracefully. It stops.

What we look for

When we map a workflow, this is one of the first things we go looking for, and there are tells.

Work that queues up when one person is out, rather than being picked up by somebody else, is the clearest. A file only one person opens is another. So is a step where the answer to how does this happen is a name rather than a system. And the sharpest tell of all is when two people describe the same process differently and both are partly right, because the real process was never agreed, only performed.

Automation is documentation that runs

Here is the part that changes the economics. When you build the process as a system, the documentation arrives as a by product. The rules have to be stated to be built. The exceptions have to be named to be handled. What was instinct becomes something you can read, change, and hand to somebody else.

That is a different outcome from writing a manual. A manual rots the moment the process changes, because nothing forces it to stay true. A working system cannot drift from itself. If the rule changes, it changes in one place, and everybody is now following the new one whether they read a document or not.

It also does something quieter for the person who was carrying it. They stop being the single point of failure and start being the person who owns the system, which is a better job and a less anxious one. Nobody enjoys being the reason a holiday is inconvenient.

Start with the sentence

If you want a cheap test before anyone builds anything, try this. Pick the process that worries you and try to write it as instructions a competent new starter could follow, exceptions included. Give it twenty minutes.

If you can write it, it can be built. If you cannot, you have just found the thing worth fixing, and you have found it before it found you.