Documentation that survives turnover

Documentation is not judged by whether it exists, how complete it looks, or how much effort went into it. It is judged by whether someone who was not here last month can do the thing without asking a person. That is a harsh standard and it is the only one that predicts what happens when somebody leaves.

Most small businesses fail it in the same way. There is documentation, it is largely accurate, and it assumes the reader already knows the surrounding context — which supplier is which, what the folder naming convention means, why there are two customer lists and which one is current. A person who was here absorbed all of that without noticing. A person who was not cannot reconstruct it from the documents, so they ask, and each question is answered by whoever is nearest rather than added to the page.

The practical consequence is that turnover exposes the gaps all at once, at the moment there is least capacity to fill them. Nobody discovers a documentation problem gradually. They discover it in the two weeks after a resignation.

Process documentation gets almost all the attention, and it is one fifth of the problem. The categories that actually bite during turnover are these.

Processes: how recurring work gets done, step by step.

Decisions: why the business does it this way — the supplier chosen and rejected, the pricing structure, the tool nobody likes but cannot be replaced yet. Without this, successors re-litigate settled questions or reverse decisions for reasons that were already considered.

Contacts: who to call at each supplier, which contact is useful versus which is listed, the accountant, the landlord, the person at the bank who actually answers.

Access: what accounts exist, who owns them, which are tied to a personal phone number or a departing person's email. This is the one that produces genuine emergencies.

Recurring obligations: filings, renewals, licences, insurance, contract review dates. These have deadlines and no owner shouting about them until they are late.

A business with excellent process documentation and none of the other four is still one resignation away from a bad month.

One searchable place, with a structure a stranger can navigate, and every reference pointing into it rather than copying from it.

Searchable matters more than organised. People do not browse a hierarchy to find a document; they type two words they remember. A perfectly categorised structure with weak search loses to a flat one with good search, which is why documentation living in a wiki or a shared drive with full-text search beats a beautifully nested folder tree nobody can query.

One place matters because the moment there are two, there are two versions, and the reader cannot tell which is current. This is the most common way documentation becomes actively harmful — not by being wrong, but by being ambiguous about which of two right-looking answers applies.

And pointing rather than copying matters because copies do not get updated. A procedure pasted into a training deck, a chat message and an email is now four documents with one maintained. Link to the canonical page from everywhere, so there is exactly one thing to change and everybody reads the change automatically.

The most common documentation store in a small business is somebody's inbox, and it fails on every property that matters. It is not searchable by anyone else. It has no current version — only the most recent one that particular person happened to receive. It disappears when the account is closed. And it is invisible: nobody can find out what exists without asking the person who has it.

Chat messages fail the same way with a friendlier interface. A procedure explained clearly in a message thread is findable for about three weeks and then effectively gone, buried under volume and unfindable by anyone who does not already know it exists and roughly when it was said.

Personal drives are the subtler version of the same problem. A document in someone's own cloud storage is genuinely accessible, right up until they leave and the account is deprovisioned. The test to apply is uncomfortable and quick: if this person's account were closed tomorrow, what would go with it? In most small businesses the honest answer includes several things nobody has thought about, and the access category is where the answer is most expensive.

Every page needs a named owner and a date of last review, and both need to be visible on the page rather than in a register somewhere else.

The date is doing more work than it appears to. A reader encountering a procedure with no date has no way to calibrate their trust, so they either follow it blindly or ignore it, and both are wrong. A date lets them apply judgement: a procedure last reviewed six weeks ago is probably current, one last touched three years ago needs checking against reality before use.

Ownership should sit with whoever does the work, not whoever manages it, because they find out first when a step stops working. The obligation is to update on change rather than on a schedule — the update trigger is the change itself, which is both more reliable and much cheaper than a recurring review cycle.

Version history matters mainly for decisions. Knowing that a policy changed, when, and ideally why, prevents the recurring argument where two people are each correctly remembering a different version. Most shared document tools keep this automatically, which is a good reason to prefer them over files with dates in the filename.

It cannot capture relationships. Ten years of dealing with a supplier produces knowledge that is real and largely unwritable — how much flexibility exists on a deadline, what they will do as a favour, which of their staff can actually make things happen. You can record the useful facts and the relationship itself does not transfer with the file.

It cannot capture judgement in genuinely ambiguous work. For anything where the skill is deciding rather than executing, documentation can supply the considerations and the boundaries, and a document that claims to supply the decision produces either false confidence or a procedure people quietly work around.

And it cannot make itself get read. This is the failure that surprises people who invest heavily: a complete, current, well-structured knowledge base that nobody enters because nothing points into it. Documentation changes behaviour when it is linked from the moment the work starts — the recurring calendar entry, the task template, the onboarding checklist. Left as a library, it is read once during someone's first week and then remembered as a place where answers might be.

The honest goal is not completeness. It is that no single person's departure creates a problem nobody else can solve.