The Reputation Problem
Change management has a branding issue: engineers often see it as bureaucracy that slows delivery. But the data is consistent: a large share of unplanned outages trace back to changes made without review, without a backout plan, or without anyone else knowing they were happening. The goal of a good process isn't to say no; it's to make sure changes are visible, reversible and appropriately approved for their risk.
Right-Sizing the Control
The mistake is treating every change the same. A routine, low-risk change shouldn't need the same scrutiny as decommissioning a firewall. Tiering changes, standard, normal, emergency, lets you move fast on the safe things and concentrate review where the risk actually is. That balance is what turns change management from a bottleneck into a safety net.
What to Insist On
A few non-negotiables keep the process light but effective:
- Every change carries a risk level and a backout plan proportionate to that risk.
- Higher-risk changes require approval, while emergency changes are still logged and reviewed after the fact.
- Changes are scheduled into agreed windows so they don't collide with each other or with the business.
- A brief post-implementation review is done every time, the fastest way to stop repeating the same mistake.
The attached template, 06: Change Management / RFC Log, is an RFC log with change type, risk level, approver, scheduled window, backout plan, status and post-review columns, with risk levels colour-coded. Route every change through it to build both an audit trail and organizational memory.
