Documenting the minimum: so a holiday doesn't stop the business

Almost every company has someone things stop working without. Not because they hoard anything, but because over the years they've accumulated in their head everything nobody wrote down: how that unusual client gets invoiced, where the bank portal login lives, why things were set up this way in the first place. While they're around, everything runs. When they take a holiday, fall ill or leave, the problem that was there all along finally shows itself. The decision this article is about isn't "document more": it's deciding what has to be written down so the operation doesn't depend on anyone's memory — and what you can leave out without guilt.

The holiday test

There's a simple way to find out whether you have a documentation problem, and it doesn't require auditing anything: imagine the key person in each area goes away for two weeks, unreachable. What stops? What slips? What gets done badly because nobody knew how it was done?

Whatever stops in that thought experiment is your priority list. You don't need any more sophisticated criterion to start: minimum documentation exists so that a normal absence — a holiday, sick leave, a departure — is an inconvenience rather than a crisis. If something wouldn't stop, it probably doesn't need urgent documentation, however deserving of a page it might look in some ideal wiki.

Worth saying plainly: this isn't about distrusting anyone. The person who knows everything is usually the first to want it out of their head. Carrying the operation around in your memory is exhausting, turns every break into half a break, and makes delegating impossible. Documenting the minimum protects the business and frees the person.

Why "document everything" ends in a dead wiki

The usual reaction to the scare is the opposite of the solution: set up a documentation space, ask everyone to write up their processes, consider the matter closed. Months later there are dozens of pages nobody reads, half of them out of date, and the operation still depends on the same people.

It happens for a simple reason: documenting has a cost, keeping documentation true has an even bigger one, and that cost only pays off where the risk justifies it. When the goal is "everything", effort gets spread evenly across the critical and the trivial, the trivial wins on sheer volume, and what's written ages faster than anyone can maintain it. Out-of-date documentation is worse than none: it gives wrong instructions with the appearance of truth.

The alternative isn't documenting everything better — it's documenting very little, well: what the holiday test points at, and nothing more until that little is alive and working.

What does have to be written down

Three blocks. If all three are covered for your critical areas, you have minimum viable documentation.

Access

The most urgent block and the least glamorous: which accounts, systems and services the company uses, who can get into each one, and how access is recovered if the usual person isn't there. Include the things nobody looks at until it hurts: the domain and email, online banking, government portals, the ERP or CRM, and the services contracted in a person's name rather than the company's — a classic that only surfaces once that person is gone.

This is not about listing passwords in a shared document. It's about knowing what exists, who can get in, and what the recovery path is. Credentials belong in a proper password manager; the inventory belongs in writing.

Critical processes

Not all processes: the ones the holiday test surfaced. Invoicing, running payroll, fulfilling an order, handling a serious incident. And it doesn't call for prose: a list of steps that a reasonable member of the team could follow without phoning anyone. What gets done, in what order, in which system, and what to do with the usual exceptions — which is precisely the part that lives in someone's head and never gets written down.

The quality bar isn't completeness, it's whether it works: if someone who has never done the task can carry it out with the document in front of them, it's well documented. If they can't, its length is irrelevant.

Decisions

The block almost nobody writes and the one most missed later: why things are the way they are. Why this system was chosen and not another, why that client is invoiced differently, why this process has that apparently absurd step. Without that context, whoever comes next undoes correct decisions because they look arbitrary, or preserves arbitrary ones because they look deliberate.

It doesn't demand a solemn format: a few lines per meaningful decision — what was decided, when, why, what alternatives were rejected — save you from replaying entire conversations every time someone new asks "why on earth is it like this?".

What you can leave out

With the same honesty: don't document what the market already documents (how to use a standard tool — that's what its help pages are for), what changes so often the write-up will be born old, or what is only ever executed by the person who already masters it and will keep doing so. And be suspicious of documentation written for a hypothetical future reader who doesn't exist: if nobody is going to consult it within the next year, it's probably not time to write it yet.

Leaving things out isn't a gap. It's what makes keeping the important part alive sustainable.

How it stays alive without becoming bureaucracy

Three conditions are enough. First, every document has an owner: one named person responsible for it staying true, just as a critical piece of data has an owner. Second, it gets updated when the process changes, not in periodic reviews that never happen: the change and its documentation are one movement, not two tasks. Third, it gets used: documentation that is consulted corrects itself, because whoever uses it spots what no longer matches reality. A good habit: cover planned absences with the document in hand, not with phone calls — every holiday becomes a test.

If the exercise reveals you don't even know which systems you have or who each one depends on, that initial picture is exactly what a data & systems assessment produces: before documenting, know what's there.

Four questions to check you have the minimum

1. If your key person vanished for two weeks, what would stop? Is how to do it written down?
2. Do you know what access exists, who holds it, and how to recover it?
3. Could someone on the team run a critical process with only the document in front of them?
4. Does each document have an owner — or does "everyone maintains it", which means nobody does?

If any answer is "no", that's where the work is. It isn't a big project: it's a short list, well chosen and kept alive. That's documenting the minimum — and it's far more than most companies have.