SOPs for a tiny team: documenting the business so it survives you taking a week off

There is a specific moment when a very small business discovers it has no documentation, and it is never a convenient one. You are sick, or finally on a holiday, or a contractor is covering for two days, and a routine thing — the weekly supplier order, the payout reconciliation, the way refunds get logged — simply does not happen, because the only copy of the procedure was in your head and your head was elsewhere. Nothing dramatic broke. The business just quietly stopped doing one of the things that keeps it alive, and nobody else could tell, because nobody else knew the thing existed.

These are field notes on fixing that at the scale where most advice about standard operating procedures is useless. The SOP literature is written for companies with departments — process owners, revision approval chains, compliance audits. At one to three people, that apparatus is not just unnecessary, it is actively harmful, because every hour spent maintaining documentation theater is an hour taken from the work. What a tiny team needs is narrower and humbler: the five to fifteen recurring procedures that actually run the business, written down in a form someone else could follow cold, kept somewhere everyone can find, and kept honest by occasional real use. That is achievable in spare half-hours, and the notes below are about how to actually do it rather than how to feel guilty about not doing it.

Software teams talk about the bus factor — how many people would have to be hit by a bus before the project is unrecoverable. In most tiny businesses the honest answer is one, and not because of catastrophe scenarios. The bus is usually a flu, a family emergency, a week of travel, or just two urgent things landing on the same day. When every procedure routes through one person's memory, the business has a single point of failure that gets exercised constantly, and you feel it as the low-grade dread of being unable to step away. That dread is informative. The things you worry about while trying to be offline are precisely the list of what needs documenting first.

There is a second, less obvious cost to keeping everything in your head: you cannot see your own processes well enough to improve them. A procedure that exists only as habit is invisible — you perform it slightly differently each time, you cannot spot the redundant steps, and you certainly cannot hand it to a tool or a contractor or a future hire. Writing it down is the first time you actually look at it, and the act of writing reliably surfaces nonsense you have been doing on autopilot for a year. Half the value of SOPs at small scale has nothing to do with handoff at all; it is that documentation is the cheapest process audit available.

Forget the corporate template with purpose statements and revision tables. At this scale an SOP is any written artifact that lets a competent person who is not you complete a recurring task to an acceptable standard without asking questions. That is the entire definition, and it implies the test: could your most capable friend, with your logins and this document, do the thing tomorrow? A numbered checklist in a shared note qualifies. A fifteen-line text file qualifies. A two-minute screen recording with a sentence of context qualifies. A beautifully formatted process document that skips the step everyone actually trips on does not.

The inventory of procedures worth writing is shorter than it feels. List every task that recurs daily, weekly, or monthly, and every task that is rare but scary — the domain renewal, the tax filing prep, the what-to-do-when-the-site-is-down sequence. For most small operations that list lands between ten and twenty items, and they sort themselves by a simple rule: document first the tasks where you are the only person who knows, the cost of skipping is high, and the frequency is high enough that the document gets used. The weekly payout reconciliation beats the annual domain renewal, which beats the aesthetic preferences about social media captions, which possibly never needs writing down at all.

The single habit that makes this sustainable: write the procedure while performing it, never from memory afterward. Documentation written from memory is fiction — it records the procedure you believe you follow, which is missing the workaround you do without thinking, the field you always have to double-check, the button that is mislabeled. The next time the weekly task comes around, open a blank note next to the work and narrate each step as you do it, including the ugly parts. It adds maybe ten minutes to the task, once, and what you get is the real procedure instead of the idealized one.

Scheduled documentation sprints, by contrast, fail at small scale every single time, and it is worth understanding why so you stop feeling bad about it. A documentation afternoon competes against revenue work and loses, so it gets deferred; when it finally happens you are writing six procedures from memory in a batch, which produces six pieces of fiction; and the batch format means nothing ships until everything ships. Capture-while-doing inverts all of that. It costs almost nothing, it cannot be deferred because it rides along with work that was happening anyway, and it produces one real document per cycle. Within a month or two of normal operations, the procedures that matter have documented themselves, in frequency order, which conveniently is also priority order.

Format matters more than it seems, because the document will be used by someone mildly stressed, doing the task for the first time, probably with you unreachable. Prose paragraphs are where procedures go to hide; a wall of text forces the reader to extract the steps themselves, under pressure, and they will miss one. Numbered steps, one action per line, each starting with a verb, is the format that survives contact with a stressed reader. Conditionals get their own line — if the payout does not match, stop and do X — because branch logic buried mid-sentence is the most commonly skipped content in any procedure.

For anything involving an interface, a screenshot with an arrow outperforms a paragraph of description, and a short screen recording outperforms almost everything for tasks that are genuinely sequential and visual. The capture cost is trivial now — record the screen while doing the monthly close once, talk through it, and you have a training video that took zero extra time. The one caution with recordings is rot: interfaces change, and a video is harder to patch than a text step. The durable pattern is a text checklist as the spine — easy to update line by line — with screenshots or a recording attached as the illustration layer. When the interface shifts, you fix one line and one image instead of re-recording everything.

Where the documents live matters less than that there is exactly one answer to the question. The failure mode is not choosing a bad tool; it is having procedures scattered across a notes app, two email threads, a doc someone shared once, and a folder named "misc" — at which point looking for the document costs more than asking you, and the system collapses back to interrupting you. Pick one place, any reasonable place your team already opens daily: a shared notes workspace, a folder of plain files in shared storage, a wiki if you already have one. Flat structure, boring names that match what people would search — "Weekly payout reconciliation," not "Finance Ops Process v2."

Resist every urge toward ceremony. No templates beyond a title and a last-verified date at the top. No owner fields, no status workflows, no review cadences enforced by calendar — at three people, ownership of everything is already obvious. The last-verified date is the one piece of metadata that earns its place, because it answers the reader's only metadata question: can I trust this, or has the world changed since it was written? Updating that date takes five seconds at the end of any run where the procedure held true, and a date more than a few cycles stale is a quiet flag that someone should run the document skeptically and patch it as they go.

A procedure document is untested theory until someone who is not its author runs it for real, so engineer that test cheaply rather than waiting for an emergency to administer it. The gentlest version: next time a task comes up, have the other person do it from the document while you are in the room but silent. Every question they have to ask is a defect in the document, not in them — write the answer into the checklist on the spot. Two or three of these supervised runs and the document is genuinely load-bearing. If you work alone, the test is future-you: follow your own checklist literally, six weeks after writing it, doing nothing the document does not say. You will find the missing step.

The full exam is the vacation test: can you be properly offline for a week while the recurring operations actually happen? The first attempt will surface gaps — that is the point, and it is much nicer to discover them during a planned absence with you a phone call away than during an unplanned one with you in a hospital. Each gap becomes a patch, and the second absence goes smoother. There is a real psychological shift on the other side of a passed vacation test that is hard to overstate: the business stops being a thing only you can hold, the dread of stepping away fades, and decisions about growth or rest stop being hostage to your physical presence. That shift is what all of this was for.

Documentation has a cost — writing, maintaining, and the subtle drag of feeling obligated to follow stale instructions — so the decision not to document something should be as deliberate as the decision to document. Judgment-heavy, novel, one-off work does not belong in an SOP: how to respond to an angry customer with an unusual story, whether to take on a weird custom order, what to do about a competitor's move. Writing procedures for judgment produces either useless generalities or, worse, rules that get followed when they should not be. What you can document is the boundary: the escalation line that says which situations are routine enough for the checklist and which mean stop and think, or stop and call.

Also skip documenting anything still changing weekly. A procedure you are actively redesigning will rot faster than you can patch the document, and the half-true checklist is more dangerous than no checklist, because it gets trusted. Let a process stabilize for a few cycles first; the moment it has repeated identically two or three times is exactly the moment to capture it. The underlying principle is honest scope: the documentation system exists to make the stable, recurring, delegatable spine of the business survivable, not to capture the whole business. The judgment stays in people. The procedures go on paper. Confusing the two directions is how tiny teams either drown in process or die of its absence.

Everything above pays off twice the day you bring in help — a contractor for a busy month, a virtual assistant for the inbox, eventually a first hire. The difference between delegating with and without documents is the difference between handing someone a job and handing them an apprenticeship you do not have time to run. With a checklist, the new person is productive on day one for the covered tasks, their questions improve the documents instead of evaporating, and you can evaluate their work against a written standard instead of a vibe. Without one, you spend the hours you were trying to buy back explaining things live, and the explanation leaves with them when they go.

The same documents are also what make selective automation honest work instead of gambling. A procedure that is written down step by step is a procedure you can look at and ask: which of these steps is mechanical enough to hand to software, and which needs the human? The undocumented process can never be examined that way — you end up automating your guess about the workflow rather than the workflow. So the sequence for a tiny team that wants leverage is fixed: stabilize the process, write it down, run it from the document a few times, and only then delegate or automate the parts the document proves are mechanical. Skipping to the end is how small businesses buy tools that do the wrong thing faster.

The whole practice, run honestly, costs about an hour a week at the start and less later: ten minutes of capture-while-doing on whichever recurring task comes up undocumented, five seconds of date-bumping on the ones that held, an occasional patch when something drifts. There is no project phase, no documentation quarter, no tooling decision worth more than thirty minutes of deliberation. In exchange, within a couple of months, the business acquires a property it has never had before: it can run, briefly but genuinely, without you. Every subsequent ambition — the first hire, the second product, the actual holiday — leans on that property.

If you want a starting point smaller than a list of twenty procedures, use this one: tonight, write the document called "If I am unreachable for a week." One page. The recurring tasks and where their checklists live (write the two most critical checklists while you are at it), the passwords location, the three people to contact for the three most likely emergencies, the things that can safely wait. It is the highest-leverage single document a tiny business can produce, it takes an evening, and it converts the vague dread of being indispensable into a short list of solvable gaps. The rest of the system grows from there, one captured procedure at a time.