A few months into any process improvement effort, someone on the team says some version of the same thing. “I thought we all did it the same way.” Then it turns out three people on the same team handle the exact same task three different ways, and none of those ways match what the manual says, and none of them match what leadership thinks happens.
The instinct is to treat this as a problem. Somebody did not follow the process. Documentation is out of date. Training failed somewhere. All of that might be true. But there is a more useful way to think about it, one that comes out of safety and reliability research, not management theory.
Treat the gap as data, not a verdict
In that world, a gap between the documented process and the actual process is not treated as a failure. It is treated as data. It tells you where the written process does not match the conditions people are actually working in. Maybe the manual assumes a resource that is not always available. Maybe the “correct” way takes twice as long under real workload, so people quietly built a faster path that mostly works. Either way, the gap is information about the system, not a verdict on the person.
A process nobody actually follows is not a process. It is a suggestion with better formatting.
As a director, the instinct when you find one of these gaps is to close it immediately, tell everyone to follow the documented process, and move on. That instinct is usually wrong, or at least premature. Ask why the gap exists before deciding which side of it is right:
- Sometimes the documented process is correct and people drifted from it for reasons worth correcting.
- Just as often, the workaround people invented is the more honest description of how the work actually gets done, and the manual is the thing that needs to change.
What changes when gaps are safe to report
This reframe changes how a team responds when gaps surface. Instead of bracing for blame, people start bringing the gaps forward voluntarily, because they have seen that surfacing one leads to a better process rather than a harder conversation. That shift alone is worth more than any individual fix. A team that hides its workarounds cannot be improved. A team that surfaces them can — the same shift in posture that makes it possible to tell the truth plainly in a status update instead of dressing it up.
The goal was never for everyone to do it the same way for its own sake. The goal is for the way it gets done to actually work, to be known, and to be something the organization chose rather than something that accumulated by accident. Finding out three people do it three different ways is not the failure. Not finding out would have been — it is the same quiet blind spot that makes a transformation feel like it is stalling when it is actually just under-measured.
More essays like this one live on the Between Mondays articles page.
Further reading: OSHA and NIST both publish extensively on treating near-misses and process deviations as safety signal rather than blame.
Frequently asked questions
What does it mean when a process audit reveals everyone does a task differently?
It means the documented process no longer matches the conditions people are actually working under. That gap is data about the system, not evidence that individuals are doing something wrong.
Should a leader immediately correct a workaround they discover?
Not immediately. First ask why the workaround exists. Sometimes the documented process is correct and needs enforcing, but just as often the workaround is the more honest description of how the work actually gets done, and the manual needs to change instead.
How does treating process gaps as data change team behavior?
Teams stop hiding their workarounds and start surfacing them voluntarily, because they have seen that reporting a gap leads to a better process rather than a harder conversation. That shift alone improves reliability more than any single fix.
What field does the idea of treating gaps as signal come from?
It comes from safety and reliability research, where near-misses and deviations are treated as valuable information about a system’s real behavior, not as failures to be punished.
What is the actual goal of standardizing a process?
Not sameness for its own sake, but making sure the way work gets done actually works, is known, and was deliberately chosen by the organization rather than something that accumulated by accident.