How to Document How You Work for Your Team
Why this matters
There is a class of work in every shop that only the owner does, that nobody has ever seen done start to finish, and that has never been written down. Not because it is secret, but because it is fast and habitual and there has never been a reason to slow it down. That work is the reason a week off is hard, and it is the reason handing something over usually produces a worse version of it.
The obstacle is not willingness. Owners who sit down to write these procedures produce documents that are confidently wrong, because the parts they perform automatically are invisible to them. This article is about the capture method that gets around that, not about writing standing decision rules for recurring questions, which is a different job with its own procedure.
Step 1: Pick the task with three gates, not by gut feel
The candidate list is long and most of it is not worth capturing. Use three gates, and require all three:
- It happens at least twice a month. Below that, the document goes stale between uses and you will rewrite it anyway.
- It has no written form today, not even a checklist someone made once.
- Getting it wrong costs more than about an hour to unwind, or costs a customer relationship. If the cost of a wrong outcome is trivial, let someone learn it by doing it badly twice.
The gates matter because the natural instinct is to document the biggest, most complex thing you do, which is usually rare, judgment-heavy and the worst possible first capture. Pick something ordinary and frequent. The method is what you are learning on the first pass, not the content.
If you skip the gates, you will spend a Saturday producing a long document about an annual task, discover next year that half of it changed, and conclude that documentation does not work.
Step 2: Accept that you cannot write this from memory
This is the load-bearing step and it is the one people skip.
When you have done something a few hundred times, the parts you have automated stop being available to introspection. You do not experience them as steps. Ask an experienced tech how they knew a unit was the wrong one before they opened anything and you will get "it just did not look right," which is true and useless. Ask an owner to write down how they price a non-standard job and you will get a document that produces the wrong number, because the four checks they run without noticing did not make it onto the page.
The consequence is procedural: do not sit down and write it. Narrate it while doing it, and have someone else do the writing. Everything below follows from that.
Step 3: Set up the capture on a real instance
Three requirements. A real instance, not a demonstration - a demonstration skips the awkward parts, which are where the knowledge is. A second person to write, ideally the person who will eventually do the work. A recording as backup, phone voice memo is fine, because the writer will miss things and reconstructing from memory reintroduces the exact problem you are working around.
Allow roughly three times the normal duration. Narrating while working is genuinely slower and pretending otherwise is how the session gets cut short at the interesting part.
Step 4: Narrate decisions, not motions
Motions are easy to observe and mostly worthless on the page. What the writer cannot see is why you went left. So at every point where you could have done something else, say four things out loud:
- What you looked at. The specific thing: the note on the account, the tone of the call, the date on the last visit.
- What you compared it to. The threshold, the previous case, the standard.
- Which way you went.
- What would have made you go the other way. This one is the highest-value sentence in the whole session and the one you will forget to say. It converts a step into a rule.
The writer's job in the room is not to make it read well. It is to capture those four things at every branch and to interrupt with "what would have made you do something else there?" whenever you move past a choice without narrating it.
Step 5: The observer writes the first draft, within 24 hours
Not you. Two reasons, and the second is the one that matters.
The first is simple: they will write what they actually understood, which is a direct measurement of whether the capture worked. Where the draft is vague, the capture was thin, and that tells you where to go back.
The second is that a document written by the expert is written for the expert. It will use your shorthand, assume your context, and skip the parts you consider obvious - which reproduces the original problem in written form. A draft written by a competent non-expert is readable by the next competent non-expert, which is the entire point of the exercise.
Within 24 hours, because the recording only partly compensates for a cold memory of the room.
Step 6: Edit for errors and missing branches only
You get to correct three things: factual errors, missing branches, and wrong thresholds. You do not get to fix the phrasing, reorganise the order, or make it sound more professional.
This will be uncomfortable. The draft will read as clumsy and over-explained to you, because you are the one person for whom it is over-explained. Every time an owner rewrites the draft in their own voice, the document gets shorter, more elegant and less usable, and the person it was written for stops being able to follow it.
Mark each missing branch by adding it in the same four-part shape from Step 4: what to look at, what to compare it to, which way to go, what flips it.
Step 7: Test on a live instance with a third person, and count stop points
The test is not "read it and tell me if it makes sense." The test is a live instance, done by someone who was not in the capture session, working from the document alone, with you present and silent.
Count stop points: every moment the person stops and asks a question, or does something wrong that the document should have prevented. Silence is hard and it is the whole test - answering the first question destroys the measurement, because everything after it is a conversation, not a document.
The pass condition, stated as a rule: 2 or fewer stop points on one live instance, AND the person's decisions match the ones you would have made on at least 4 of the next 5 live instances they run alone. Both gates, not either. A document can be perfectly followable and still produce the wrong answer, and it can produce right answers only because the person is asking you privately afterwards.
Step 8: Fix the stop points, and only the stop points
Second pass revises exactly what the test exposed. Resist the urge to improve other parts while you are in there. An untested revision is a guess, and the document's whole authority comes from having been run against a real person on real work.
Date the document and put a review trigger on it: revisit whenever it produces a wrong outcome, or whenever the underlying process changes, not on a calendar. Calendar reviews of documents that are working are how documentation programs die.
A worked capture: the emergency-slot decision
The task: every morning, more calls want same-day service than there are same-day slots, and the owner decides which one gets the slot. He does it in about 12 minutes and has never written down how. It happens daily, so it clears the frequency gate. Nothing is written, so it clears the second. A wrong call means a customer waits who should not have, which clears the cost gate.
Capture. The office lead sat in with a notepad and a voice memo running. The session took 35 minutes for work he normally does in 12, roughly three times, which is what Step 3 said to expect. She interrupted eleven times with the Step 4 question. Six of those eleven produced a branch he had not narrated, including one he could not explain until the third attempt.
Draft one: 14 steps and 6 decision points, written by the office lead the same afternoon.
His edit: two factual errors, one wrong threshold, and three missing branches added in the four-part shape. He also rewrote two paragraphs to sound better, then reverted them after the test, for reasons that follow.
Test. A dispatcher who had not been in the room ran a live morning from the document with the owner silent. Nine stop points. Well past the pass condition of 2 or fewer. Two of those nine landed on the paragraphs he had rewritten for style, which is what sent him back to the original wording.
Second pass. Only the nine stop points were addressed. The document grew from 14 steps to 19, which is the normal direction: a document that shrinks after a failed test has usually had the difficult parts deleted rather than clarified.
Retest. 2 stop points on a live morning. First gate cleared.
Second gate, the next 5 instances run alone. The dispatcher's decision matched the owner's on 4 of 5. The mismatch was a customer with a history the document did not account for, where the owner would have taken a lower-urgency call first because of a service failure two months earlier. Both gates cleared, at 2 stop points and 4 of 5, so the document passed - and the single mismatch still bought the most valuable thing in the exercise, which was a factor he had been applying for years without ever having named it. It became decision point 7.
Total investment: 35 minutes of his time in capture, about 40 minutes editing across two passes, and two mornings of standing there not talking. Against roughly 12 minutes a day he had been spending, five days a week, on a decision that now routes to someone else. The comparison worth making is not hours-for-hours: those 12 daily minutes came out of his morning, which is the block where the day's structure is set, so what he bought back was the shape of the morning rather than an hour a week.
When the test says the problem is not the document
Watch for one specific result: the person hits few stop points, follows the document faithfully, and still mismatches you on 2 or more of the 5 instances. That is not a documentation failure. That is you being inconsistent, and the document has just measured it.
The fix is not more detail. It is to sit with the mismatched cases, decide what the rule actually is now, on paper, with nobody waiting, and put that rule in the document as a threshold with a number on it. Owners find this genuinely unwelcome, because "it depends" has been a workable answer for years. It stops being workable the moment you want anyone else to do the work.
The related trap is documenting the exceptions into the ground. If the document keeps growing because each new case adds a branch, the underlying decision has too many inputs and the honest move is to cut inputs - to decide that one factor no longer counts - rather than to keep capturing them. A decision with 6 factors can be taught. A decision with 15 cannot, and it was probably not being made consistently by you either.
References
- U.S. Small Business Administration (SBA), small business operations and process documentation guidance
- Trade-standard practice, procedure capture and on-the-job training in small service shops
- See related: How to Stop Being the Answer to Every Question, How to Write a Handoff That Does Not Come Back, The Owner's Personal Operating Manual, Delegating the Decision Not Just the Task, How to Hand Off a Recurring Task Permanently