Writing Down What Only You Know, Before Anyone Can Take It

The work an owner cannot delegate is rarely the difficult work. It is the work they have done so many times that the decisions inside it have stopped feeling like decisions — which means that when they try to explain it, they describe the sequence accurately and leave out everything that actually determines the result.

Expertise makes the decisions disappear

Ask an experienced owner how they price an awkward job, or how they decide which customer to call back first, and the answer arrives as a description of steps. Look at what they did, and the steps were the least of it. Between each pair of steps sat a judgement that never got mentioned because it no longer registers as one.

This is not evasiveness. It is what competence does. A person becomes fluent by compressing decisions into habits, and habits are not introspectable — you cannot recover a choice you have stopped experiencing as a choice.

The practical consequence is that the honest attempt to hand something over produces a document that is true, complete-looking, and missing the load-bearing part. Somebody then follows it exactly and gets a result the owner would never have produced, and both parties conclude the other one is the problem.

Write down the exceptions before the process

The instinct is to start with the ordinary path, because that is what a procedure feels like it should describe. It is the wrong end.

A competent person can usually reconstruct the ordinary path from context. What they cannot reconstruct is that this particular customer is always called before anything is sent, that this supplier needs a day more than they claim, that jobs of a certain kind are never quoted without a look in person. Those are not general knowledge and they are not inferable, and they are exactly where a reasonable stranger will confidently do the wrong thing.

So the highest-value writing in the whole exercise is a list of the things that are not the general rule. It is also the fastest, because exceptions are memorable in a way that routine is not — an owner can usually produce most of the list in twenty minutes if somebody asks the right question, which is not “how does this work” but “when does this go differently”.

Say what it depends on

The most common stopping point is the phrase “it depends”, offered as though it closes the subject. It opens it.

If a decision depends on something, that something has a name, and naming it is the whole job. Whether a job gets quoted in person might depend on distance, on the customer being new, on the description sounding unusual. Three named conditions turn an unwritable judgement into something a second person can apply and, importantly, into something the owner can be shown to have applied inconsistently.

That second effect is the underrated benefit. Owners who write these rules down routinely discover they have been making the same call two different ways depending on the week. Nothing about the business changed; the rule was simply never held anywhere stable enough to check against.

One page, or it does not get read

Length is where this most often fails after the content is right.

A document is used by somebody in the middle of doing something, usually with a phone in their hand or a customer waiting. At that moment a long document is functionally identical to no document. It gets skimmed, the reader takes their best guess, and the writing has bought nothing.

The discipline is to write for the moment of use rather than for completeness. One page, the exceptions near the top, and no preamble explaining why the procedure exists. If it genuinely will not fit, that is usually a sign that two different tasks have been described in one place and should be separated. The procedure work that holds up over time looks thinner than people expect, and that thinness is the reason it survives.

Test it on somebody who does not know the answer

Nothing an author does can validate their own document, because the author cannot un-know the thing they are testing for.

The only test that works is to hand it to somebody who does not already know and watch where they stop. Every question they ask is a gap, and the gaps are reliably not where the author predicted. This takes about half an hour and it is worth more than another hour of writing.

A company that tried this had a well-written procedure for handling an incoming enquiry, produced carefully by an owner over a weekend. Handed to somebody new, it survived four lines. The fifth step said to record the job type, and the new person had no idea that the company used four specific job types with particular meanings, because that had never been written anywhere — it lived in the heads of the two people who had invented it years earlier. The document was not wrong. It was written by somebody who could not see what they knew.

Record decisions, not just outcomes

There is a difference between a record of what was done and a record of why, and companies keep the first and lose the second.

A file that says a job was quoted at a particular figure lets somebody repeat the arithmetic. A note saying it was quoted that way because access was poor and the crew would lose half a day lets somebody handle the next similar job. The second one is what makes a company able to operate without the person who made the original call, and it costs one sentence at the time.

This is also what gives the documents a company holds their durability. A store of outcomes is an archive. A store of reasons is something a new person can actually learn from, and it is the only version that reduces what the owner has to hold.

Where the writing has to live to survive

Content is most of this, but location decides whether any of it is still there in a year, and the default location is the one that guarantees it will not be.

Written knowledge in small companies tends to accumulate in personal places: a document on one laptop, a note in somebody’s phone, a message thread that happened to contain a good explanation. All of those work at the moment of writing and all of them fail the same way — they are reachable only through the person who made them, which is precisely the dependency the writing was supposed to remove.

The test is simple and unforgiving. Could somebody who joined the company this morning find this without asking anybody? If the honest answer involves a person, the document has recorded the knowledge without relieving anybody of holding it.

Wherever the rest of the work already lives is usually the right answer, because it is the only place people are already in the habit of looking. A procedure attached to the job type it governs gets read. The same procedure in a separate repository of documentation gets read once, during the week it was announced. This is not a claim about any particular tool — it is a claim about attention, and attention goes where the work is.

The second property worth having is that it can be changed by more than one person. A document only its author can edit stops being accurate the first time the process changes, and then becomes actively harmful: a new person follows it, gets a wrong result, and learns that the written material cannot be trusted. One stale document does more damage than none, because it removes the reason to look at the others.

Do it while nothing is urgent

Written calmly, all of this is a description of how a company already works. Written the week somebody starts, it becomes a hurried reconstruction of whatever happened most recently, which is a considerably less reliable thing.

The order that works is unglamorous: pick the function that most often interrupts the owner, list its exceptions, name what its judgements depend on, keep it to a page, and have somebody who does not know the answer try to use it. That is a couple of hours, and it is the precondition for any of the routes in the rest of this cluster actually working — whether the work eventually goes to somebody employed, spread across the team, or run by a desk elsewhere.

Nothing moves before it has been described. The description is the work.