The Route That Trained Override Behavior
How a handoff became a gap when nobody named a receiver (Route Rebuilder | Episode 3)
The quarterly architecture review is twenty minutes in when the process diagram goes up on the screen. Maya has seen this slide before. Every new service flows left to right across it: request, requirements, design, and then the box in the middle that makes everyone feel safe, the security and architecture review. The arrow runs straight through it, the way arrows do.
The compliance partner walking the room through the diagram sounds confident. The diagram gives him every reason to be.
Then someone from the platform team asks a small question. “When did a service last actually go through that review?”
Maya starts counting in her head. Eleven services shipped last quarter. She can remember two review meetings, maybe three. She looks around the room and realizes everyone else is doing the same math. The silence that follows is not guilty. It is something worse. It is the sound of competent people calculating, and coming up empty.
A review gate is not a control because it exists. A review gate becomes a control when teams actually use it, trust it, and leave evidence that real scrutiny happened. The box was on the diagram. The arrow pointed through it.
The work had stopped visiting.
If You’re Skimming
A gate that exists on the diagram is not the same as a gate that operates in the work.
Teams rarely rebel against a review gate. They adapt to its friction, and the route teaches the workaround.
Approval is not scrutiny. A thumbs-up can move a change forward without anyone owning the risk.
Use the Five-Change Field Test to find whether your gate is operating, not merely documented.
👋 Welcome to this week’s edition of Empathy Engine. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.
Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.
In Episode 1, a warning died in a busy incident channel because receiving is not routing. In Episode 2, a handoff became a gap because a closed ticket is not a completed handoff. Episode 3 follows the same failure one boundary deeper: a checkpoint that everyone can point to and almost nobody passes through. The signal had a channel. The handoff had a ticket. The gate has a diagram. This episode is about what the diagram quietly trains people to do.
What Happens When the Gate Still Lives on the Diagram?
Maya, her review board, and that quiet room are composites, not a disguised client or a single remembered meeting. I use them because the pattern is real even when no one incident should carry the whole argument. The tools change, the industry changes, and the diagram changes.
I have sat in that room. I have watched a clean process diagram describe a route everyone knew the work no longer followed. The strange part is how quiet the room gets when the slide still looks right and the people in it know it is wrong.
On paper, the route looked disciplined. A request came in, requirements were gathered, the design was prepared, and the review happened before implementation. After that came testing, release, and whatever quiet satisfaction comes from a process chart that looks like it was designed by someone with a ruler, a framework, and three uninterrupted afternoons.
The real work had been moving through chat-thread approvals, code-review sign-offs, escalations, shadow workarounds, and late rework. The gate still lived in the documented process. The work had found other doors. Some gates work well, and plenty of organizations run reviews worth the time they take. This episode is about the ones that quietly stop working while the diagram keeps vouching for them.
This is the failure in one frame. The diagram shows intent. The route shows reality. When the real route flows around the gate, the box on the chart stops being proof of control and starts manufacturing false confidence, and false confidence is what makes leaders stop looking for the gap.
Existence Is Not Operation
Many organizations can readily prove they designed a gate. Far fewer can show that people actually use it. Fewer still can show that the gate changes decisions, catches risks, or leaves a record of meaningful scrutiny.
A documented control tells you what should happen. An operating control tells you what does happen. An effective control tells you that what happens actually reduces risk. Many teams stop at the first level because the first level is the easiest one to show in a slide, an audit packet, or an onboarding deck.
That is why “Do we have a gate?” is the wrong first question. The better question is “Can we show the gate operated the last time eligible work reached it?” Answering it requires evidence from real work: which changes were eligible, which ones entered, how long review took, and what happened afterward. Existence is the start of the question, not the answer.
What Does a Slow Gate Teach a Team Under Deadline?
The review queue shows four days. The change would take thirty seconds to deploy. The engineer looks at the sprint board, looks at the queue, and quietly scopes the work so it does not technically require the review. Nobody announces anything. Nothing in the process document changes.
People do not usually begin by rebelling against a gate. They adapt to friction, and a slow gate under deadline pressure becomes a lesson: the official route is not the route that gets work done. The system teaches the behavior through repetition, especially when bypassing gets rewarded with delivery and using the gate gets punished with delay.
This is how the loop forms. The gate slows the work, deadline pressure rises, someone finds a workaround, and delivery happens anyway. Leadership sees movement, the gate remains unchanged, and the workaround gets repeated until it stops feeling like a workaround at all.
That does not make the bypass noble. Do not praise the bypass; diagnose the route. Some bypasses are reckless, unsafe, or politically convenient, and repeated bypasses are still worth studying for one reason: they show where the documented route and the real work have drifted apart. When teams keep routing around a gate, the sharper question is not “Who broke the process?” It is “What did the process teach people to do under pressure?”
I wish I could say I have only observed this from a safe distance. I haven’t. I have made the practical choice, moved the smaller version of the work, and let the heavier review path become someone else’s future problem. That is not a confession because I think I was uniquely careless. It is a confession because I was being rational, the way most people in that seat would have been, inside a route that rewarded the wrong move.
The most dangerous gate is not the missing one. It is the one everyone believes is working.
The Architects of the Paper Gate
Go back to Maya’s room and look at who built this route. Somewhere upstream is the security architect who drew that diagram three years ago and meant every box of it. She is the Designer, and she built the gate in good faith to catch real risk. The compliance partner at the front of the room is the Inspector. His checklist has a field for whether the gate exists. It has no field for whether the work still visits. The Enforcer is not in the room yet. The incident reviewer who will eventually meet this gate arrives last, after the override has become a pattern, when the cost has a date and a name.
Each role is doing its job. The Designer can prove intent, the Inspector can prove documentation, and the Enforcer can prove damage. Nobody in the chain is positioned to prove operation, which is the only thing that was ever going to keep the gate real. As in the first two episodes, this is just a practical lens for inspecting the system, not a validated taxonomy. Changing any one actor would not fix the script.
Why Does a Thumbs-Up Count as a Review?
A three-second “LGTM” moves the change forward. A thumbs-up closes the thread. A green dashboard reassures a manager who has eleven other things to check before lunch. The workflow advanced, the record exists, and none of it proves that meaningful scrutiny happened.
Episode 1 called this the Ack Trap: acknowledgment creating the appearance of control. At a review gate, the trap scales up, because approval leaves an artifact. False proof can look more convincing than no proof at all.
Real proof looks different. Real proof has a named owner, review evidence, and a follow-up action. It tells you not only that the gate was touched, but that something happened inside it. The rubber stamp is not a personality flaw; it is a routing failure that appears when the approval mechanism is easier to satisfy than the underlying risk.
I have clicked approve when “approve” really meant “I trust you,” not “I checked this.” In hindsight, I wish I hadn’t let the time crunch rush what should have been a more intentional look. That distinction is small enough to disappear inside a workflow. It is also large enough to matter when the gate is supposed to protect the decision, and the fallout dwarfs whatever time the shortcut saved.
A stamp is not a review. A thumbs-up is not ownership. A completed workflow is not a completed decision.
Machine-Speed Output, Human-Speed Gate
The diff looks clean. Formatted, tested, documented, and confident. The reviewer scans it, feels the small pause where a question could go, and clicks approve, because questioning polished work feels like the slower path.
Part of that is mechanical, not moral. Reviewers lean on surface signals, and messiness is the cue that usually invites a closer look. Polished output removes the cue without removing the risk.
AI did not invent weak gates. It did not invent shallow review, performative approval, or the habit of treating a workflow as proof that judgment occurred. What AI changes is throughput. When generation gets faster, verification gets heavier, and the gate that barely worked at human speed starts absorbing machine-speed volume.
This does not mean AI killed code review. That claim is too broad, too dramatic, and too easy to misuse. The safer truth is more useful: AI-assisted work can increase the importance of verification, especially where the review route was already fragile. The danger is not that AI makes human review obsolete. The danger is that AI makes weak human review look productive for longer, moving more artifacts through the gate while less actual thinking happens per artifact.
The pressure revealed what the system already allowed.
What Does a Bypassed Gate Actually Cost?
The cost language here is local and illustrative. No borrowed industry number will match your team, but three familiar categories tend to surface when you trace a bypassed gate backward. Bystander Burn is the time several people spend half-monitoring a change nobody examined. Investigation Tax is the duplicated effort when the incident review has to reconstruct the scrutiny that should have happened at the gate. Compounding Rework is the cleanup when downstream work was built on a change that was approved but never inspected.
I have done the after-the-fact accounting in Azure DevOps. A change that looked small when it slipped through review came back later as clarification threads, duplicate investigation, and a blocked handoff between people who thought someone else had checked the risk. The original review might have taken thirty minutes from two people. The cleanup took parts of three calendars across two days we could not afford to lose, which is how a “faster” route quietly became the slower one.
The same gap bills different calendars. For the engineer, it shows up as a four-day queue wrapped around a thirty-second change. For the security lead, it shows up as a surprise escalation for something the diagram says was reviewed. For the manager, it shows up as a schedule slip explained by “waiting on review” for work that quietly never waited at all. Multiply the hours by your own loaded rates and the math becomes local, specific, and hard to ignore.
How Can You Tell Whether a Gate Is Real?
At some point, leadership has to move from confidence in the chart to evidence from the route. If the gate is real, the route leaves traces, and six signals will show them: adoption, cycle time, bypass reasons, ownership clarity, scrutiny depth, and update cadence. The audit below turns each one into a question you can ask in a thirty-minute review.
None of these are perfect on their own. A fast review is not automatically shallow, a long review is not automatically thoughtful, and review should take enough time to indicate actual attention given the complexity and risk of the change. Episode 1 readers will recognize the family resemblance: just as MTTO asks how long a signal stayed visible before someone owned it, these signals ask how long a gate has been visible without evidence that it operates. Both are local learning lenses, not scorecards for individuals.
Evidence of operation beats confidence in the chart.
Good Gates Match Risk to Scrutiny
A weak gate does not prove that governance is bad. It proves that governance needs to fit the work, so the answer is not fewer gates by default and not heavier gates everywhere. The answer is better-routed gates that match scrutiny to risk.
Low-risk changes should not wait behind the same gate as high-impact architectural decisions; automation, static checks, and safe-to-proceed criteria can carry that load. Medium-risk changes may need peer review and clearer decision checkpoints. High-risk changes deserve the deliberate version: named reviewers, impact assessment, human judgment, and an evidence trail. A gate that takes four seconds may be superficial, depending on the risk involved. A gate that takes four days may train avoidance if that delay does not come with visible value.
This is where the politics deserve care. Security is not the villain here, and neither are engineers, compliance, or managers, although managers (and, if we are honest, the rest of us) do have a remarkable talent for discovering “just one more quick thing” at the least helpful possible moment. In this story, the villain is mismatched routing: a gate too heavy for routine work, too weak for risky work, too slow for real delivery pressure, or too disconnected from any evidence that it operates.
How Do You Run the Gate Integrity Audit?
Pick one gate. Do not audit every gate in the organization at once unless your secret ambition is to create a governance swamp and then slowly sink into it with a clipboard. Choose one that matters, tied to security, architecture, change approval, or code review, and turn the six signals into six questions.
What percentage of eligible work actually used this gate? If the answer is vague, that is the first finding. How long does the gate take from entry to decision? Why do teams route around it? The reasons might be urgency, confusion, unclear ownership, hidden cost, or the quiet belief that the gate adds no value.
Then the second three. Who owns the result after approval, not who clicked approve, but who owns the decision and its consequences? What evidence shows real review happened: comments, test results, risk notes, follow-up actions? And when was the gate last changed based on what the organization learned? A gate that never changes is not automatically stable. It may simply be unattended.
The audit card started with one question I learned to stop softening: “How much eligible work actually goes through this gate?” If the answer is “probably,” “usually,” or “we think so,” the gate may still exist. The evidence does not.
The Gate Integrity Audit works best when you run it against recent, real changes with telemetry in hand, not as an annual slide in a compliance deck. The answers will not fix the system by themselves, but they will show you exactly where the documented route and the real route have drifted apart. From there you can make a responsible decision: automate routine checks, move scrutiny earlier, add ownership, shorten cycle time, or escalate high-risk work while lightening the rest. We will meet this diagnostic again later in the season, when we look at what a route that survives pressure has in common.
You can even retire a gate, but only after an alternative safeguard exists.
Removing friction without replacing protection is not maturity.
It is just faster exposure.
The Five-Change Field Test
You do not fix this with a transformation program. You fix it five changes at a time. This week, pick the last five changes that should have passed through the gate, and for each one, check four things.
Did it actually enter the gate?
Did it leave evidence of real review, not just an approval artifact?
Did the approval have a named owner with authority over the result?
If it had bypassed the gate entirely, would anyone have known?
Circle the change with no evidence behind it. That is your first route repair, and it will tell you whether your team has an adoption problem, a scrutiny problem, an ownership problem, or a detection problem. Those are different diagnoses, and they do not need the same fix.
The Gate Still Lives on the Diagram. Does It Still Live in the Work?
Modern work keeps widening the gap between documented process and actual flow. Work moves through chat threads, trackers, code platforms, meetings, dashboards, and AI assistants, and the real route is rarely as neat as the official one. The leader’s job is not to worship the gate. The leader’s job is to know whether the gate still works, and that takes operational evidence, not process nostalgia.
The process chart is not useless; it is a map of intent. But a map is not the road, and the road is where teams learn what actually gets rewarded. If the route rewards bypassing, the bypass becomes normal. If it rewards rubber-stamping, shallow approval becomes normal. If it rewards evidence, ownership, and calibrated scrutiny, the gate can become real again.
Now rerun Maya’s review, ninety days later, in the version where someone ran the audit. The same diagram goes up. The same question gets asked, and this time someone can answer it. Most eligible services went through the gate last quarter, the bypasses have reasons attached, and every approval names an owner. The room is not finished, but it is no longer guessing. The diagram has started catching up to the road.
The gate lives in the work now, not just on the slide. The only question left is whether yours does.
Subscribers received the Gate Integrity Audit Card below. This is a six-question diagnostic for testing whether a gate operates in reality, not just in documentation, with prompts for adoption, cycle time, bypass reasons, ownership, scrutiny depth, and update cadence, plus a worked example and the Five-Change Field Test tracker. If you want to test your own gates instead of guessing, the card is here:
This is also one of the practical arguments behind my upcoming book, Collaborate Better: collaboration improves when teams build clearer routes for trust, ownership, decisions, and action. A review gate is just a route with a checkpoint in it. You can learn more at CollaborateBetter.us.
Next in Route Rebuilder: Part 4, The Route That Confused Speed With Progress, where a velocity metric became the thing that hid rework.
P.S. Pull up your team’s process diagram. Pick one gate. Ask out loud when work last actually passed through it. Reply and tell me what you found. I read every one.
Evidence note
The evidence binder for this episode separates documented control guidance, delivery-performance research, and local illustrative examples. All bypass rates, review times, and costs in this article are illustrative and local; compute your own.
Regards,
Mark 👋
The Route Rebuilder · Episode 003 · Mark S. Carroll · Substack.Mark-Carroll.com
Previous:
More Content to Discover:
The most dangerous review gate is not the one people ignore.
It is the one leaders still trust after the work has learned to route around it.
What is one gate in your world that looks healthy on the process diagram, but would get uncomfortable fast if someone pulled the last five real changes and checked what actually happened?