Every organization I’ve worked in has had a change advisory board, and most of them were theatre.
A weekly meeting. Thirty changes on the agenda. Twenty-five minutes of actual discussion, which means roughly fifty seconds a change. Everything gets approved, because nobody in the room has the context to challenge any of it, and the one person who does isn’t there. Then something breaks on Saturday and the finding is “the change wasn’t properly reviewed.”
It was reviewed. That’s the problem. It was reviewed by a process that couldn’t possibly have caught anything.
The board is not the control
The useful question isn’t “did a board approve this.” It’s “did the right person look at the right risk before this went out.” Those come apart quickly at any volume.
What actually reduced release-related incidents for me — by about half, across ten or more concurrent infrastructure and application releases — wasn’t a stricter board. It was sorting changes so the board only saw the ones worth its time.
- Standard changes. Pre-approved, documented, repeated. A known patch, a scripted restart, a certificate renewal. These need a record, not a meeting. If you’re discussing a certificate renewal in a governance forum, you have a process problem, not a risk problem.
- Normal changes. Assessed on risk, approved by someone with the context to say no. Most of these never need a room — they need a named approver who understands the system.
- Major and emergency changes. These get the board, and because the board is now seeing four of them instead of thirty, it can actually do its job.
Getting the standard-change catalogue right is most of the work, and it’s the part everyone skips. It’s tedious. It’s also what buys back the attention you need for the changes that can hurt you.
What a real risk assessment asks
Four questions. If a change record can’t answer them, it isn’t ready, regardless of who approved it.
- What breaks if this goes wrong? Named services, named customers. Not “potential impact to the environment.”
- How do we know it worked? A specific check, performed by a specific person, within a specific window. “Monitor for issues” is not a verification plan.
- How do we back it out, and how long does that take? If the answer is “restore from backup,” you’ve just told me your rollback is measured in hours. That’s fine — but the business should know that before Saturday, not during it.
- What else is going out at the same time? Most changes are safe alone. The incidents come from three safe changes landing on the same night.
The one that gets skipped
Backout. Every time.
People write the implementation plan carefully and then write “revert change” in the backout field. Under pressure, at 2am, “revert change” is not a plan — it’s a hope. The test I use is simple: could someone who didn’t write this change execute the backout from the record alone? If not, it isn’t a backout plan.
Governance that people route around isn’t governance. The goal is a process light enough that following it is easier than not.