Tribal Knowledge Is Not a System

This is a representative example illustrating the method below. It is a composite scenario, not a specific named client engagement.

The constraint

A professional-services firm looked well-run from the outside. Clients were happy. Retention was strong. Delivery was consistent. Then the senior operations lead announced she was leaving, and the founder discovered — over the course of a very uncomfortable two weeks — that roughly forty percent of "how we do things here" existed exclusively inside her working memory.

Not in a wiki. Not in a checklist. In her head.

What was actually happening

The firm had, for years, mistaken competence for a system. Because things worked, no one questioned how they worked. The three most tenured people had absorbed patterns, exceptions, judgment calls, and small tricks that made the machine run. None of it was written down, because writing it down felt like busywork when the machine was already running.

Then a single resignation exposed the truth: the business did not have processes, it had people. When one person left, a capability left with them.

The decision

Do not attempt to document everything. That is the trap that kills every "SOP initiative" ever launched — a six-month effort to write down every process in the company, most of which are trivial or already understood, resulting in a five-hundred-page wiki no one reads.

Document only what would actively break if the person who does it left tomorrow. Prioritize by revenue and client exposure. Ship in weeks, not quarters.

What got built

An 80/20 SOP sprint. Twelve processes, ranked by criticality, documented in a fixed one-page format, over six weeks. Not fifty. Not two hundred. Twelve.

The one-page format was non-negotiable. Every SOP had exactly the same shape, so anyone in the company could open a new one and immediately know where to find what they needed. Longer documents were rejected on principle — if a process could not fit on one page, it was not one process, it was several, and needed to be broken down.

The one-page SOP template

Use this format verbatim. Every SOP in your business, on a single page:

• Trigger. The event that starts this process. Written as a single sentence: "when X happens." Not "sometimes." Not "as needed." A specific event.
• Owner. One named role, not a team. If two roles could own it, split the SOP.
• Steps. Numbered, imperative, each verifiable. If a step cannot be completed by someone reading it cold, it is too vague — rewrite. Aim for five to twelve steps.
• Inputs. What the owner needs before starting. Files, access, information, sign-offs.
• Outputs. What exists at the end that did not exist at the start. Named artifacts.
• Done-definition. How the owner knows the process is complete. Not "when it feels finished" — a specific, observable state.
• Exceptions. The two or three cases that break the standard path, and what to do in each. If there are more than three, the process is under-designed.
• Last reviewed. Date. Reviewed at least quarterly, or immediately after any incident tied to this process.

The prioritization method

Before writing any SOP, list every recurring process in the business. Then score each on two axes: does it touch revenue or clients (yes / no), and how many people can currently do it (one / few / many). The twelve you document first are the ones that touch revenue or clients and can currently be done by only one or a few people. Everything else waits.

In this firm, the twelve turned out to be: client onboarding, monthly client review, scope-change handling, invoice generation and follow-up, new-employee onboarding, weekly team cadence, incident response for a client escalation, project kickoff, quarterly capacity planning, tool access and offboarding, expense approval, and the sales handoff from founder to delivery.

What changed

The senior operations lead left. Nothing broke. A replacement — hired at a lower seniority level, which was itself a cost reduction — was productive within three weeks instead of the three months that had been the informal expectation for that role. More importantly, the same format made every other new hire onboarding measurably faster. Documentation stopped being an act of insurance and started being a capability.

Six months later, they were up to twenty-eight SOPs. Every one still on a single page.

Is this you?

Symptoms: you can name the person a specific thing "lives with" (the invoice person, the onboarding person, the client-review person). You feel a spike of anxiety when any one of those people goes on vacation. Your training approach for new hires is "sit with X for a few weeks and pick it up." Any two of those are true, and the constraint is documented process, not headcount.

Related reading

The very common next move after this diagnosis is to hire someone to "own operations" — a mistake, if the operating system does not yet exist. Read They Hired an Operations Manager to Fix a Missing System before making that hire. And once processes are documented, the natural next question is whether they are actually being run — which is a scorecard problem, covered in Flying Blind: The Business With No Scorecard.