The Friday 5 p.m. Change Committee

# ITIL

# AI

# Service Management

From theatre to real governance

October 8, 2026

Luc Davalle

The Friday 5 p.m. Change Committee

From theatre to real governance

Every week, eight tired people rubber-stamp changes no one fully understands. Here is why our change ritual drifts into theatre — and how, in the right order, data and eventually AI could make it matter again.

Friday. Five o’clock. A meeting room that is a little too warm, a cold coffee forgotten on the table, a projector showing a table of twenty-three lines — and eight people who, deep down, want just one thing: to go home.

Notifications pile up on the shared screen. Someone joined “just to listen.” Another turned their camera off twenty minutes ago. Welcome to the change committee — the CAB, the Change Advisory Board — the weekly ritual where we decide what we are allowed to modify in production. On paper, it is serious business. In real life, it is often theatre.

And like any good theatre, it has its cast. There is the one who presents a request by reciting a script he does not quite understand himself: “It’s a standard change, low risk, nothing to report.” There is the resident sceptic, who asks the one question that stings: “And if it breaks, how do we roll back?” A silence — the kind where everyone studies their screen very intently. And then someone delivers the magic line that ends every debate: “We’ll deal with it when we get there.”

We’ll deal with it when we get there. There, in a single sentence, is the whole strategy.

I want to do two things here. First, an autopsy: why this ritual exists, and why it so often ends up running on empty. Then — and this is where it gets interesting — a reconstruction. Because the very same committee could become, within a few years, something almost elegant: with data, with method, and yes, with a hand from artificial intelligence. But in the right order. The right order, here, makes all the difference.

✦ ✦ ✦

What change management is actually for

Let us set the record straight, because change management carries a bad reputation: the brake, the paperwork, the reflexive “no.” It should be none of that.

Change management answers one simple question: before we touch what works, have we actually thought about it? That is all. It is a decompression chamber between “I want to deploy” and “I deploy.”

Why the chamber? Because in production, the vast majority of serious incidents do not come from some exotic cyberattack on the other side of the world. They come from a change. Ours. An overconfident update, a parameter changed in a hurry, a certificate no one renewed, a nightly batch that spills into the day. Nothing spectacular — just a good idea on a Friday evening that wakes everyone up on Saturday morning.

Picture it as surgery on a patient who is very much alive and still receiving visitors. You do not operate without knowing what you are cutting, without anaesthetic, and above all without knowing how to close up if it goes wrong. Good change management does exactly that: it answers three questions, and only three. What are we changing? What is the risk? And how do we go back if it goes wrong? Three questions — not thirty-three checkboxes. Remember that number, because we will come back to it: the committee’s value lives in those three questions, not in the thickness of the form.

A word on where this ritual comes from. The CAB was born in an era when we deployed big and rarely — one large release a quarter, prepared over weeks, the kind of event where you gathered everyone because the stakes were enormous and rolling back was a nightmare. In that world, the Friday meeting made sense. The trouble is that the world changed — and the meeting stayed.

How it turns into theatre

So why does a sound principle — think before you act — curdle into Friday-evening comedy? Because we confused two things: control and ritual.

Control means asking the right questions at the right moment. Ritual means repeating the same gestures because we always have, even when they no longer protect anything. And little by little, insidiously, the CAB slides from the first to the second.

In practice: we approve a change because it has always been approved. We reject another because it is late and we are out of energy to argue. We validate requests that, honestly, no one in the room truly understands — but everyone nods, because no one wants to be the person slowing the whole room down.

The sociologist Michel Crozier described this beautifully. In any organisation, he argued, everyone ends up playing a role that protects them individually — even when that role no longer serves the collective. That is exactly what happens at the CAB. Its real function has drifted. It is no longer “protect production.” It has quietly become “protect the people in the room.” If it breaks, at least there was a meeting. At least a box was ticked. At least it was not my fault.

And there we reach the heart of it. A committee whose hidden function becomes covering itself no longer produces safety. It produces paper. Defensive traceability. A signature at the bottom of a document so that, if something goes wrong, responsibility is shared — therefore diluted, therefore no one’s.

The worst part, the real alarm bell, is the perverse effect. While the committee religiously combs through the most harmless release, the genuinely risky changes go elsewhere. In an emergency. Monday morning. As a “hotfix.” Outside the committee, with no one to ask the rollback question. In other words: the ritual bears down on low risk and lets high risk slip through — the exact opposite of its job.

And let me be clear: this is nobody’s fault in particular. Everyone around that table is perfectly rational. The presenter who recites, the sceptic who doubts, the manager who watches the clock — each plays their part sensibly. It is the sum of these individual good senses that produces a collectively absurd result. That, too, is organisational sociology. And it means one thing that matters: you do not fix this by blaming people. You fix it by changing the system that makes them play.

A process that no longer protects anyone ends up protecting only itself.

So much for the autopsy. Now the good news: we can rebuild. And it happens in three movements.

Rebuilding, part one: the foundations to lay today

Here is something that may surprise you: we are not going to talk about artificial intelligence. Not yet. Because a lot of people want to skip this step — “AI will score our changes, AI will decide for us!” Maybe. One day. But if you put AI before the foundations, all you get is a bad decision, faster, wrapped in a veneer of algorithm that makes it feel beyond challenge. The worst of both worlds.

Before dreaming of the machine, you have to build the memory it will learn from. And that memory is built today, with gestures that have nothing magical about them. Just discipline. Five, in particular.

Record every change — properly, completely, honestly. Type, application, team, deployment window, the risk estimated beforehand. Every release is a small scientific experiment: if you do not record the conditions, you will never learn from it. An untracked change is a lesson lost forever.

Link every incident to its change. This is the most precious link, and the most neglected. In most organisations, incidents live on one side, changes on the other, and the two never speak. As a result, we cannot say which release caused which incident — yet that causality, this change caused this damage, is the raw material of all future learning.

Review after the fact — the post-implementation review, especially on failures, and above all without a hunt for the guilty. Record what failed, not who failed. Because the day declaring a failure becomes dangerous for the person declaring it, failures vanish from the radar without vanishing from reality. They hide. And data that hides is a lesson you can never learn.

Keep the map current — which applications are critical, and how they depend on one another. A living map, not a graveyard of spreadsheets last updated three years ago. Without that map, you simply cannot assess a change’s impact.

Measure two simple numbers — the share of releases that succeed, and the share of changes that cause an incident. Two numbers. That is your baseline, your point zero. Without it, you will never know whether you are improving or merely telling yourself stories.

None of this is glamorous. No one gives an inspiring talk on “filling in your change form properly.” And yet that is where everything is decided. Because an AI, however powerful, does not learn in a vacuum. It learns from your history. And if that history is false, absent or embellished, it will learn your lies and repeat them with the serene confidence of a machine.

Clean data today is tomorrow’s intelligence. You don’t build a brain on amnesia.

Rebuilding, part two: a risk score for releases, assisted by AI

Now we can dream a little. A warning first: what follows is a projection — a vision of what becomes possible once the foundations are laid, not something you download on Monday morning.

Imagine every release arriving at the committee already carrying a risk score, computed automatically before the meeting even starts. That score feeds on three families of signals.

The history of the estate’s releases. This type of change, on this application, by this team, at this time of year: how often did it go wrong in the past? That is the kind of correlation the human eye misses. You remember the last memorable incident; the machine remembers the previous ten thousand releases, and notices that — say — deploying this component on a Thursday, after a database upgrade, ends in an incident three times as often. No human works that out in their head. An AI does.

The application’s resilience to release. Can it absorb a failed deployment? Does it have automated rollback, redundancy, a battery of tests, a progressive rollout — on a fraction of users first, rather than all at once? Is it observable — will we know immediately if it is in trouble? An application that can roll back in thirty seconds simply does not carry the same risk as an ageing monolith you only restart with crossed fingers.

The possible impact — technical and business. On the technical side: dependencies, the domino effect, the true blast radius. On the business side — the dimension technical teams almost always underestimate: how many users, how critical the process, what regulatory stakes, and timing. Deploying the day before an accounting close, a payroll run, or a regulatory deadline is not the same risk as a quiet Tuesday in a slow month. The same technical change can be harmless one day and explosive the next. Only the business context tells you which.

The AI takes these three families, correlates them, learns continuously from every new release — and produces two things: a score, and above all an explanation. Because a score without an explanation is worthless in our world. You do not tell a regulator “the algorithm said green, so we went ahead.” The score has to be explainable: “high risk, and here are the three factors that explain it.”

An example. First release: a minor fix, on a resilient application, of a type deployed two hundred times without incident, on a Tuesday, outside any sensitive window. The score says green — known profile, low risk, pre-approved automatically. It never even reaches the committee. Second release: a change to a central component, on which twenty applications depend, carried by a team still discovering the scope, the day before a regulatory deadline. The score says red — and it says why: strong dependencies, loaded history, critical timing. Now the committee wakes up, and it has a real reason to.

See what changes? The committee no longer reads twenty-three undifferentiated lines. It handles three — the ones that deserve a genuine expert conversation. We give humans back their brainpower for exactly where it adds value: judgement on the hard cases. The machine sorts the routine; the human arbitrates what matters.

It’s not AI against humans. It’s AI giving humans back their proper place.

The conditions that make it work

At this point you might think: fine, we buy the tool, and we are done. No — above all, no. Because a poorly grounded score is not a decision tool; it is an automatic excuse generator. For it to be trustworthy, several conditions have to come together. Some you will recognise.

Reliable, structured data. Straight back to the foundations: a current map, changes recorded honestly. The old computing principle has not aged a day — garbage in, garbage out. No foundations, no AI. It is that simple.

Traceability from change to incident. Without that link, the model is blind to the essential: it cannot learn what actually broke yesterday.

A shared taxonomy of criticality. “Critical” must mean the same thing to everyone — from the engineer to the business owner. If every team keeps its own scale, the score mixes apples and oranges and becomes uninterpretable.

A blameless culture. I keep returning to it because it is vital. If failure is punished, it stops being declared — and if it is not declared, the data corrupts at the source, upstream of any algorithm. No AI on earth recovers a history in which people learned to hide their mistakes. The quality of your score depends, literally, on the psychological safety of your teams.

A human in the loop. The AI proposes; the human decides on anything sensitive. You never delegate responsibility to a score. In a regulated environment especially, a decision commits a person, not a model. The score informs; it does not sign.

Governance of the model itself. Who audits it? What happens the day it is wrong? How do we detect that it is drifting, or that it has learned a bias — penalising a team, say, simply because it reported its incidents more honestly than the others? A score has to be watched, challenged, corrected. It is not an oracle; it is a tool under responsibility.

Time and managerial backing. None of this can be decreed. It is built over months, with management that protects the effort and accepts that the first year mainly serves to collect clean data. It is an investment in patience — and anyone looking for results within a quarter will be disappointed, and will drift back to the Friday theatre.

The destination: CI/CD, DevOps, and the rare incident

Let us zoom out, because all of this leads somewhere precise. That Friday committee is an inheritance — from an era when we deployed big, rarely, and with fingers crossed.

The direction the whole industry is heading is the opposite: deploy small, often, and reversibly. That is the logic of continuous integration and delivery — CI/CD. Automated tests running on every change, tooled delivery pipelines, well-known repetitive changes pre-approved once and for all so they never go through a human meeting again.

And the consequence is fundamental: when you deploy in small, reversible steps, each change carries far less risk. Because it is small — easy to understand. And because it is reversible — if something goes wrong, you undo it and breathe. You have defused the bomb before even handling it.

In that world, the CAB does not disappear. It changes nature. It moves from gatekeeper-and-rubber-stamp to a light risk-governance function: it sets the rules of the game, watches that the score stays reliable, and arbitrates the few genuinely sensitive cases the machine escalates. The routine flows on its own; the human concentrates on the exception. That is a promotion, not a disappearance.

And this is where the DevOps culture closes the loop, in the finest way. When deployments become safe, small and frequent, something remarkable happens: incidents become rare. Genuinely rare. And the day one occurs — because one always does — it is no longer a catastrophe or a witch-hunt. It is a goldmine. We analyse it calmly, blamelessly, with a single question: what does this teach us, and how do we make sure it can never recur the same way? And what we learn, we feed back — into the tests, into the guardrails, and, the loop complete, into the score itself, which grows a little smarter each time. Every incident makes the system sturdier. Error is no longer paid; it is invested.

How do we know we are making progress? With a few simple markers — four in particular: how often we deploy, how long an idea takes to reach production, what share of our changes fail, and how quickly we recover when an incident hits. Those four numbers tell the real health of your production better than any committee.

And you get a virtuous circle, the exact opposite of the Friday theatre: fewer incidents, so more trust; more trust, so more automation; more automation, so smaller and safer deployments; and therefore fewer incidents still. The wheel turns the right way. It reinforces itself.

The bottom line

Let us gather the thread. The change committee is not your enemy: it is your seatbelt. But a seatbelt you buckle out of habit, without ever checking it is anchored to the seat, protects no one. It reassures. And reassuring is not protecting.

The real work, then, is not to abolish the committee. Nor to hand it to an AI overnight, skipping the steps. The real work is to lay, starting today, the discipline that makes everything else possible. Record. Link. Learn. Blamelessly, without exception, patiently.

Because at the end of that road lies a place where the machine assesses the routine, the human arbitrates what matters, and the incident — now rare — serves to improve rather than to justify. A place where Friday, 5 p.m. becomes just Friday, 5 p.m. Where you go home with a clear mind, because safety no longer lives in the meeting: it lives in the system.

So next Friday, at five, before you approve anything, ask yourself one question. This committee, today — is it deciding, or reassuring? And if the answer stings a little, that, believe me, is the best possible place to start.

Enjoyed this post? Join the conversation by leaving a comment or sharing your thoughts below, we’d love to hear your experiences and perspectives. Don’t forget to explore our upcoming events for more opportunities to learn and connect, and visit the forum to continue the discussion.

Where conversation, connection, and real-world practices come together.