Approval-Based Governance Fails the Moment Work Moves Faster Than Meetings

You are changing the tyres on a car doing 100 miles an hour. When you finish, the car needs to be a rocket doing a thousand. And while you work, the road is being rebuilt underneath you.

That is enterprise transformation, and it has always been roughly that hard. What has changed is not the difficulty. It is that one part of the problem got dramatically faster while the machinery built to control it did not.

Governance Was Built on an Assumption

Nearly every enterprise governance model in existence encodes the same assumption: a human being reviews each significant decision before it takes effect.

Architecture review boards. Change advisory boards. Design authorities. Stage gates. Sign-offs. All of these are implementations of one idea — that control is exercised by a qualified person looking at a proposal and approving it.

That assumption was sound for a long time, because it matched the tempo of the work. If a team could produce one significant change a fortnight, a fortnightly review board was adequate. The review was a real constraint on real risk, and the cost of waiting was proportionate.

The assumption breaks when the work rate crosses the review rate. And when it breaks, it does not fail loudly — it fails by turning into theatre.

What Failure Looks Like

You can recognise a review process that has been outrun without measuring anything, because the symptoms are behavioural.

Approvals become rubber stamps, because the queue is long and the reviewers do not have time to genuinely evaluate each item. The board meets, works through forty items in ninety minutes, and approves nearly all of them. Nobody is being negligent; there is simply no version of that meeting where forty items get real scrutiny.

Work routes around the process. Teams discover which changes require review and structure their work to stay under the threshold — not dishonestly, just responding to incentives. The governance process ends up seeing a systematically biased sample of what is actually happening.

And the reviews arrive after the decision. By the time an architecture board sees a proposal, the team has usually built enough to know it works, and the board is being asked to bless a fait accompli. Reviewers know this, which is part of why approval rates are so high.

At that point you are paying full price for governance and receiving very little of it. The comfort is real. The control is not.

Boundaries Instead of Gates

The alternative is not less governance. It is governance expressed as boundaries rather than approvals.

An approval model says: propose what you want to do, and a human will decide. A boundary model says: here is the space you may operate in autonomously; anything inside it needs no permission, anything outside it stops and escalates.

The difference matters because a boundary is evaluated continuously and automatically, while an approval is evaluated periodically by a person. Boundaries scale with throughput. Approvals scale with headcount.

Making that concrete: instead of reviewing each data access request, define which data classes may be touched by which systems for which purposes, and enforce it technically. Instead of approving each deployment, define the conditions under which a deployment proceeds — tests pass, error budget intact, blast radius bounded, rollback verified — and let anything meeting them go. Instead of signing off each spend decision, set thresholds and let anything below run.

The human judgment moves from evaluating each instance to defining the boundary and reviewing the exceptions, which is both higher-leverage and considerably more interesting work.

Where the Judgment Actually Belongs

This only works if you are honest about which decisions genuinely require a person, because the temptation is to claim all of them do.

Reserve human judgment for the decisions with these properties: irreversible, or expensive to reverse. Novel, meaning no boundary has been defined because nothing like this has come up. Cross-boundary, affecting parties who did not agree to the risk. Or value-laden, where the right answer depends on what the organization thinks is acceptable rather than on what is technically correct.

Almost everything else is a boundary problem.

The useful test is to look at your existing approval queue and ask, item by item, what the reviewer actually changed. In most organizations the honest answer for the large majority is nothing — which means those items were never getting judgment, only latency. Those are your boundary candidates, and you will find far more of them than you expect.

Exceptions Are the Signal

The part that makes this work over time, and the part most implementations skip: exceptions are information, not annoyances.

Every time something hits a boundary and escalates, you have learned that either the boundary is wrong or the work is genuinely unusual. Both are worth knowing. A boundary that generates constant exceptions is mis-drawn and should be redrawn. A boundary that never generates exceptions is either drawn correctly or drawn too loosely to constrain anything, and you should be able to tell which.

Track exception rates per boundary. That number tells you more about the health of your governance than any approval-cycle metric, and it is the mechanism by which the system gets better rather than merely older.

What Doesn't Change

Two things stay exactly as they were, and it is worth saying so plainly because "move faster" is frequently heard as "care less."

Accountability does not distribute. Someone is still answerable for outcomes, and defining a boundary is an act of accountability rather than a delegation of it. If a boundary was too wide, that is the fault of whoever drew it, not of the team that operated inside it.

And the record still has to exist. Faster does not mean unlogged. If anything the logging requirement is stricter, because the reconstruction of what happened can no longer rely on a human remembering the meeting.

The Actual Argument

The case for changing the model is not that speed is inherently good. Speed without control is not acceleration; it is just a shorter interval before the crash.

The case is that approval-based governance has already stopped working in most organizations that have adopted these tools, and the failure is currently invisible because the meetings still happen and the minutes still get written. Rubber-stamping forty items in ninety minutes feels like governance and is not.

The choice is not between control and speed. It is between control you can demonstrate and control you have merely retained the appearance of.

Digital Transformation at Machine Speed: How CIOs Are Using AI to Accelerate Change Without Losing Control covers the whole framework — AI-powered discovery and assessment, agentic planning, accelerated execution, knowledge capture at scale, the guardrails framework, risk management, trust architecture, and the metrics that matter.