A review system that treats every change as high risk creates two problems.

Reversible, contained work waits in the same queue as decisions that create durable data, shared contracts, customer exposure, or synchronized migrations. Meanwhile, the people with the judgment to review consequential commitments spend their attention on routine changes.

The result is more than delay. Slow approval encourages larger batches, postpones feedback, makes emergency response harder, and hides which decisions actually deserve cross-team or executive attention.

DORA's research on change approval gives this boundary an empirical basis.

Heavy approval is not the same as risk control

DORA's 2019 State of DevOps report examined formal external change approval. It found no evidence that a more formal approval process was associated with lower change fail rates in the studied data.

The report also tested a second hypothesis: additional approvals slow delivery and produce larger, less frequent batches with greater production impact. That hypothesis was supported in the data.

DORA's current capability guidance carries the finding forward. It recommends peer review during development, supported by automated testing, continuous integration, monitoring, and early feedback. It also calls out treating every change equally as a failure mode because routine work consumes attention that should be available for higher-risk changes.

This evidence concerns software delivery practices. It does not prove that every architecture review, regulatory control, or independent approval is waste. It shows why the number of approvals is a weak substitute for a system that identifies risk early and routes it to the right level.

Keep a strategic review path

DORA does not remove leadership or change advisory bodies from the system. It gives them a different job: cross-team coordination, process improvement, and business decisions that require an explicit tradeoff and sign-off.

Google SRE's production guidance makes a related distinction at rollout time. Nonemergency configuration and binary changes proceed in stages, and the rollout size and time between stages depend on the service and risk profile. The control changes with the possible consequence.

That is the useful boundary. Routine controls should be close to the work. Additional review should appear when the commitment becomes durable, broad, or difficult to observe and contain.

Use two review lanes

For a CTO or engineering leader, a practical review route can begin with two questions:

  1. What work would reversal require after adoption?
  2. Who or what can inherit the consequence before detection and containment?

If the change is reversible and contained, use a team-local lane. Require an owner, peer review or equivalent segregation of duties, automated controls, a small batch, a recovery action, and a short observation window. Let the team proceed without waiting for an unrelated committee.

If the decision creates durable state, a shared contract, broad customer or security exposure, or several roadmaps that must move together, use an escalated lane. Bring in the affected owners. Compare credible alternatives, reduce the first commitment, stage exposure, define stop authority, and name the exit owner.

The second lane is not a punishment. It protects a decision whose consequences cannot remain inside one team.

Promote a decision when its commitment changes

The first classification is temporary. A contained experiment can become a shared dependency. A reversible implementation can become durable after historical data, operating procedures, contractual expectations, or consumer assumptions form around it.

Define promotion triggers before rollout. Useful triggers include a new consumer class, customer-facing exposure, durable state, removal of the old path, a regulatory obligation, or a point after which several teams must migrate together.

When a trigger appears, move the decision into the escalated lane. Do not keep calling it an experiment because that was its original label.

Measure the review system

DORA suggests measuring approval waiting time and the share of low-, medium-, and high-risk changes that require manual or external approval. That exposes whether governance is selective in practice.

Add batch size, change lead time, failed-deployment recovery time, change fail rate, and rework. Keep the measures at the application or service level where their context remains visible.

For the architecture-review queue, also record the reason for escalation. If contained reversible work waits as long as durable broad commitments, the review system is not allocating attention by consequence.

The goal is not to make review disappear. It is to keep routine change safe and fast enough that scarce judgment remains available when a technical decision can remove options for several teams or the business.

Sources

The two-lane review route is Gevorg's application of Reversibility and Blast Radius to the cited public sources. This field note does not report an employer implementation, customer result, advisory delivery, or measured commercial outcome.