Most delivery governance fails in the same direction. It accumulates. A release sign-off here, a steering committee there, a Change Advisory Board added after the last incident, an architecture review bolted on after the one before that. Each addition is locally reasonable and globally corrosive. The result is an organisation that confuses the volume of approval with the quality of decisions, and pays for it in lead time. The senior engineering reality is starker: governance that slows everything down rarely makes anything safer. It mostly makes accountability diffuse and decisions late.
The fix is not less governance. It is governance designed around decision quality rather than decision permission. Two things have to be true at once: the consequential, hard-to-reverse decisions get genuine scrutiny, and the reversible, everyday ones get out of the queue. Get that separation right and governance becomes an accelerant. Get it wrong and you have built a tax on flow that nobody can repeal.
Not all decisions deserve the same door
The most useful mental model here is not ours. In Amazon's 2015 Letter to Shareholders, Jeff Bezos distinguished Type 1 from Type 2 decisions: Type 1 are one-way doors, consequential and nearly irreversible, and deserve to be made slowly, with deliberation and consultation; Type 2 are two-way doors, reversible, and should be made quickly by high-judgement individuals or small groups. His warning is the part most boards miss: applying a single heavyweight process to every decision is not prudence, it is a category error that crushes the many to insure against the few.
Apply that lens to a typical release pipeline and the waste is obvious. A schema migration that can be rolled back, a feature flag, a copy change, a dependency bump behind tests, these are two-way doors. Routing them through the same board that should be examining a data-residency commitment or a public API contract is how you manufacture both bottlenecks and complacency, because reviewers facing a wall of trivial decisions stop reading carefully. The board's authority is finite attention; spend it on the doors that do not swing back.
What the evidence says about heavyweight approval
This is not merely a matter of taste. The empirical case against blanket control is now reasonably strong, and it cuts across several independent kinds of evidence. Practitioner analysis drawing on the 'Accelerate' research of Forsgren, Kim and Humble reports that external change-approval processes such as Change Advisory Boards were negatively correlated with lead time, deployment frequency and time to restore, and showed no correlation with change-fail rate at all. Read that twice: the boards slowed delivery without making it safer. Risk-tiered peer review and automation for low-risk changes outperformed them on both axes.
More interesting is the peer-reviewed picture, because it resists the obvious overcorrection. Research published in Springer's Empirical Software Engineering journal, 'Finding the sweet spot for organizational control and team autonomy in large-scale agile software development', finds that neither full autonomy nor heavy central control is optimal; outcomes improve when the two are deliberately balanced. That matters. The lesson of the CAB evidence is not 'abolish governance and let teams do what they like'. It is that control and autonomy are not opposing dials but complementary settings, and the engineering job is calibration, not abolition.
Governance as decision rights, not gates
Once you accept calibration as the goal, governance stops being a queue and becomes a wiring diagram. Gartner defines governance as 'the specification of decision rights and an accountability framework', and its recent operating-model guidance favours federated models that combine local decision ownership with automated policy enforcement (analyst framing). The standards bodies land in the same place. ISO/IEC 38500:2024 frames governance as an Evaluate–Direct–Monitor cycle, with a Responsibility principle that insists on clearly assigned roles and decision-making rights, positioning the board's job as asking the right questions and tracking benefit and risk, not operating the gate.
The mechanism that makes decentralised decision rights actually work, rather than degenerate into local chaos, is again borrowed and worth attributing precisely. Andrew Harmel-Law's Architecture Advice Process, set out in his 2024 O'Reilly book 'Facilitating Software Architecture', lets anyone take a decision provided they first seek advice, explicitly not permission, from those affected and those with relevant expertise. The decision-taker keeps full ownership and is not obliged to follow the advice. InfoQ's 2026 coverage of the approach makes the point that this regulates decentralised decisions to keep them aligned with the right stakeholders rather than removing governance, which is exactly the calibration the academic work argues for.
Heavyweight approval boards slow delivery without improving safety. The work is not to remove governance but to move the decision to the person with the judgement, and route the advice to them instead of routing them to a queue.
Why the wiring shapes the system
There is a deeper reason decision rights deserve this much care. Melvin Conway's 1968 paper 'How Do Committees Invent?' established that organisations are constrained to produce designs that copy their own communication structures. The corollary for governance is uncomfortable: the way you wire your boards and approvals does not just regulate the system, it determines what system you are able to build and how fast. A delivery organisation with a single central approval chokepoint will tend to produce coupled, slow-to-change architecture, because that is the shape of its conversations. Decentralise the decision rights and you change the system's achievable shape.
Lightweight governance also needs a memory, or it relives the same arguments. Michael Nygard introduced Architecture Decision Records in his 2011 post 'Documenting Architecture Decisions', short records capturing Title, Status, Context, Decision and Consequences, on the grounds that the hardest thing to track over a project's life is the motivation behind decisions. ADRs are the cheap governance artefact that makes decentralised decisions auditable without a board: the rationale is durable, the reviewer is whoever cares later, and the cost is two pages.
The widening gap, and the AI pressure
The stakes are rising because oversight is not keeping pace with delivery. Digital.ai's 2025 State of Agile Report finds only 49% of organisations have governance guardrails in place even as AI adoption accelerates (industry survey). McKinsey's Developer Velocity research, meanwhile, links top-quartile organisations to revenue growth several times that of peers, and its 'agentic organisation' thesis argues AI forces governance to become continuous and decision velocity to drop below the human layer (analyst framing). When agents are taking two-way-door decisions at machine speed, a quarterly board is not governance, it is a souvenir. The guardrails have to be encoded, tiered and fast, or they will simply be bypassed.
What a CTO should actually do
Start by classifying. Audit your current approvals against the one-way/two-way door distinction and delete the gates that guard reversible decisions; replace them with risk-tiered peer review and automated policy checks. Reserve real board scrutiny for the genuinely irreversible. Specify decision rights explicitly so accountability is concrete rather than diffuse, adopt the advice process so expertise reaches the decision-taker without a permission queue, and make ADRs the default record so the system remembers why. Then measure governance the way you measure everything else, by its effect on flow and on outcomes, not by the number of meetings it generates. Governance that cannot show it improves decision quality is just cost wearing a lanyard.
If you want the broader frame this sits inside, the governance question is really a special case of the translation layer between intent and outcomes that decides whether delivery organisations succeed at all. We develop that argument in our piece on the missing layer between strategy and delivery, and the practical companion on how to measure product delivery so the metrics reward decision quality rather than approval volume.