Writing down a broken process gives you a written record of the break.

Documenting a broken process gives you a written record of the break and nothing more, because the writing never addressed why the work keeps returning to you. SOPs capture a process that already works. They do not repair one that does not. If you still have to keep telling her, the problem is the design, not the documentation.

• Documenting a broken process produces a precise record of the break, not a solution to it.
• An SOP is a tool for preserving a working process, not a tool for repairing a failing one.
• If a task keeps coming back to you after you wrote the steps down, the design is the problem.
• Deming’s work argues that about 94 percent of problems live in the system, not the person following the steps.
• Deleting a step is often faster and safer than writing instructions for why it should exist.
• The goal of documentation is handoff, and handoff only works when the step no longer needs you.

Here is the belief that sent you down the SOP rabbit hole: if I write it all down, I can finally hand it off. Writing it down and handing it off are two different jobs. You can document a broken process in perfect detail and still be the only person it runs through. That is the trap in the anchor line so many people live inside. “So I have, yeah, the SOPs, right? But she just, I just have to keep telling her.”

You wrote the steps. She has the steps. And the work still lands on your desk every Friday. That is not a documentation gap. That is a process that was never designed to leave your hands.

What is a broken process, and why does documenting it fail?

A broken process is a sequence of work that depends on a specific person’s judgment, memory, or constant correction to complete, which means the real instructions live in your head and not on the page. When you document it, you capture the visible steps but not the invisible decisions you make every time. So the written version runs into the same wall. She follows the page, hits a decision the page does not cover, and comes back to you. The documentation did its job. The job was just the wrong one.

Note what documentation actually is. An SOP, or standard operating procedure, is a written capture of a process that already runs cleanly, so a second person can run it the same way. That definition carries a condition. The process has to already work before the writing helps.

Documentation preserves a process that works. It cannot repair a process that does not.

The tell: you are still the decision engine

Read your own SOP out loud. Every time you reach a line that says “use your judgment,” “check with me,” or “depending on the situation,” you have found a spot where the process still needs you. Those lines are not instructions. They are placeholders for a decision you never designed out. A prompt is not a system, and neither is a document full of soft handoffs.

Why does the work keep coming back to you?

The work keeps coming back because you documented the steps but kept ownership of every exception, and real processes are mostly exceptions, so the person running your SOP hits a fork the page does not resolve and returns it to the one person who can. You did not hand off the process. You handed off the easy 70 percent and quietly kept the hard 30 percent that was causing the pain in the first place.

This is why the SOP feels like a betrayal. You followed the advice. You spent a Friday writing. And nothing changed about your actual load. The writing was never going to change it, because the thing creating the load was the design, not the absence of a page.

W. Edwards Deming built an entire body of work around this idea. His research is often summarized as the claim that roughly 94 percent of problems belong to the system and only about 6 percent to the individual. Applied here, blaming her for not following the SOP misses the point entirely. The system handed her a process that cannot run without you.

What is documentation actually for?

Documentation is for preserving and scaling a process that already runs without you, so that handoff becomes a transfer of a working system rather than a transfer of your presence, which is the one thing writing can never move to another person. It is the last step after you fix the design, not the first step you take hoping the design fixes itself.

Here is the order that actually frees you up. Note the step. Eliminate what should not exist. Refine what remains until it runs without your judgment. Then deliver it as a written procedure someone else owns.

1. Note every place the process currently touches you.
2. Eliminate the steps that exist only out of habit or fear.
3. Refine the survivors so each decision has a rule, not a vibe.
4. Deliver the written procedure once the process no longer needs you to run.

If a step still requires your judgment to complete, you have not finished designing it, you have finished describing it.

Documentation versus process design

How do you tell a documentation problem from a design problem?

You tell them apart by watching what happens after the handoff, because a documentation problem ends when the person reads the page, while a design problem returns to you no matter how thorough the page is, which means the page was never the missing piece. If a fuller SOP would solve it, write the fuller SOP. If a fuller SOP just produces a longer document that still routes back to you, stop writing and start cutting.

The fastest diagnostic I know is this. Pick the step that keeps coming back. Ask whether the instruction is unclear or whether the decision is genuinely yours to make. Unclear instructions get rewritten. Decisions that are genuinely yours get a rule, get delegated with authority, or get deleted. Deming’s broader thinking on treating an organization as an interdependent system lands here too. The step is not failing in isolation. It is failing because of how it connects to everything around it.

Sometimes the honest answer is that the step should not exist. You built it to catch a problem that no longer happens, or to satisfy a client who left, or to soothe a worry you have outgrown. Writing an SOP for that step dignifies it. Deleting it ends it. One of those gives your Friday back.

Deming’s 94 percent figure comes from Out of the Crisis, and he revised his own estimate upward over the years, moving from an earlier 85 percent to 94 percent as his conviction grew that systems, not people, carry the blame for most failures.

Almost every time I open a client’s SOP folder, I find a beautifully written document for a process that should have been deleted two years earlier. The person spent a whole afternoon capturing steps for a task that existed only because nobody had ever questioned it. The writing was careful. The process was dead weight. I have watched the relief on someone’s face when I ask one question about a documented step and they realize they cannot remember why it exists. That is the moment the real work starts, and it is never the writing.

How do I know if I have a broken process or just bad documentation?

Watch what happens after someone reads your SOP. If they can complete the task start to finish, you had a documentation gap and you fixed it. If they read it and still return to you for a decision, you have a design problem. Documentation never solves a task that depends on your judgment to finish.

Why does the work still come back to me after I wrote the SOP?

Because you documented the predictable steps but kept ownership of the exceptions, and the exceptions are where the real work lives. Your SOP handed off the easy portion and quietly left the hard decisions with you. The page cannot transfer your judgment, so the judgment keeps routing back.

What is an SOP actually supposed to do?

An SOP preserves a process that already runs without you so another person can run it identically. It is a scaling tool, not a repair tool. It belongs at the end, after you have designed a process that no longer needs your constant correction. Written before that point, it just records the break.

Should I delete a step instead of documenting it?

Often, yes. If you cannot explain why a step exists beyond habit or an old fear, deleting it is faster and safer than writing instructions for it. A shorter process that runs cleanly beats a long document that explains a step nobody needs.

Does more detailed documentation ever fix the problem?

Only when the problem was genuinely unclear instructions. More detail helps a process that works but was poorly described. It does nothing for a process that structurally depends on you. Adding detail to a broken process produces a longer record of the break, not a working handoff.

Who should own the exceptions in a process?

Whoever runs the process day to day, with a clear rule for each exception you can hand them. If every exception still has to clear your desk, you have not delegated the process. You have delegated the typing and kept the thinking. Give the rule, give the authority, or delete the exception.

Before you open another document, do one pass. Pick the process that keeps coming back and separate the steps into three piles: delete, assign a rule, rewrite. Most of what you were about to document belongs in the first two piles. Only the third pile earns a page.

Save this before you spend another Friday documenting something that should be deleted.