SOPs: Standard Operating Procedures

You built your first delegation system back in Lesson 15. Now we go deeper, because SOPs aren’t just about delegation. They’re the backbone of independent operations.

Every process that lives only in your head is a single point of failure. You get sick, you go on vacation, you’re simply having a bad day — and that process degrades or stops.

An SOP takes the process out of your head and puts it somewhere anyone can access. That’s not bureaucracy. That’s freedom.

What Good SOPs Look Like

Bad SOPs are dense, confusing documents that nobody reads. Good SOPs are clear, scannable references that someone can pick up and follow.

The difference comes down to design.

Start with the purpose. Why does this process exist? What does it accomplish? When someone understands the why, they make better decisions at every step.

Write for a smart stranger. Not someone with your context. Not someone who’s been watching you do this for months. A capable person who’s never seen this process before. If they can follow the SOP and produce acceptable results, it works.

Number everything. Sequential steps that can be followed in order. Not paragraphs of prose. Steps. “1. Open the dashboard. 2. Filter by date range. 3. Export to CSV.” Clear. Sequential. Unambiguous.

Flag the decision points. Where does judgment come in? What criteria guide the decision? “If the order value exceeds two hundred dollars, apply the premium shipping rate. If under two hundred, use standard shipping.” Don’t just say “decide on shipping.” Provide the criteria.

Cover the exceptions. What happens when things don’t follow the normal path? The customer wants something unusual. The system throws an error. The typical process doesn’t apply. Document the common exceptions and what to do about them.

Set the quality bar. What does “done well” look like? What’s the minimum acceptable standard? Without this, quality becomes whatever the person thinks is good enough — which may not match your definition.

Name the lifeline. When the SOP doesn’t cover the situation, who do they contact? How? This is the safety net. It shouldn’t be you for everything — but there should always be someone.

The Writing Process

Most people try to write SOPs from memory. That produces incomplete documentation because you’ve been doing the process so long that half of it is unconscious.

Better approach: do the process one more time, slowly, and document as you go. Every click, every decision, every step. Narrate what you’re doing as if someone is watching. That narration becomes the SOP.

Even better: have someone watch you do the process and write down what they see. They’ll catch steps you skip unconsciously because they seem “obvious.” Nothing is obvious to someone seeing it for the first time.

Testing the SOP

An untested SOP is a draft, not a document. The only way to know if it works is to have someone follow it.

Find someone who hasn’t done this process before. Give them the SOP and nothing else. No verbal instructions. No “let me show you first.” Just the document.

Watch them work through it. Note where they get stuck. Note where they make mistakes. Note where they have questions the SOP doesn’t answer.

Every stuck point is a gap in the documentation. Fill it. Then test again. Repeat until someone new can produce acceptable results from the SOP alone.

Which Processes to Document First

You can’t document everything at once. Prioritize:

1. Processes that would stop without you. These are your critical single points of failure from the independence test.
2. Processes you delegate repeatedly. If you keep explaining the same thing, writing it down once saves hours.
3. Processes with quality variability. If results are inconsistent, an SOP with quality standards fixes it.
4. Processes that new people need to learn. Onboarding is dramatically faster with SOPs.

Today’s Practice

Create one real SOP. Not a quick sketch. A functional document.

1. Select a process that currently requires you or that you plan to delegate.
2. Do the process once slowly, documenting every step as you go.
3. Add decision points with explicit criteria.
4. Add exceptions — the common edge cases and how to handle them.
5. Add quality standards — what “done well” looks like.
6. Add the lifeline — who to contact when the SOP doesn’t cover it.
7. Test with someone. Give them only the document. Watch where they get stuck. Fix the gaps.

One complete, tested SOP. This is how you start building institutional knowledge that doesn’t depend on your personal presence.