Insight
The Governance Tax: When Risk Management Becomes the Risk
Every gate started with a reason. The reason may still be valid. The control still has to show what risk it reduces and what it costs to do so.
A bounded warning from software delivery
DORA’s 2019 State of DevOps survey examined formal external approval for significant software changes, such as approval by a change advisory board or senior manager. Respondents in organizations with that process were 2.6 times more likely to be low software-delivery performers.
The report found no evidence supporting the hypothesis that formal external approval was associated with lower change-failure rates. Its data supported a different path: more approvals, slower process, larger and less frequent batches, and greater production impact.
That result belongs inside its boundary. It came from a 2019 software-delivery survey. It does not prove that every financial, safety, legal, regulatory, architecture, or investment gate is harmful.
The counterfinding matters too. Respondents with a clear, understood change process were 1.8 times more likely to be elite performers. Governance clarity can help even when heavyweight external approval hurts.
DORA’s change-approval guidance keeps that distinction. Routine software changes can use peer review and automated checks close to the work. Higher-risk changes receive added scrutiny. The change process itself should be measured and improved.
The broader lesson is not borrowed statistics. It is a testable mechanism: a control can increase risk when its crossing cost drives larger batches and slower feedback.
How a rational control becomes a tax
Something went wrong. A production change caused an outage. A contract exposed the company. A team crossed an architecture boundary without seeing the downstream effect. An audit found missing evidence.
The organization responded with a review, sign-off, standing board, or another packet of required proof. The response made sense when it was added.
Years later, the original exposure may have changed, the evidence may have improved, and the people closest to the work may have stronger controls. The gate remains because removing it feels risky, while measuring it belongs to nobody.
That is how a rational control becomes an unmeasured operating tax.
Count the whole cost
The meeting is the visible cost. It is not the whole cost.
Preparation is the evidence assembly, reformatting, signature chasing, and rehearsal required before review.
Queue time is the wait for the next board, specialist, or executive window.
Batching pressure is work held or combined because each crossing is expensive.
Delayed learning is customer, technical, policy, or business evidence postponed until the gate releases the work.
Together these costs form the Governance Tax. The gate consumes capacity before review, holds value during the wait, changes behavior around the crossing, and pushes learning downstream. Governance Drag carries the complete mechanism and boundary conditions.
When the control increases exposure
A gate can reduce one risk while creating another.
A monthly review may prevent an unauthorized decision but extend exposure to a known defect. A broad architecture board may catch a cross-system dependency but encourage teams to bundle unrelated changes into one submission. A detailed investment packet may improve executive visibility while delaying a reversible experiment that would replace assumptions with evidence.
Those trade-offs do not make the original risk imaginary. They make the full system visible.
The right question is not, “Did the gate catch something?” Ask whether the gate’s decision value and risk reduction justify preparation, waiting, batching, and delayed learning. Include obligations and rare high-impact exposure in that judgment. A low rejection rate cannot answer the question by itself.
Make the gate earn its cost
Start by separating item classes.
Routine, reversible, low-risk work may fit preapproved standards, peer review, delegated authority, automated evidence, or post-action monitoring. Consequential, irreversible, novel, or mandatory decisions may deserve broader review and explicit trade-offs.
This preserves scarce attention for the decisions that need it. It also gives the control a measurable design:
- explicit decision rights;
- risk tiers with different paths;
- evidence requirements matched to the decision;
- a service expectation for review time;
- an owner accountable for the control’s performance;
- lead-time and risk signals reviewed together.
You do not need to dismantle governance. You need to make it earn its cost.
Audit one gate
Choose one recurring gate and inspect a practical sample, such as the last twenty items that crossed it. Twenty is a starting point, not a threshold or score.
Use the six fields defined in Governance Drag: intended risk, preparation effort, wait time, decision yield, induced batching, and a lower-cost control.
Run the alternative for one operating cycle. Compare lead time, incidents, detected escapes, rework, and obligation-specific evidence against the baseline. Then retain, tier, delegate, automate, redesign, or remove the gate. The decision rests on the gate’s actual work, wait, behavior, and risk signals.
The bill belongs to leadership
Teams can document preparation effort and waiting. Risk, compliance, architecture, finance, and security specialists can explain the exposure the gate is meant to control. The authority to redesign enterprise governance usually sits with leaders who own the policy and its trade-offs.
That ownership carries a simple obligation: measure the control as part of the operating system. A gate that is never reviewed becomes policy debt. Another failure adds another layer, and the layers keep accumulating because each one looks safer than removing anything.
Each layer made sense when it was added. The stack can still become irrational.
A gate should be able to show what risk it reduces and what it costs to do so.
Sources and lineage
This Insight is derived from the Governance Drag and Choked Flow treatments in Applied End-to-End Flow: Enterprise, the Enterprise Implementation Guidelines, and the jointly authored April 2026 Governance Tax article. The argument and six-part audit are Applied End-to-End Flow synthesis. The external software-change example comes from DORA’s 2019 State of DevOps report and Streamlining Change Approval guidance. Those findings are presented within their software-delivery scope.
Curtis Hibbs and Joshua Barnes are co-creators of Applied End-to-End Flow and co-authors of Applied End-to-End Flow: Enterprise. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.