The SOPs founders actually use.
Most documented processes get abandoned in the first month. The ones that survive share four quiet characteristics — and none of them are about formatting.
I’ve inherited a lot of SOP folders. Beautiful ones — numbered headers, screenshot guides, version control. And inside the team, almost no one knew they existed. The documents weren’t wrong. They just weren’t being used.
After enough of these handovers, a pattern shows up. The SOPs that actually get pulled up at 11pm before a shipment, or referenced when someone new joins, or used to settle a quiet disagreement between two coordinators — they all look quite similar. They share four characteristics. I want to walk through them, because they’re not the ones most founders optimize for.
1. Written for the next person, not the auditor.
The most common mistake is writing SOPs as if a regulator is going to grade them. Long, formal, exhaustive. The result reads like a contract: technically correct, practically unreadable.
The SOPs that survive get written the other direction. They imagine one specific person — the operator who joined three weeks ago, who is trying to do this task for the first time, at 9pm, alone — and they speak to her directly. Short sentences. Active voice. Screenshots if useful, not because policy says so.
A useful test: if a new hire can read the document, do the task, and not message you with a clarifying question, the document is doing its job. If they message you, that’s not their failure — it’s a missing line in the SOP.
2. Lives where the work actually happens.
An SOP stored in a Notion folder three clicks deep does not exist. I don’t mean that abstractly — I mean people do not open it. The cognitive cost of finding the document is higher than the cost of just messaging a colleague and asking. So that’s what happens, every time.
The fix is unglamorous: SOPs go where the task starts. The procurement SOP sits inside the procurement template. The on
boarding SOP is the first link in the welcome email. The shipping SOP is pinned to the top of the shipping Slack channel. You’re not asking anyone to remember where the document is. It’s already in their hand when they need it.
The document that is impossible to find is, for most practical purposes, the document that was never written.
— TOM DEMARCO, PEOPLEWARE
3. Owned by a name, reviewed on a date.
An SOP without an owner becomes wallpaper. Within six months the tool has changed, the team has changed, the process has changed, and the document is quietly wrong. Nobody flags it because nobody believes it’s their job to.
Every SOP I keep alive has two lines at the top:
- Owner: one named human, not a team
- Last reviewed: a date in the last quarter
The review doesn’t need to be elaborate — ten minutes, once a quarter, to check that the steps still match reality. The point isn’t perfection. The point is that someone is paying attention.
A small caveat
Not every process needs an owner with a calendar reminder. The SOP for something that runs twice a year can be lighter-touch. The SOP for the thing that runs every Monday morning cannot.
4. Includes the “why,” not just the “how.”
This is the one most founders skip, and it’s the one that matters most for longevity. A list of steps tells someone what to do. A short paragraph at the top — “we do it this way because the client cares about X” or “this step exists because we got burned once by Y” — tells them how to handle the situations the SOP didn’t anticipate.
SOPs without the “why” are brittle. The moment something unexpected happens — a vendor delay, a new client request, a tool update — the person on the ground has no basis to make a judgment call. They either freeze or they invent. Both are worse than just knowing the intent.
Where to start.
If you have no SOPs and you’re feeling guilty about it, don’t try to document everything. Start with the one process that breaks most often — the one that generates the most “wait, how do we do this again?” messages in a given week. Document that, just that. Put it where the work happens. Give it an owner. Add a sentence about why. See if anyone uses it.
If they do, you’ve found the shape of an SOP that fits your team. Repeat it for the next one. If they don’t, the document isn’t the problem — you’ve just learned something about how your team prefers to operate, and that’s worth more than a perfectly formatted folder.