RFCs that pass CAB the first time

Tuesday, 10:00, change advisory board. Fourth item on the agenda: a firewall change, submitted by an engineer who is not in the room. The RFC says what will change but not what happens if it goes wrong. Someone asks about rollback. Silence. Deferred to next week.

Now the change is a week late, the engineer thinks CAB is bureaucratic theatre, and CAB thinks engineers submit half-finished requests. Both are a little bit right, and the cycle repeats every Tuesday in thousands of organisations.

Here's the thing though: a deferred RFC is almost never a rejected idea. It's an incomplete document. CAB rarely says no to well-described changes; it says "come back when we can tell what we're approving." Which means first-time approval is mostly a writing problem, and writing problems are fixable.

What CAB is actually checking

Strip the ceremony away and a change board answers three questions. Do we understand what's changing and why? Do we believe the risk has been thought through? And if it goes wrong, is there a way back that doesn't require heroics?

Every field in a good RFC serves one of those three. Everything else is form-filling.

The change, in plain words. What is changing, on which systems, for which reason. One paragraph a non-specialist board member can follow. If the business reason is missing ("why now?"), expect a deferral, because "approve this because I say so" is what an RFC without a why amounts to.

Impact and blast radius. Which services and users are touched, during and after. Include the honest worst case: "if this goes badly, VPN access is down for all remote staff until rollback completes." Boards trust requests that name their own worst case; they defer requests that pretend there isn't one.

The window and the duration. When, how long, and why that window. Include how long the rollback takes, because a 30-minute change with a 3-hour rollback is a 3.5-hour risk window, and pretending otherwise is how Saturday nights get ruined.

The plan, tested. Steps in order, and whether they've been rehearsed anywhere. "Tested in staging on the 12th, same versions as production" changes the risk conversation entirely. If there is no test environment for this change, say so and compensate with a more conservative window.

Rollback, specifically. The section that kills more RFCs than any other. "Restore from backup" is not a rollback plan; it's a category of hope. Which backup, taken when, restored how, taking how long, verified by what check? If the change cannot be rolled back (some can't), the RFC should say that in plain text and describe mitigation instead. Boards can approve irreversible changes; they just refuse to discover irreversibility during an incident.

Verification. How you'll know the change worked, beyond "no complaints yet." A named check, run when, by whom.

The completeness check before submission

The cheapest process improvement available to any change process: nobody submits an RFC without a two-minute completeness pass against a fixed list. Not a quality review, just presence: is every section filled with something real?

This is also a task AI handles well as a first pass. Give an assistant your RFC and a strict rubric and ask what a sceptical board member would flag. It will catch the missing rollback duration and the unstated business reason faster than a colleague skimming out of politeness. We keep this rubric as a printable RFC completeness checklist in the Opstimio library, next to the pre-implementation checklist that picks up where approval ends, because no two minutes in the whole change process pay back better than the two just before submission.

Standard changes: the reward for writing well

There's a compounding payoff. Once a change type has passed cleanly several times with the same well-documented procedure, it's a candidate for pre-approval as a standard change: executed against the fixed procedure, logged, no board time at all.

This is how mature teams keep CAB meetings short: not by lowering the bar but by graduating repeatable work out of the meeting entirely. The board spends its attention on the genuinely risky changes, engineers stop waiting a week for routine work, and the Tuesday agenda shrinks from fourteen items to five that deserve discussion.

That future is built one complete RFC at a time. Start with the next one you submit.