HIVE80lab — Ops notes

Change advisory board for small teams: a 10-minute review that isn't theater

The ITIL change advisory board — a weekly meeting where changes are read aloud to people who do not operate them — deserves its reputation. In small teams it decays into one of two failures: forty changes rubber-stamped in forty-five minutes (a queue wearing a meeting's clothes), or no review at all until the Friday migration takes the billing database down. Both miss the same point. A change review exists to answer, before merge, five questions that predict most change-induced incidents. Answer them in writing, in the pull request, and the board dissolves back into the work.

This note gives the five-question card, the short risk-class list that decides what gets extra scrutiny, the async setup that replaces the meeting, the five traps that turn a CAB into approval theater, and a one-afternoon rollout.

1. The five-question change card

Every change answers these in its description — one line each, in writing. Unwritten answers do not count; the point is that writing them down is where the thinking happens.

2. Risk classes: short, or pointless

Scrutiny must be rationed or it stops being scrutiny. Four classes is enough for most small teams:

The list stays short by force. The moment most changes are high-risk, the classes have stopped measuring risk and started measuring politics — and reviewers stop reading, which is how the one dangerous change slips through wearing the same label as the other thirty-nine.

3. The meeting, replaced

Under roughly twenty people, the review is async: the five answers live in the PR template, the reviewer for Class 1–3 changes is a named second pair of eyes (rotate it; the same approver every time is a single point of failure with a calendar invite), and merge waits on that one approval. Nobody attends a meeting to hear a change described.

What survives as a meeting is a 10-minute weekly slot with one agenda: the changes that failed or nearly failed this week. Not a re-approval of the week's changes — a review of the process that let them through. This is the slot where someone says the backfill answer on Wednesday's change was "we hope it's fine," and we merged it anyway, and the card gets a rule added. Failed changes feed the same weekly table as the DORA four numbers, so the process is judged by its receipts.

For the changes that need an approver at 3am, pre-write the authority: the standing-orders ladder already answers who decides when the decider is asleep, and a CAB that ignores it will be ignored right back.

4. The five traps

Approval theater. A board that approves forty changes a week is a queue with minutes. If reviewers cannot remember what they approved yesterday, the review does not exist — it is a signature factory. The fix is classing down: fewer changes deserve a meeting than anyone expects.

The emergency loophole. When everything urgent bypasses review, "urgent" becomes a label people apply under deadline pressure, and the review only ever sees the safe changes. The repair: emergency changes still get reviewed — retrospectively, within 48 hours, in the weekly slot. Review after the fact is not as good as before; it is infinitely better than never.

Review by people who can't operate the thing. A change approved by managers and merged without the on-call who will catch its pager is a ritual, not a review. The operator belongs in the loop; often they are the only reviewer who has seen this system fail before.

The freeze as the only tool. A change freeze is for exceptional windows — peak season, an active incident, a migration weekend. As a substitute for review it backfires: changes queue up behind the freeze and ship in one avalanche when it lifts, which is precisely the big-bang pattern that produces the worst failures.

No record. A verbal approval leaves nothing to learn from. One line in the deploy log — what shipped, who approved, what class — is enough to answer, three incidents later, "what changed on Thursday?" without archaeology. The post-mortem for a failed change starts from that line.

5. Worked example

A nine-person logistics SaaS runs the classic CAB: Thursdays, 45 minutes, twenty-three changes on the deck, all approved. The approvals mean so little that a Thursday-approved database migration ships Friday with a rollback script that has never been run — and when it melts the orders table, the script turns out to reference a column that was renamed two migrations ago. Recovery takes eleven hours and one very quiet morning of order intake.

The redo is one afternoon: the five questions go into the PR template as required fields, the four classes get defined, and the Thursday meeting shrinks to a 10-minute failures-only review. The first month is noisy — engineers object to writing five lines — until the card catches its first backfill whose honest answer to how do we undo it? was "we can't," and the team watches a potential eleven-hour incident die in a comment thread instead of production. A quarter later: change failure rate down from 31% to 11%, meeting time down from 45 minutes to 10, and the two riskiest changes of the quarter were caught by question two. The counter-example is the sister team that responded to the same class of incident with a six-week freeze instead: changes piled up behind it, then shipped in one three-day avalanche, and the post-freeze fortnight produced more incidents than the freeze prevented.

6. Metrics (for the metric itself)

Data migrations are where the change card earns its keep: the database migration checklist turns the five questions into a hard gate — the undo is tested on a copy before the migration ships, not imagined during the incident. And once review approves, the release checklist for small teams walks the change from green build to shipped in twelve boxes.

The release checklist is the card's downstream twin: the release checklist turns the approved risk class into the twelve boxes a shipper actually checks — four for a normal release, all twelve when the card says data, auth, or money.

From the HIVE80lab kit

Related: the deployment rollback checklist is what question two commits you to, the change-freeze window policy covers the exceptional windows review can't, and the incident post-mortem template is where a failed change gets its receipt.