We audited our own systems. The how-to lived in people's heads.

Every live system we run had the same gap. The steps to release a change existed mainly in someone's head.

We found it on Wednesday, at the end of a structural audit of the software we build and run, across eight separate systems. We were looking for problems in how things were built, not for one bad bug, and the most uncomfortable finding turned out not to be in the code at all.

On none of the live systems was there a written, repeatable release procedure that a second person could pick up and follow. In several places, the written instructions that did exist contradicted what the software actually did. And across the estate we found the same handful of habits repeated, because everything had been built the same way by people moving fast.

The audit's own summary called them habits, not bugs. That framing stuck with us. A bug you fix once. A habit you fix by changing how you work.

We are a firm that tells other firms to write things down. So we are writing this down.

The same habit, outside software

Strip away the technical detail and the pattern is one every owner-run business will recognise. Something important gets done regularly. One person knows how. They do it from memory, it works, and because it works nobody asks them to write it down. Over time, the only documentation that exists is the person.

In a non-software firm it looks like this:

• Month-end close, done by the finance officer from a mental checklist.
• Payroll adjustments for overtime and advances, known only to the person who runs payroll.
• The order in which a site is shut down and secured at the end of a contract.
• How to set up a new customer in the accounting system so their invoices come out right.
• Which supplier to call when the usual one is out of stock, and what to say.

Each of these runs fine until that person is sick, on leave, or gone. Then the business finds out in one bad week how much it depended on them.

Why written instructions drift

The second finding, documents that contradicted reality, is worth dwelling on because it is the trap that catches firms who do write things down.

Instructions are usually written once, when something is set up. The process then changes in small ways. A step gets skipped because it turned out not to matter. A new step gets added after a mistake. Nobody updates the document, because the people doing the work do not need it. Two years later the document describes a process that no longer exists, and a new person following it carefully will get it wrong.

That is arguably worse than having nothing, because a document looks authoritative. The same is true when an AI reads it. An assistant asked "how do we close the month?" will follow the stale procedure with complete confidence.

What we are changing

For our own systems, the plan is to write each release procedure as steps that someone other than the author has followed successfully, and to treat the procedure as part of the system. Change the process, change the document in the same piece of work. Not later.

We also put the recurring habits into our company memory, the shared written record every AI working session reads before it starts, so that new work can be checked against them instead of repeating them. That will not undo the existing problems. It should stop us adding new ones of the same kind, which is the cheaper half of the fix.

The test for your firm

There is an old name for this: the bus test. If one person were unavailable tomorrow, which parts of the business would stop or go wrong?

Take an hour this week and list the five recurring tasks in your firm that only one person can do. For each, ask that person to talk someone else through it once while the second person writes it down as numbered steps. Then have the second person do the task next time, with the original person watching but not helping.

Wherever the second person gets stuck, the document is missing something. Fix it there and then. The procedure is done when someone who did not write it can follow it.

Check how dependent your operation is on single people at pgco.world/tools/os-health, or book 20 minutes at pgco.world/book.