The gap between what the system rewards and what reality requires.
There is a particular kind of failure — compliance drift — that nobody flags when a system appears to be working properly.
People follow the steps, do the research, complete the documents. The structure is respected, and the process produces exactly what it was designed to produce. And then the output meets reality, and reality doesn’t cooperate.
The client has already moved on. The team knew the constraints were wrong from the start. The recommendation lands six months after the decision it was meant to inform. Everything looked fine inside the system. Nothing was fine outside it.
This is not a failure of effort. That would be easier to fix. This is a failure of design, and it tends to hide inside systems that appear to be working. The process worked on paper, but failed in practice.
I started noticing this pattern in different contexts, first in education, then inside organizations. The setting changes, but the mechanism is often the same: a process or idea begins to organize people’s work before it has enough contact with reality.
What compliance drift actually looks like
I’ve been calling this compliance drift, and I keep seeing it in different settings.
In education, a process designed to improve student work can quietly invert its own purpose. The intention makes sense: create structure, increase quality, support deeper research, build evidence before they recommend, validate before they conclude. No serious person argues against that.
But in practice, the process can create a different problem. Students spend the bulk of their time inside the process. By the time they present findings to a real client, some of those ideas have already been tested, implemented, or quietly dropped. What the student frames as a future recommendation, the client experiences as last month’s conversation.
The same thing happens in companies, only with better coffee and more expensive slides. A senior leader presents a sharp narrative. The ambition is clear. The language is doing the work that evidence should be doing. The people closest to the operation see the gaps immediately — the customer problem is underspecified, the operational constraints are underestimated, the timing is wrong, someone already tried this. But by then the idea has momentum, and momentum is expensive to question. The idea is not necessarily bad, but it is floating slightly above the facts.
In both cases, the mechanism is identical. The system starts rewarding movement through the process before anyone has seriously tested whether the process still fits the situation.
Once that happens — that is where the real issue begins — the question changes. It stops being: Is this still true? It becomes: How do we make this fit?
That shift is where compliance replaces judgment.
What the system rewards is what people learn
Every system teaches behaviour through what it rewards, not through what it says it values.
A system that rewards documentation gets documentation. One that rewards research volume gets research. One that rewards enthusiasm around senior ideas gets enthusiasm on demand. None of this is automatically wrong. It becomes a problem when those behaviours are rewarded more than relevance, timing, or the ability to change direction when the situation changes.
The gap opens between two things that look similar but aren’t:
This is not a design flaw that emerges from laziness or bad intentions. Compliance drift happens inside serious systems built by serious people. That is precisely why it is hard to challenge. Compliance drift doesn’t announce itself. From the inside, the process looks reasonable. It has phases, criteria, quality checks, governance moments, reporting lines. The dysfunction only becomes visible when the output meets reality and reality says: interesting, but not what was needed.
Or worse: correct, but too late.
The misdiagnosis that keeps compliance drift in place
The standard response to compliance drift is to add more process. Tighter reviews, more checkpoints, earlier sign-offs, better templates. The assumption is that the system failed because it wasn’t rigorous enough.
This is usually the wrong diagnosis.
When education is designed primarily from academic priorities: research depth, procedural consistency, formal justification, assessment safety, it naturally produces students who are strong at those things. Not wrong. But when those priorities dominate without enough friction from professional reality, the system becomes slow in exactly the places that matter.
When strategic initiatives are designed primarily from executive priorities: narrative coherence, visibility, speed of announcement, stakeholder management, they naturally reflect those concerns. Also not wrong. But when those priorities dominate without enough input from the people who understand the operational friction, the roadmap detaches from the ground it’s supposed to move.
The lazy conclusion is that less structure fixes this. It doesn’t. Without structure, education becomes arbitrary, and organisations become chaotic, and decisions depend too much on whoever speaks last.
The answer isn’t less structure. It’s structure that keeps people in contact with reality. Research on high-performing teams consistently shows the same pattern: the structure that works is the one designed to surface reality, not protect the plan.
What changes when the design changes
A better education process doesn’t ask students to research more. It asks them to validate earlier, and it rewards how the analysis shaped decisions, not just the quality of the analysis itself.
A better organisational process doesn’t ask teams to execute the senior idea faster. It asks what must be true for the idea to work. It surfaces assumptions before resources are committed. It creates space for the people closest to the work to challenge the logic without being labelled resistant or not strategic enough.
Those labels are doing a specific job. They’re not descriptions of behaviour. They’re mechanisms for protecting ideas from the contact that would test them.
This is the design question that most systems avoid: where does reality enter the process? Not as a final validator at the end, after commitments are made and narratives are set. Earlier. When it can still change something.
Where are assumptions tested? Where does feedback from outside the system get taken seriously? Where can someone use professional judgment without being punished for breaking the expected script?
These aren’t administrative questions. They’re system design questions. And the answers reveal what the system actually values, as opposed to what it says it values.
The thing worth sitting with
There is a version of compliance drift that never gets diagnosed because the system continues to function. Reports are produced. Projects are delivered. Roadmaps are presented. Everything moves. The gap only shows up in aggregate: in the distance between what was planned and what proved useful, between what was recommended and what was relevant, between what the leader announced and what the team could actually implement.
Good systems don’t remove judgment. They make judgment easier to exercise — by designing reality into the process instead of keeping it at the edges, where it arrives too late to matter.
The harder version of this: a system that’s working well by its own measures can still be producing the wrong thing. And the people inside it are often the last to see it, because the system taught them what good looks like.
