In short
Do not start by writing a manual. Start by recording the next real instance of your highest-risk process while someone performs it, then edit that recording into a checklist rather than an essay. Document in this order: processes that only one person knows, then processes that are performed most often, then everything else. Documentation that describes what actually happens and lives where the work happens gets used; documentation that describes what should happen and lives in a folder does not.
Key takeaways
- Capture beats authoring. Record someone doing the work rather than asking them to write it up later.
- Sequence by risk, not by tidiness: single-owner processes first, high-frequency processes second.
- Write checklists and decision rules, not narrative prose. Prose is read once; checklists are used repeatedly.
- Documentation that lives away from the work is documentation that rots. Put it where the task is performed.
- A process with no named owner will not stay current, no matter how good the first version was.
Why documentation projects fail before they start
The standard failure looks like this. Someone senior declares that the business needs proper documentation. A template is chosen. A shared drive is created. Three people write thorough documents for the processes they happen to run. Everybody else does not, because they are busy, and because writing about work is a different skill from doing it. Four months later the drive contains eleven documents, six of which are already wrong, and the initiative is quietly not mentioned again.
The diagnosis is almost always the same: the project was scoped as writing when the actual problem is capture. Asking a busy operator to sit down and compose a description of something they do automatically is asking them to do the hardest possible version of the task. They have to remember, sequence, generalise and write, all at once, for a reader they cannot see.
The knowledge is not missing. It is running, in production, several times a week. The problem is that nobody is catching it as it goes past.
The second failure: documenting the ideal
The other common death is documenting what should happen rather than what does. This produces documents that are simultaneously correct and useless: correct because they describe good practice, useless because anyone who follows them will diverge from the real process within two steps and lose trust in the document permanently.
If your real approval process involves messaging someone on WhatsApp because the ticketing system is slow, write that down. You can fix it afterwards. A document that pretends otherwise teaches new joiners a process that does not exist.
What to document first
Sequence is the entire game. Get it wrong and you spend your limited appetite on the wrong things.
Rank every process on two questions:
- How many people can do this without help? If the answer is one, this is a risk, not a process.
- How often does it run? Frequency multiplies the value of the document.
| Order | Profile | Why |
|---|---|---|
| First | One person knows it, and it runs regularly | This is where the business is genuinely exposed. If that person leaves or is ill, revenue or delivery stops. |
| Second | Several people know it, runs very often | Highest total time saved. Also where inconsistency is quietly costing you quality. |
| Third | One person knows it, runs rarely | Real risk, but lower urgency. Capture it opportunistically the next time it runs. |
| Last | Widely known, runs rarely | Often not worth documenting at all. Say so explicitly. |
In practice, most businesses find between four and eight processes in the first row. That is your entire scope for the first pass. Not the whole business — four to eight documents. This is achievable in a month alongside normal work, which is exactly why it works.
For more on the risk this addresses directly, see key person risk and single points of failure.
The capture method: record, then edit
Here is the method, in the order it should happen.
Step 1: catch it live
Wait for the process to run naturally — do not stage it. Have the person performing it share their screen and narrate what they are doing while they do it. Record it. Twenty to forty minutes is typical. The instruction to the performer is important: do it exactly as you normally would, including the shortcuts and the annoying bits.
Step 2: ask the three questions that reveal the real process
Narration captures the happy path. The value is in the exceptions, and those need prompting. Three questions surface most of them:
- “When does this go wrong?” Produces the failure modes and the informal checks people run.
- “What would a new person get wrong here?” Produces the tacit rules that never made it into any system.
- “When do you have to ask someone else?” Produces the dependencies and the undocumented approval gates.
Step 3: edit into a checklist, not an essay
Someone other than the performer turns the recording into a document. This matters: the person who does not know the process is the person who can tell what has been assumed. The output format should be:
- A one-line statement of what this process produces and who receives it
- Preconditions — what must be true or available before starting
- Numbered steps, each an action, each verifiable as done or not done
- Decision rules written as if/then, not as guidance
- Known failure modes and what to do about each
- Who owns this document and when it was last confirmed accurate
Aim for one page. If a process needs four pages, it is probably two processes.
Step 4: test it on a stranger
Have someone who has never performed the process attempt it using only the document, with the original performer watching but not helping. Every question they ask is a defect in the document. Fix them in the same session. This single step does more for documentation quality than any template.
Where documentation has to live
Documentation rots for one structural reason: it is stored somewhere other than where the work happens. A procedure in a wiki that nobody opens is functionally identical to a procedure that does not exist.
The rule is simple. Put the document at the point of use. In practice:
| Type of knowledge | Where it belongs |
|---|---|
| Steps for a recurring task | Attached to the recurring task in whatever tool the work is tracked in — as a checklist template, not a linked file |
| Decision rules and policy | One canonical page, linked from every process that depends on it, never duplicated |
| Reference data (codes, thresholds, contacts) | A single table, ideally in the system that consumes it |
| Rationale and context | Separate from the procedure. Mixing why into what makes the what unusable at speed. |
That last row is the most commonly ignored. A procedure someone follows under time pressure should be scannable. The reasoning behind it is valuable, but it belongs in a linked note, not interleaved with step four.
One source, many links
The moment a piece of information exists in two places, you have created a maintenance obligation you will not meet. Copying the refund policy into three onboarding documents guarantees that at least two of them will be wrong within a year. Link instead, always, even when linking is slightly less convenient to write.
Keeping it current without a documentation team
The maintenance problem is real and it kills more documentation than the authoring problem does. Three mechanisms handle it without dedicated staff.
1. Named owner, visible on the document. Not a team, a person. The owner is not responsible for writing it; they are responsible for it being right. Ownership without a name is ownership by nobody, which is a subject worth its own treatment — see who owns what.
2. Review triggered by events, not by calendar. Annual reviews produce annual rubber-stamping. Event triggers produce real updates. Useful triggers:
- The process failed or produced rework
- A tool in the process changed or was replaced
- A new person was onboarded into it and had questions
- The step count changed
3. Onboarding as the audit. Every new hire is a free, high-quality audit of your documentation. They will find every gap, because they are the only people in the building who cannot fill gaps from memory. Give them explicit permission and a light obligation: as you work through this, fix anything that is wrong or missing. This converts your weakest documentation moment into your strongest.
The number of times a process should be performed from the document by someone other than its original owner before you consider it genuinely documented. One is a test. Three is evidence.
What good looks like six months in
You are not aiming for a manual. You are aiming for a specific set of observable conditions:
- No process in the business has exactly one person who can perform it. This is the headline outcome and the one that changes how the business can be run.
- New joiners reach useful output faster, and the ramp is measurable rather than felt.
- The same question stops being asked. When someone asks a documented question, the answer is a link, and the link works.
- Holidays stop being events. A senior person being away for two weeks is a scheduling matter, not a risk register entry.
- Documents get edited by people who did not write them. This is the strongest signal that documentation has become infrastructure rather than a project.
None of this requires a documentation platform, a template library, or a dedicated hire. It requires deciding what to capture first, catching it as it runs, and giving each document a name attached to it.
If you are not sure which of your processes sit in that first, highest-risk row, the Mayim Ops assessment scores documentation and knowledge as one of ten dimensions, and identifies specifically where knowledge is concentrated in individuals rather than held by the business.
Frequently asked questions
How do I start documenting processes when nothing is written down?
Start with capture rather than authoring. Record someone performing the process live while narrating what they do, then have a second person edit that recording into a one-page checklist. Do this first for processes that only one person can perform, since that is where the business is actually exposed.
What should a process document contain?
A statement of what the process produces and who receives it, the preconditions, numbered verifiable steps, decision rules written as if/then, known failure modes with responses, and a named owner with a last-confirmed date. Keep reasoning and context in a linked note rather than mixed into the steps.
How long should a standard operating procedure be?
Aim for one page. If a procedure needs four pages it is usually two or more separate processes that have been merged, and splitting them makes both more usable. Length is a symptom worth investigating rather than a target to hit.
How do you stop process documentation from going out of date?
Give every document a named individual owner, trigger reviews on events rather than on a calendar, and use onboarding as the audit. New joiners are the only people who cannot fill gaps from memory, so give them explicit permission to correct anything they find wrong.
Should I document the process as it is or as it should be?
Document what actually happens, including the workarounds. A document describing an idealised process loses the reader's trust the moment reality diverges from it, and it teaches new joiners a process that does not exist. Capture reality first, then improve it deliberately as a separate piece of work.