Why Your Team Ignores The Process You Wrote Down

What I've found is that a written rule holds when it comes back in front of whoever is doing the work, at the moment they do it. Read once at the start of a long job, it has to compete with everything else in that person's head, and it usually loses. So a fifth copy of the rule tends to change nothing, because the rule was never missing, badly worded or hard to find. What has worked for me is moving it out of the document and into the step, so the work cannot reach the end while the rule is broken.

Why does a written procedure get ignored?

A written procedure gets ignored when the person doing the work has to hold it in their head for too long. The procedure can be completely accurate. It can also be sitting in a folder while the actual work happens somewhere else entirely.

I hit this on a content job for a law firm client, and it is an unusually clean example because almost every normal excuse was unavailable. The instruction was plain English, about a ninth grade reading level. It appeared in four separate places: the client's brand file, the drafting step, the finalize checklist and the project guardrails. It was read and agreed with. Then all 25 pages broke it.

Nobody had to hunt for a missing document. Nobody disagreed with the rule. I was running the process myself, so there was no team member to blame for not reading it. The instruction existed in four copies and still dropped out of attention while the pages were being written.

Safety researchers have a name for the gap this opens up. They call it the difference between work as imagined and work as done, a distinction that comes out of Erik Hollnagel's research on why real processes drift from documented ones. Work as imagined is the process on paper. Work as done is what happens with six files open, a deadline, and a decision to make every other paragraph.

Hollnagel and two colleagues traced that gap through two intensive care units in Implementation Science in 2015. In one draft discharge guideline the researchers mapped 22 separate functions, and the mapping showed missing information and dependencies that were hard to see from the written guideline on its own. The document itself read fine.

What I've found is that this is not carelessness. Attention goes to the immediate problem, which is the right place for it. A rule read forty minutes ago has become background by then, even when everyone involved still agrees with it.

What is different about a rule that actually holds?

A rule holds when the work itself brings it back at the point of use, so nobody has to carry it through the whole job from memory.

One instruction in my own writing setup is four words long. No em dashes anywhere. I wrote those instructions myself, they are short, and they sit in the same file the writing is done from. Two em dashes still reached a client's scheduled post.

Reading the rule again before every session would only have added another thing to remember. So I put a step after the writing instead. It reads the finished text and strips that character out before anything gets saved.

That changed what kind of thing the rule was. It moved from something I intended to remember into something the process tested, and it ran late enough to inspect the real output rather than the plan for the output.

So I run it before the page goes out. Run afterwards it can tell me what I missed, but by then the thing is already published and I am fixing it in public. During drafting I can still sort it out without much trouble.

Does a checklist really work, or does it just become a ritual?

A checklist changes behaviour when people use it during the work and treat each line as a real test. It can also decay into box-ticking, so how it is designed and how it is used both matter.

The strongest evidence for the first half is surgical. In 2009, Alex Haynes, Atul Gawande and their colleagues introduced a nineteen-item safety checklist across eight hospitals and measured what happened. The death rate fell from 1.5% to 0.8%, and inpatient complications fell from 11.0% to 7.0%. Those hospitals already had surgical standards written down. What changed was that the standards were now read aloud in the room, at the moment they applied.

Those hospitals already had surgical standards. What the checklist did was put nineteen of them into the room as a step in the work. The study compared outcomes before and after introduction rather than isolating every cause, so it cannot show which part of the change produced the result. It is still the clearest example I know of an agreed rule moving out of a document and into the job.

The second half is just as important and gets quoted far less. In 2024, Facey and colleagues published work in Sociology of Health and Illness on the same checklist becoming ritualised and decoupling from the safety goal behind it. The boxes still got ticked. The thinking had drained out of the exercise.

I have run into the small version of that. One compliance check failed a single page thirteen times over one word, because the document that word names was the actual subject of the page. At thirteen failures the check was no longer protecting anything, it was blocking correct work, and the natural next move is to route around it.

A check that blocks good work gets switched off sooner or later, and then it catches nothing at all. So it needs a clear job, a warning that says what to do, and an honest way to record a genuine exception.

Where should a rule live?

So I think it helps to keep a rule close to the part of the work where it actually matters. These are four places I have used, and for the kind of checks I run, the later ones have usually held better.

1. In somebody's memory

The least dependable place there is. A person can understand a rule completely and still lose it while handling the rest of the job. Training helps and memory is still doing the work.

2. In a procedure document

A document gives the rule a permanent home, which genuinely helps with training, review and disagreements about what the process requires. Somebody still has to open it and connect the right paragraph to the task in front of them.

3. Inside the step where the decision happens

A short checklist line, a required field, one sentence beside the button about to be clicked. The instruction arrives while it can still change the decision.

On that 25-page job, the first honest scan found 173 readability problems. The word "cured" was on 18 of the 25 pages. The phrase "worth knowing" appeared 20 times across the set, which is a verbal tic I had no idea I had. None of that surfaced from reading the instructions again. It surfaced because something counted.

4. In a check that tests the finished work

The strongest position I have found. The process examines the real file, page or record before anything moves forward, and it can stop the job or send the item back.

The catch is that the check has to work, and you cannot assume it does. On 18 September 2026 I found one of mine had been dead since the day I built it. It printed a clean status line whenever the queue was healthy. When it had a warning to deliver, it crashed on a character the console could not display, and the crash was swallowed by the safety net wrapped around it.

So the only path it had ever proved was the one where nothing was wrong. That is why I now feed a deliberately broken example to any new check and watch it go red before I trust a green result from it.

How do you tell which kind of rule you have?

Break the rule on purpose and see what happens. That single test tells you whether your process inspects the finished work or merely contains instructions about it.

Take one safe copy of something real and put a known error into it. Run the normal process. Note where the error gets caught, who sees the warning, and whether the work can carry on without anyone fixing it.

If nothing happens at all, the rule lives in memory or in a document. A reminder that shows up while the task is running means it lives inside the step. If the finished item cannot move forward unnoticed, you have a real output check.

Then run the opposite test, which people skip and should not. Feed it something legitimate that looks suspicious and make sure it passes. My readability checker threw three genuine false positives in one session, so I loosened those specific rules and left the rest alone. Tuning a check down is not weakening it. Leaving it noisy guarantees somebody stops reading its output, which is the same as deleting it.

This works the same way on an employee checklist, a client intake form, a bookkeeping review or an AI writing pipeline. Put in one known problem, watch what the system does with it. A tidy procedure document cannot answer that question for you.

Frequently asked questions

Why does a written procedure get ignored?

Because the person doing the work has to carry it in their head for too long. The procedure can be accurate, findable and agreed with, and still sit in a folder while the work happens somewhere else. On one job the same instruction appeared in four separate files, was read, was agreed with, and was broken on all 25 pages.

Should every procedure become a checklist?

No. A checklist suits steps somebody can confirm during the work. Background explanations, judgement calls and unusual cases still belong in the full procedure, because a checklist that tries to hold all of that stops being quick enough to use.

What should happen when a check fails?

The warning should name the problem, show where it happened and give the person a way to correct it. A message that only says failed leaves somebody hunting for the reason, and a check people have to decode is a check they start skipping.

How do I know whether my check actually works?

Break something on purpose and watch it go red. A check that has only ever passed has been used rather than tested. One of mine reported success perfectly and crashed every time it had a warning to print, so the only path it had ever proved was the one where nothing was wrong.

Can AI follow a written procedure reliably?

In my experience, not from instructions alone on a long job. I use a separate output check for formatting, required sections and banned terms, because instructions given at the start of a long draft can still get missed by the end.

---

Two things worth reading next. The Second Opinion Brief is the prompt I use to make one AI attack another one's work rather than agree with it, which is the same idea applied to review. How do you know if AI actually did the work covers the narrower version of this problem, where the report and the result disagree.