Why Nobody Follows the Procedures You Already Wrote

Leaders usually blame the wrong reason when procedures go unused. Here are
the five real ones, the fix for each, and where we part ways with the common
advice on how tightly to control who can change them.*

Ask a business owner why her team doesn't follow the procedures she wrote, and she'll almost always give you the same answer: they don't think it's mandatory. Give them a talking-to, make it clear this isn't optional, and the problem fixes itself. That instinct is understandable and it's usually wrong. Watch enough small teams try to get their procedures actually used, and "they think it's optional" turns out to be the reason leaders reach for first and the reason that's actually true least often. Reaching for it anyway, and responding with a crackdown, tends to make the real problem worse, whatever it turns out to be.

Four other reasons sit underneath the one everyone assumes, and each needs a completely different fix.

They don't know it exists. This is the most common reason by a wide margin, and it's almost never a communication failure. It's a filing failure. An owner spends a productive Saturday writing eight new procedures, drops them into whatever tool happened to be open at the time, a shared drive here, a sticky note there, a group text with a screenshot, and wonders eighteen months later why nobody's using them. If a team member doesn't know a procedure exists, no amount of strong leadership gets it used.

A single, searchable home for every procedure is the long-term goal, but something smaller works this week: whenever a task has a procedure behind it, link the two together. A task for onboarding a new client gets a link to the onboarding procedure, right inside the task, whether that task lives in a project management tool or on a sticky note on someone's desk. Nobody has to remember a procedure exists if it shows up automatically attached to the work that needs it.

They know it exists, and it still doesn't help them. This is the hardest one to hear if you wrote the thing yourself, because it usually means someone tried it, found it useless for their actual job, and quietly went back to doing things their own way. It happens for one of two reasons: the procedure is too vague to act on, or it's so exhaustive that reading it takes longer than just doing the work from memory.

Underneath both versions of that problem sits the same root cause: the person who wrote the procedure wasn't the person doing the job. A manager who hasn't done the actual task in years writes a procedure that's technically correct and practically useless, because she's forgotten which details are actually hard to remember and which ones are obvious. The fix is direct, and a little uncomfortable for anyone used to writing every procedure herself: let the people doing the work write it. A team member who handles this task every week knows exactly which two details get missed and exactly how much explanation the rest needs. She'll also use what she wrote, because she built it, and she's the least likely person in the building to treat it as someone else's paperwork.

They don't trust it. A procedure that led someone astray once, because it was two versions out of date, earns a permanent asterisk in that person's head. Once that happens, memory or a coworker's advice feels safer than the document, even after it's fixed.

This is where we part ways a little with the common advice in this space, which tends to say: get rid of approval gates entirely, let anyone edit anything at any time, because a review step just slows everyone down. We think that's half right. Locking a procedure behind a formal approval process, where a small edit has to wait a week for a manager's sign-off, kills trust just as fast, because the gap between noticing a problem and seeing it fixed becomes the whole reason people stop bothering to report problems at all.

But wide-open editing with no check at all has its own failure mode, one we've watched play out just as often: someone makes a well-meaning edit based on how one job went, and it quietly breaks the procedure for the next fifty jobs that don't look like that one. For most small teams, the better balance is open editing with a light review step before a change goes live: anyone can propose a fix the moment they spot a problem, and whoever owns that procedure gives it a quick look before it replaces the version everyone else is using. That review shouldn't take more than a day, and it shouldn't require a meeting. It just means one more set of eyes confirms the fix holds up before fifty other people start relying on it. Fast, light review beats both extremes: no gate at all, and a gate heavy enough that nobody bothers proposing changes in the first place.

**They've memorized it.** This is the strangest reason on the list, because it's mostly a sign of success. Someone who has done this task two hundred times doesn't need to read step three anymore, and that's fine on its own. The risk shows up later: memory drifts, a procedure gets updated and the person on autopilot never notices, or the process changes in someone's head without ever making it back into the document for the next person.

Making the document skimmable enough that even an expert glances at it out of habit works better than forcing her back to reading a document she's outgrown. Give her one thing worth glancing at even when she doesn't need the steps: a short completion check at the bottom, three to five items, the kind of gut-check a veteran runs in ten seconds without feeling handed a training manual again.

None of these five reasons make anyone a bad employee, and none of them require a stricter policy to solve. They require noticing which one is actually happening in your business first, because the right fix for one reason can make a different reason worse if you apply it to the wrong one. Get the diagnosis right, and the fix is almost always smaller and less dramatic than the problem felt like from the outside.