Change management vs change enablement: change control without a CAB

Change management is the practice most likely to be inherited rather than designed. Someone read that changes need approval, created a form and a weekly meeting, and now every deploy waits for Thursday. The rename in ITIL 4 — from change management to change control, and then to change enablement — was the industry admitting that the practice had drifted into gatekeeping when the goal was always to make change both safe and fast.

The distinction is not academic. Change management as most teams practise it optimises for the number of unauthorised changes it prevents. Change enablement optimises for throughput at an acceptable failure rate. Those two goals produce completely different processes out of the same paperwork.

Every change you make is one of three kinds. A standard change is pre-authorised: low risk, well understood, follows a documented procedure — adding a user to a group, restarting a known-flaky worker, deploying through a pipeline with automated tests and a rollback. It needs no approval when it happens, because the approval was granted once, to the procedure. A normal change is assessed and scheduled: a schema migration, a firewall rule, a version upgrade with real blast radius. An emergency change is expedited because something is already broken or about to be, and its authorisation is compressed rather than skipped, with the documentation completed afterwards.

Most change-control pain comes from having only one of these categories in practice. If everything is a normal change, you have built a queue in front of routine work and taught engineers to route around it. The highest-value improvement available to almost any change practice is moving work into the standard category: write the procedure, agree the conditions, pre-authorise it, stop discussing it. A mature change practice is measured by how small its normal-change queue is, not by how thorough its reviews are.

A change advisory board is a group that assesses proposed normal changes for risk, scheduling conflicts, and readiness. It exists to solve a coordination problem: in an organisation with dozens of teams sharing infrastructure, nobody holds the full picture of what else is happening on Thursday night, and the CAB is where that picture gets assembled.

If your engineering organisation is twenty people in one Slack workspace who already know what everyone is shipping, you do not have that coordination problem, and a CAB will produce nothing but latency. Skip it. What you cannot skip is the function it performs — someone with the authority to say yes, and awareness of what else is in flight. At small scale that is a named change authority per area, usually the service owner, plus a visible calendar of anything with blast radius. One rule keeps it honest: the person authorising a change is never the only person who reviewed it, and never the person under deadline pressure to ship it.

Ask why you should record a change at all and you usually get an unconvincing compliance answer. The convincing answer is operational. The first question in almost every incident is "what changed?", and a team that can answer it in thirty seconds resolves faster than a team reconstructing the last day from six people’s memories.

That is what a change record buys. Timestamp, what changed, who authorised it, how to roll it back. If you record nothing else, record those four fields, and make sure whoever is handling an incident can see what shipped in the window before the alert fired. Change records nobody reads during an incident are a filing exercise. Change records that are the first thing opened are the cheapest diagnostic tool you own.

The failure mode is predictable. A bad change causes an outage, the response is another approval step, throughput drops, engineers batch their changes to amortise the process, batches get larger, and large batches cause worse outages — which triggers another approval step. Change control that reduces deploy frequency usually increases change failure severity, because it makes each change bigger. If your process is producing fortnightly releases of forty commits, the process is the risk.

Three rules keep it in check. Measure the practice by change failure rate and time to restore rather than by approvals granted; if those numbers are healthy, loosen it further. Require every approval step to name what it catches, and delete any step nobody can attribute a caught failure to. And invest in making changes reversible rather than in reviewing them harder — a change behind a feature flag with a tested rollback deserves less scrutiny than an irreversible migration, and the process should say so explicitly. An hour spent reviewing an irreversible migration is proportionate. An hour spent reviewing a flagged frontend change is theatre.

Change practice and the service desk meet at two points: incidents caused by changes, and requests that are really changes in disguise. FlowTux does not run a change calendar and has no change-advisory-board features, which is deliberate. What it does is the other half — tickets arrive from Slack, Teams, email, or WhatsApp, and triage is grounded in the linked codebase and previously resolved tickets, so an incident that follows a deploy tends to surface the files and prior occurrences that make "what changed?" answerable. Routine requests that qualify as standard changes, the pre-authorised and reversible ones, can run in autonomous mode per category with the full action trail on the ticket timeline, while anything riskier stays in suggest or approve mode and escalates into Jira, Linear, or GitHub with a link kept on the ticket. That boundary between modes is the standard-versus-normal change line, drawn in software.