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

The complaint about change advisory boards is that they're slow. The real problem is the opposite: they go too fast over too many things, and a board that reviews everything approves everything.

Aldermoor Health's CAB met Thursdays for ninety minutes and worked through about twenty-six changes. That's roughly three and a half minutes each, including the ones needing discussion.

Approval rate over fourteen months: one hundred per cent.

It would be easy to call that rubber-stamping, and easy to fix by telling people to take it more seriously. Both would be wrong. The board was staffed by competent people who cared. They had simply run out of the only thing a board actually supplies, which is attention — and three and a half minutes buys you a sanity check on the form, not a judgement about the system.

A board's only product is scarce, so spend it deliberately

A CAB doesn't produce approval. Approval is free. What it produces is cross-team knowledge applied to a specific change — the person who knows that the payments team is mid-migration, or that the last time someone touched that queue it took two days to drain.

That's a genuinely valuable input and it does not scale. One room, ninety minutes, a fixed number of humans: the supply is fixed no matter how many changes you put in front of it.

Which makes the design question simple to state and uncomfortable to answer: which changes are worth spending it on? The answer is only those where the board's specific knowledge could change the outcome. For everything else, the board is a queue.

The test you can run: take your last board meeting's agenda and, per change, ask what the board knew that the engineer didn't. Any change where the answer is "nothing" spent attention and returned none.

Route by class before the meeting exists

The filter that fixes the volume problem isn't in the meeting — it's upstream, in classification.

Aldermoor's twenty-six per meeting became six, and nothing was loosened. What changed is that the standard-change catalogue got filled from evidence, and standard changes don't go to the board by definition.

Change class	Goes to the board?	Because
Standard (pre-approved, done repeatedly)	No	The judgement was made once, at promotion
Normal, single team, reversible	No — team authority	The board knows nothing the team doesn't
Normal, crosses teams	Yes	This is the case boards exist for
Normal, hard to reverse	Yes	Cost of being wrong justifies the attention
Emergency	No — reviewed after	Waiting is the thing you're trading away

The two Yes rows are the board's actual job: changes where somebody outside the requesting team holds relevant information, and changes where being wrong is expensive enough to be worth an interruption.

The test: apply that table to your last agenda. Whatever fraction survives is what your meeting should have been.

Six changes, fifteen minutes each, and a real question

With six on the agenda, the format can change from processing to examining. Aldermoor's per-change format is three questions, and the third is the one that matters:

1. What breaks if this is wrong, and how fast would we know? Not "what's the risk rating" — the specific failure and its detection time.

2. What's the rollback, and has anyone done it? A documented rollback that's never been executed is a hypothesis. That distinction is the subject of rolling back safely.

3. Who in this room knows something the requester doesn't? Asked out loud, of the room, every time.

That third question is the entire reason for the meeting, and it is the one that almost never gets asked, because it feels like a formality until the week somebody answers it.

At Aldermoor it has been answered eleven times in nine months. Three of those stopped a change. One was a platform engineer saying "that queue has a two-day drain time, and you're planning to switch it on Friday."

The test: in your next board meeting, ask question three explicitly for every change. Count the answers. If the count is zero over a month with a full agenda, either the wrong changes are being reviewed or the wrong people are in the room.

Who's in the room decides whether it's worth having

Boards get staffed by seniority, which optimises for the ability to say yes rather than the ability to know something.

The membership that works:

• Someone from each team that consumes what's being changed. Not each team in the organisation — the dependents list tells you who.

• One person with operational history — who was on call, who remembers what broke.

• The requester, who presents and answers, and is not a bystander.

Who doesn't need to be there: anyone whose contribution is authority rather than knowledge. If someone's role is to accept responsibility, they can do that from the record afterwards; they don't need ninety minutes on a Thursday.

The size that works is five to eight. Beyond that, people stop speaking, and a silent attendee is a cost with no return.

The test: for each standing member, name the last time they contributed information that changed a change. Anyone with no instance in six months is attending out of habit.

When to kill it

A CAB is one mechanism for routing cross-team knowledge, not the only one, and it stops earning its place in identifiable conditions:

• You have automated dependency detection and per-service ownership. If the pipeline tells consumers automatically, the board's routing function is already covered.

• Deploy frequency exceeds meeting frequency by a lot. A weekly board and forty deploys a day is not a control, it's a fiction. What survives is async review on the small number of genuinely cross-cutting changes.

• The approval rate has been 100% for a year and you've applied the routing table above. That means the remaining changes genuinely don't need it.

• Teams have started routing around it. That's a verdict already delivered; the only question is whether you read it.

What should replace it rather than simply disappearing: a written path for cross-team changes to reach the people who'd know. Killing the board without that just removes the routing and keeps the risk — and delegated change authority is the framework-sanctioned way to write it down.

The test: if you cancelled the board tomorrow, which specific failure would go undetected? A concrete answer means keep it. A vague one about oversight means it's ceremony.

What to change this week

Don't reform the meeting. Shorten the agenda.

Apply the routing table to next week's list and cut everything that isn't cross-team or hard to reverse. Then, in the meeting, ask the third question out loud for each survivor — who here knows something the requester doesn't?

Aldermoor's board runs forty minutes now, six changes, and has said no three times this year. The number that changed most wasn't the duration. It was that people started bringing changes early to get the answer, rather than late to get the stamp.