Scheduled for 2026-10-28 β€” not indexed yet. Only visible via direct link.

Founder Infrastructure Β· 2026-10-28

Your SOP Is a Google Doc With One Page and Nobody's Opened It Since March

You wrote it well. That is the part nobody believes, including you. 🧰

You gave it a Saturday. You got the order right. You did the thing that most founders never bother to do, which is write down not just the steps but the reason β€” and the reason is the entire reason anybody follows a process at all. Then you put it in a folder, dropped the link in a channel nobody reads, and went back to work.

Since March the only person who has opened it is you. Twice. Both times to fix a typo nobody else will ever notice.

A Black woman in a cream tailored suit seated at a warm wood desk in a calm bright studio office, a single plain unmarked sheet of paper flat under both hands, a slim gold pen laid down beside it and a plain unmarked ceramic mug at the edge of the desk, her expression concentrated and slightly rueful, her eyes on the page.

The document isn't the problem. The distance is.

An SOP that lives in a document is a thing somebody has to remember to go and get. A process that lives inside the task is a thing that simply happens. Those are not the same product, and the first one is the only version most founders ever build. πŸ“‹

So the question was never did you document it. It is: how many decisions does somebody have to make between finishing this task and starting the next one? Every decision in that gap is where your process quietly goes to die, and none of them feel like decisions while you're making them. πŸ”

They want you to call this an onboarding discipline problem. I think that's wrong, and I think it is expensive β€” because it means you'll write a better document, send it round again with a nicer title, and watch the identical thing happen a second time with better formatting on the cover page.

I see this constantly, and the pattern is always the same shape: the founder who writes the documentation is the one person on the team who did not need it. She already had the order in her hands. So the thing gets built for the team, stored where the team won't look, and then quietly judged as a failure of the team β€” when the only person who ever read it was the one person it was never for. 🧰

Nobody skips documentation on purpose. They skip the four steps between the task and the document.

Three questions that find the leak

1️⃣ Take the step your team gets wrong most often. Now count what happens between the moment somebody realises they've got it wrong and the moment they go looking for the fix. If that number is they ask me, then the document isn't a process β€” it's a phone call with extra steps. πŸ“±

A Black woman in a camel blazer over a white tee standing in a bright modern studio office kitchen alcove beside a warm wood counter, a plain matte unbranded laptop closed under one arm and a plain unmarked ceramic mug in her other hand, relaxed and mid-stride, her expression light and unforced, her eyes turned toward a colleague out of frame.

2️⃣ Ask somebody who was not there the day it was written to describe the process out loud. If their version differs from your document in any way that matters, the document has already lost. It is a historical record now, not a description of present.

3️⃣ Ask the person it was written for what they would need to see, in what place, at what moment, for it to turn up at the right time without anybody having to go and get it. Their answer will be specific, slightly uncomfortable, and something you would not have thought of.

Here is the question I would put underneath all three, and I would genuinely like you to sit with it for a minute. If you deleted the document tonight, how much worse would tomorrow actually be? πŸͺž

Most founders answer with a feeling, and the feeling says: enormously, my whole operation falls apart. Look at what actually happened the last time somebody got a step wrong β€” because that is the answer, and it is usually one person's afternoon, not a catastrophe. The document is a monument to a fear, and monuments are expensive to maintain and easy to walk past.

Which is not an argument against writing things down. It is an argument for writing down the four steps that would actually hurt, and letting the rest go. A process that only needs to survive being found is not a process. It is a filing habit, and filing habits do not scale a business β€” they just make the founder feel like she has done something. πŸ’…πŸΎ

The three moves

Not a knowledge base. Not a wiki. Not a tool rollout in March. Three moves, this week.

One. Cut the document down to the single page somebody would actually read, and delete every paragraph that explains why the system is good. Nobody needs to be persuaded at the exact moment they are trying to finish a client. πŸ—‚οΈ

Two. Put the step where the work already happens. Inside the tool. On the form. In the calendar. On the invoice. If it lives where the task lives, it costs zero attention to find β€” and attention is the only currency this whole thing is actually spent in.

Three. Ask one question every time it gets used, and read the answers on a Friday. Not a survey. One question. Over three months that is a system which tells you where it is failing, which is the only review process I have ever watched anyone actually keep doing. πŸ’Œ

Then delete the rest of the documentation and do not rebuild it. I know that feels reckless on paper. It is the opposite. The documentation you don't have is the part that was never doing any work anyway. 🧹

And when you do delete it β€” because you will want to rebuild it within about nine days, that is not weakness, that is what our brains do with anything we removed β€” leave one line in its place. Not a copy. One line naming who owns that step now, and where they will find it. That line is worth more than the forty pages it replaced, because it is the only part that was ever true. πŸ“¦

The test, if you want one: pick any instruction in your operation and ask whether somebody could follow it while looking at the task in front of them. Not at a screen with a document on it. At the task. If the answer is no, you have written documentation β€” and documentation is not the same deliverable as a process, however good it reads in the meeting where you presented it.

What it feels like once it's true

You'll notice something strange in the first week. You stop being the answer. Somebody sends a photo of a finished job instead of a question, and it is better than the one you would have given them. 🌿

That is the entire goal, and it takes about as long to describe as a hiring plan. The value of a founder's process was never in the document. It was in whether it kept working while she was busy doing something else β€” which is the only condition under which a process is worth having at all.

The takeaway

Today: take the step your team gets wrong most, delete everything in the document except that step, and move it somewhere the task already lives. Fifteen minutes. Not a documentation project β€” one instruction, in the place somebody is already standing.

You have already done the hard part, which was caring enough to write it down. Don't let a folder be the reason it never gets used. πŸ’…πŸΎ

← Back to the blog