How to Run a Change Advisory Board (CAB) That Doesn't Slow You Down

Contributor
May 11
6 min read

The Change Advisory Board (CAB) is the most-hated meeting in IT. Engineers describe it as a place where deploys go to die. Operations describes it as the only thing standing between them and 3am pages. Both views are partly right, which is why CABs are worth understanding rather than just abolishing.

A well-run CAB catches real risk early, builds shared understanding of upcoming changes, and accelerates delivery by reducing rework. A badly run CAB is a ceremonial bottleneck where senior people approve things they don't understand based on documents they didn't read. The difference is design, not the existence of the meeting.

This guide is a working playbook for running a CAB that the engineering team is glad exists.

What a CAB Is For

The CAB exists to do three things:

Catch risk that the change owner couldn't see. Cross-team dependencies. Operational impact. Customer communication gaps. The change owner is too close to spot all of these.
Coordinate timing across teams. Two changes that are individually safe can be jointly catastrophic. The CAB is the venue where that gets caught.
Make a deliberate go/no-go decision when the risk is real. Not all changes are approved automatically. Some need a conversation.

If a CAB is doing things other than these — rubber-stamping low-risk changes, debating things that aren't decisions, reviewing changes already in production — it's broken.

What a CAB Is Not For

It is not where every change must be approved. Standard changes — well-understood patterns with documented runbooks — should bypass the CAB entirely.

It is not where the change owner is grilled. The grilling pattern produces defensive change owners who hide risk to get through the meeting.

It is not where you decide whether to do a change. That decision happens before the CAB. The CAB decides whether the proposed plan is safe to execute now.

It is not status reporting. If most of the meeting is people describing what they're working on, you have a status meeting wearing a CAB t-shirt.

Who's in the Room

The minimum useful CAB has four roles:

Chair — runs the meeting, owns the decisions, escalates when needed. Not the most senior person in the room; the person who'll actually run the meeting on rotation.
Operations representative — knows the runtime environment, on-call impact, and customer-visible operational changes.
Security representative — checks for compliance, data exposure, access changes.
Business representative — knows what's happening on the customer or business side that might collide with the change.

Add roles as needed. Don't add roles for political reasons — every additional attendee makes the meeting slower and quieter (people defer to other people).

The change owner attends for their change and only for their change. They don't sit through every other change. This single rule recovers more engineer time than any other.

The Standing Agenda

A working CAB agenda is short and structured:

Closed loop on previous changes (5 min). Anything from last week's changes that went wrong? Anything we want to learn from?
Standard changes log (3 min). Brief acknowledgement that standard changes happened — not approval, just visibility.
Normal changes (most of the meeting). Each one: brief, decide, move on.
Emergency changes since last meeting (5 min). Retrospective on any out-of-band changes.
Upcoming risks (5 min). What's coming that we should be aware of but isn't ready for CAB yet.

A 30-minute weekly CAB can comfortably handle 6-8 normal changes. If you're consistently overflowing, the problem is usually that too many things are being classified as normal when they should be standard.

The Per-Change Format

For each normal change, the format is tight:

Two-minute summary from the change owner. What, when, who's affected, what's the rollback.
One round of questions. Each rep can ask one substantive question.
Decision. Approve, approve with conditions, defer for more information, reject.

Two minutes is enough for any change. If the change owner can't summarize it in two minutes, it's either not ready for CAB or it's too big — split it.

The single-question discipline prevents the meeting from being dominated by one person's pet concern. If a rep needs a deeper conversation, it happens offline.

What Approval Conditions Look Like

"Approve with conditions" is the most useful CAB outcome. It looks like:

Approved, but ship Tuesday morning, not Friday afternoon.
Approved, but with the rollback plan tested in staging first.
Approved, but with explicit customer notification 24h ahead.
Approved, but the on-call team is paged during the window.

Conditions let the meeting move forward without rubber-stamping. The change owner gets a clear, actionable adjustment rather than a vague "be careful."

The Standard Change Catalog

Most of the speed gains from a working CAB come from aggressively expanding the "standard change" catalog.

A standard change is a pattern you've done many times, with a documented runbook, that doesn't need per-instance review. Examples:

Deploying a code change through the normal pipeline to a service that's been operating stably
Adding a new IAM user from the approved template
Rotating a credential using the standard rotation tool
Scaling capacity within pre-approved bounds

Each standard change is a one-time approval (the pattern is approved) and a log entry per execution. Engineers can ship the change without waiting for a meeting.

The rule for adding to the catalog: propose a candidate, run it through CAB three times as normal changes with no incidents, then promote it. The catalog grows over time as the team builds shared confidence in repeatable patterns.

The size of the standard change catalog is the single best metric for CAB health. A growing catalog means the team is codifying confidence. A static catalog means the CAB is in maintenance mode.

Emergency Changes

Emergency changes happen outside the meeting cadence. Production is broken; someone needs to ship a fix.

The process: ship, log, retrospective.

Ship. Authority to declare an emergency rests with the on-call lead or incident commander. They don't need pre-approval. They do owe an explanation.
Log. Within 24h, document what happened: the symptom, the fix, the verification.
Retrospective. At the next CAB, the emergency is reviewed. Was it really an emergency? Could the underlying issue have been caught earlier? Is there a pattern emerging?

The danger is "emergency creep" — the team learns that emergency changes skip the meeting, and suddenly everything is an emergency. Track the ratio. If more than 10-15% of changes are emergencies, the process is being gamed.

What Engineers Hate, and How to Fix It

Common engineer complaints, with the actual fix:

"It blocks shipping." Fix: expand the standard change catalog, run CAB more frequently (twice weekly, daily standups for hot weeks), allow async pre-approval for changes submitted with full plans.

"It's pre-decided." Fix: make the meeting actually discuss substance. If the chair is rubber-stamping, the meeting is theater. Either make it real or kill it.

"It's status reporting." Fix: cut the status reporting. Restrict the agenda to decisions.

"The questions aren't useful." Fix: train the reps. A good CAB rep asks about blast radius, rollback, and customer impact — not about implementation details that should have been reviewed by the change owner's team.

"Same people block everything." Fix: enforce the one-question rule. Escalate consistent blocking patterns to leadership for resolution outside the meeting.

When to Kill the CAB

Sometimes the right answer is no CAB at all. Indicators:

Your team has very few cross-team dependencies (small org or strict modularity)
The catalog of standard changes covers nearly everything you ship
You have strong async review processes (PR reviews, ADRs) that catch what CAB would catch
Production incidents are rare and attributable to design issues, not approval gaps

If those are true, the CAB is overhead. Replace it with a weekly async digest of what shipped and what's planned.

The reverse is also true: a team that's never had a CAB and is now experiencing repeated cross-team incidents should consider adding one. It's a tool that fits some contexts, not all.

Key Takeaway

A useful Change Advisory Board catches cross-team risk, coordinates timing, and makes deliberate go/no-go decisions on changes that matter. It is not for standard changes, status reporting, or rubber-stamping. The biggest speed win is aggressively expanding the standard-change catalog so most work bypasses the meeting. Keep the agenda short, the per-change format tight (two-minute summary, one round of questions, decision), and the room small. If the engineering team views CAB as a place deploys go to die, redesign or replace it — but don't pretend a broken CAB is a working one.

ShiftQuality