The Artifact
Picture a change advisory board agenda for a Tuesday afternoon: 34 items, a 60-minute slot, and a standing quorum of six people. The arithmetic is not subtle. Sixty minutes divided among 34 items is roughly 105 seconds per change, minus the time spent on the two items that actually generate discussion. Whatever else the meeting accomplishes, it cannot be a technical review of 34 changes. It is a scheduling event with an approval record attached.
That is not a failure of the people in the room. It is a structural property of the format. A fixed-cadence gate with a growing queue has a shrinking review budget per item, and the budget shrinks fastest exactly when the queue is longest — that is, when the most changes are waiting and the most risk is nominally being reviewed. This essay treats the CAB as an artifact and asks what its agenda, quorum, and approval record can actually prove.
What the Gate Actually Produces
A weekly approval gate is a batching mechanism before it is a review mechanism. Consider two changes that would have shipped independently on Monday and Wednesday. Under a Tuesday gate, both wait for Tuesday and both ship in the same window. The gate did not slow each change equally; it synchronized them. The most reliable output of a fixed-cadence CAB is not a lower-risk change — it is a larger release unit.
DORA’s capability guidance on streamlining change approval describes this dynamic directly. Heavyweight approval approaches, it states, “tend to slow down the delivery process leading to the release of larger batches less frequently, with an accompanying higher impact on the production system that is likely to be associated with higher levels of risk and thus higher change fail rates” (dora.dev). The same page warns that responding to production stability problems by adding more process and heavier approvals is likely to make things worse “because this drives up lead times and batch sizes, creating a vicious cycle.”
Google’s SRE book makes the complementary point from the release-engineering side: “frequent releases result in fewer changes between versions. This approach makes testing and troubleshooting easier” (sre.google). The book also describes fitting the deployment process to the risk profile of a given service — hourly automatic pushes in pre-production, exponential cluster rollouts for large user-facing services, multi-day interleaved rollouts for sensitive infrastructure — rather than routing every change through one cadence.
This is where the CAB’s risk-reduction claim becomes partly self-defeating. If batch size is itself a risk factor — more changes interacting, harder attribution when something breaks, larger rollback surface — then a gate that increases batch size partially manufactures the risk it convenes to review. That is a mechanism argument, not a measured effect. It should be stated as a hypothesis to test locally, not as a finding.
What the Record Can Prove
Pull a year of CAB minutes and change tickets. What do they establish?
- Authorization: who approved what, when, and against what stated rationale. This is real and auditable.
- Notification: which teams knew a change was coming and when. Also real, and often the most valuable function the meeting performs.
- Calendar coordination: whether a change collided with a business freeze, a financial close, or another team’s migration window.
What they do not establish:
- Whether the approver understood the change. A one-line rationale and a checkbox do not demonstrate comprehension.
- Whether the change was technically safe. That evidence lives in the pull request, the test run, and the deployment log — not in the minutes.
- Whether the batch was safe in combination. The CAB reviews items; it rarely reviews interactions between items approved in the same window.
DORA names this limit explicitly: “CABs are good at broadcasting change, but people that far removed from the change might not understand the implications of those changes” (dora.dev). The minutes are evidence of authorization. They are not evidence of technical review, and citing them as such in a postmortem is a category error.
The Strongest Counterargument
Steelman the gate before dismantling it. A CAB does things a pipeline cannot. It surfaces cross-team collisions that no single team’s CI can see — two services scheduled to change the same shared dependency in the same week. It enforces a business-calendar check that no automated test knows about. It creates a paper trail that satisfies segregation-of-duties requirements, which DORA itself acknowledges as a legitimate regulatory goal: changes must be approved by someone other than the author. And in organizations with genuinely heterogeneous change — a database migration, a firewall rule, a vendor integration, and a feature flag toggle all in one week — a single risk-scored pipeline may not yet exist to route them.
DORA’s own guidance concedes a continuing role: “In the continuous delivery paradigm the CAB still has a vital role, which includes: Facilitating notification and coordination between teams… Weighing in on important business decisions that require a trade-off and sign-off at higher levels of the business” (dora.dev). That is a coordination and escalation role, not a code-review role. The counterargument is strongest when the CAB is scoped to exactly that — and weakest when the same meeting is also the mandatory gate for every routine deployment.
The empirical case against the gate as a quality control is narrower than it is often made to sound. DORA reports that heavyweight external approval approaches have “a negative impact on software delivery performance” and that “no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates” (dora.dev). Read narrowly, that is a correlation finding about approval bodies in the studied population. It is not a universal law that every committee in every organization is harmful. But it does shift the burden of proof: a CAB claiming to reduce change risk should be able to show, in its own data, that it does.
Testing the Batching Hypothesis Locally
A release owner can test whether the gate is batching risk without new tooling. The data already exists in the ticket system and the incident tracker. Five measurements:
- Items per meeting. Plot the count over time. A rising line with a fixed meeting length is a shrinking scrutiny budget.
- Minutes per item. If the meeting records durations, compute the average. If it does not, sample three meetings and time them.
- Approval rate. The proportion of submitted changes approved. A rate near 100% is consistent with formality rather than scrutiny — though it is not proof; a well-tuned standard-change catalog should also produce high approval rates for the changes that reach the board.
- Time-in-queue distribution. Not the average — the distribution. A weekly gate produces a characteristic sawtooth: changes submitted just after the meeting wait nearly a full cycle. The tail of that distribution is the gate’s real cost.
- Incident attribution to batched windows. For each post-release incident, record whether the failing change shipped alone or in a batch approved at the same meeting. If incidents cluster around batched windows, the batching hypothesis has local support.
These are measurement proposals, not findings. The point is that the CAB’s own records contain enough to test its central claim, and most organizations have never run the test.
The Non-Obvious Recommendation
Stop treating the CAB as a quality gate and start treating it as a collision detector — then measure it as one. Concretely: keep the meeting, but change what it reviews. Instead of approving individual changes, the agenda reviews conflicts: changes scheduled in the same window that touch shared dependencies, business-calendar collisions, and changes whose rollback plans overlap. Route individual change approval to peer review plus automated evidence in the pipeline, where DORA’s research says it belongs. Then instrument the meeting on the metric that matches its new job: the number of genuine cross-team collisions surfaced per meeting, and the number that would have been missed without the meeting.
This preserves the CAB’s defensible functions — notification, coordination, escalation of business trade-offs — while removing the function it cannot perform at scale. It also makes the meeting’s value falsifiable. If a quarter passes with zero collisions surfaced, the meeting is not a gate; it is a ritual, and the calendar should reflect that.
The artifact’s honest scope is narrow. A CAB can be a coordination and notification forum. It cannot be a code-review substitute, and its minutes should never be cited as evidence of technical review. The weekly cadence will keep batching risk for as long as it remains the mandatory path for routine change — and the batch, not the approval, will be the thing that ships.
FAQ
Does DORA say CABs should be abolished?
No. The retrieved DORA guidance says heavyweight external approval has a negative impact on delivery performance and no demonstrated correlation with lower change fail rates, and it names reliance on a centralized CAB to catch errors as a pitfall. It also describes a continuing CAB role in notification, coordination, and higher-level business trade-offs. The recommendation is to move individual change approval to peer review and automation, not to eliminate the forum.
If we remove the weekly gate, how do we satisfy segregation of duties?
DORA identifies segregation of duties — approval by someone other than the author — as a legitimate regulatory goal and points to peer review captured in the development platform as the mechanism, supplemented by automated detection. The specific compliance obligations vary by regulation and jurisdiction; confirm them against the primary text that applies to you rather than against a vendor summary.
Our approval rate is 98%. Does that prove the CAB is a rubber stamp?
It is consistent with formality, but not proof. A well-maintained standard-change catalog should also produce high approval rates for the changes that reach the board, because routine low-risk work should never reach it. The diagnostic is not the rate alone but the rate combined with minutes per item and whether rejected or deferred changes ever occur.
What is the single most useful number to pull first?
The time-in-queue distribution, not the average. A weekly gate produces a sawtooth that the average hides. The tail — changes that waited nearly a full cycle — is the gate’s real cost, and it is the number that makes the batching mechanism visible to people who have never sat in the meeting.
