Change management in the age of AI
The model works, and the pilot dazzled the steering committee. The go-live went smoothly, and the vendor sent a cake. Six months later, the finance team is back on the old spreadsheet, the claims assessors have quietly stopped reading the model’s recommendations, and the dashboard that was going to change everything is opened twice a week by the person who built it.
Nothing failed, and the system runs, but it is simply not used.
This is the most common way digitalisation and AI initiatives die: in the gap between deployment and adoption. Strategy and execution are so tightly interwoven that we sometimes speak of “stratcution”, and this gap is where stratcution comes apart. Change management is the discipline that bridges it. This post argues that we already know a great deal about how to do that, and that some of the sharpest recent thinking on it comes from an unexpected quarter: the engineers who measure how software gets delivered.
Understanding why teams might not adopt AI solutions: the neuro-leadership SCARF model and AI deployment
The only person who likes change
It has been said that the only person who likes change is a baby with a wet diaper. The rest of us resist it, in varying degrees, and an organisation ignores that resistance at its own peril. Force compliance with a new system and you may get compliance, but you will also stifle the innovation, resilience and agility the system was meant to unlock, and you will very likely create a passive-aggressive organisation: one that follows the new rules in the open and keeps the old habits alive under the radar.
Why is AI harder to adopt than the ERP (Enterprise Resource Planning) rollout of a decade ago? The neuro-leadership SCARF model gives a precise answer. SCARF holds that the brain runs on one organising principle: minimise threat and maximise reward, and that it applies this principle in five domains: Status (my relative importance), Certainty (my ability to predict the future), Autonomy (my sense of control), Relatedness (my sense of safety with others) and Fairness (my perception of a fair exchange).
Most organisational changes threaten one or two of these. AI threatens all five at once. Status: the expertise I built over twenty years is now a prompt. Certainty: nobody will tell me what my job looks like in eighteen months. Autonomy: the system recommends, and I am expected to follow. Relatedness: the colleague I used to ask has been replaced by a chat window. Fairness: who got the tools first, whose work is now being measured, and who decided? It is no wonder that the technically excellent deployment meets a wall of polite non-use. The wall is not irrational. It is the response to a five-fold threat.
Effective change management, in this frame, is the deliberate work of lowering threat and raising reward in each of the five domains. That is a design task, and it belongs on the project plan next to data pipelines and model validation.
A case study on change management: the importance of listening and urgency
Some years ago I facilitated change processes in two university residences whose cultures had become exclusive and resistant to transformation. The residents had every reason to see us as a punitive measure sent by management. Our approach rested on two tenets: everyone must be listened to, and without a sense of urgency, change will not be sustainable.
The technique was not rocket science. We asked each group two questions: “What would be [residence] heaven?” and “What would be [residence] hell?” Then the question that created urgency: “How do we get to hell?” The answer, in essence, was always the same: “We do nothing and change nothing, because we now see the current trajectory is leading us straight there.” And then the question that produced the first outline of a strategy: “How do we get to heaven?”
Crucially, we ran that exact process with every “tribe” in the residence separately (first-years, seniors, the house committee, alumni, management) and then found the shared mindset across all the inputs. A final meeting turned the shared mindset into a mandated change task team. The residents moved from being victims of change (“management doesn’t understand our culture”) to agents of it, and were later recognised as pioneers among their peers.
Transpose this to an AI programme, and the questions barely need changing. Ask the underwriters, the agronomists, the ground-handling supervisors, the compliance officers and the IT team, separately: what does this organisation look like in three years if the technology works and we adopt it well? What does it look like if we do nothing while our competitors do? How do we get to the second picture? The answer will come from the room, not from the consultant, and an urgency that people discover for themselves is the only kind that survives contact with Monday morning.
The two tenets map neatly onto the ADKAR model, which defines the five outcomes any change must achieve in the people affected by it: Awareness of the need for change, Desire to participate, Knowledge of how to change, Ability to implement it day to day, and Reinforcement to keep it in place. Hell creates Awareness. Heaven creates Desire. The facilitated plan transfers Knowledge. The mandated task team, mentoring and celebrating small wins, carries Ability and Reinforcement. Skip a step and the change will unwind, however good the technology.
The DORA research programme insights and how they help us understand AI change management
How the engineers solved the problem first
Here is where the unexpected quarter comes in. For over a decade, the DORA research programme (DevOps Research and Assessment, now housed at Google Cloud) has studied how organisations deliver software changes into production. Out of that research came a small set of metrics that most engineering leaders now know by heart. Change lead time: how long a change takes to go from committed to running in production. Deployment frequency: how often changes ship. Failed deployment recovery time: how quickly the team recovers when a deployment fails. Change fail rate: the share of deployments that need immediate intervention, typically a rollback or hotfix. And a more recent fifth, deployment rework rate: the share of deployments that were unplanned, made in response to an incident in production.
DORA groups the first three as throughput and the last two as instability, and its most important finding is that the two are not a trade-off. Top performers do well on all five. Teams that ship often and fast are also the teams whose changes break least, because the practice that makes speed safe (small batches, fast feedback, quick recovery) is the same practice that makes stability possible.
Now read those metrics as a change manager rather than an engineer. What DORA measures is the flow of change through a socio-technical system: how fast it moves, how often it lands, how often it gets rejected, and how quickly the system recovers when it does. That is exactly the flow an adoption programme must manage. Every one of the five has an adoption equivalent.
Change lead time becomes: how long from the decision to adopt until the new way of working is what people actually do on a Tuesday afternoon. Deployment frequency becomes: are we landing small changes often, one team and one process at a time, or betting everything on a single big-bang go-live? Change fail rate becomes: the rate of quiet rollback or how often a team, after the training and the launch, drifts back to the spreadsheet. Recovery time becomes: when adoption stalls, how quickly do we notice and intervene, rather than discovering it in the annual review? And rework rate becomes: how much of our change effort is unplanned firefighting because the first attempt was pushed rather than co-created?
Seen this way, a big-bang AI rollout is a large-batch deployment, and DORA has argued for years that large batches fail more often, they are harder to diagnose when they fail, and they are slower to recover from. ADKAR runs in short cycles, team by team, with Reinforcement measured and visible; it is small-batch delivery for people.
In AI change management, urgency is throughput; listening is stability
The correspondence goes one layer deeper. Recall the two tenets: urgency and listening. Urgency is the throughput side of change. It is what makes things move. Listening is the stability side. It is what stops what moved from being rolled back.
Organisations that push urgency without listening get exactly what DORA’s 2025 research found in AI-adopting engineering teams: throughput goes up, and instability goes up with it. More gets deployed, more of it unravels. DORA’s summary of that research is worth quoting:
“AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones”
— Google Cloud and IT Revolution (2025), DORA State of AI-assisted Software Development 2025
Replace “software development” with “organisational change”, and the sentence still holds. AI does not fix a culture that cannot absorb change; it makes that culture’s inability visible faster and at greater cost.
Organisations that listen without urgency have the opposite problem: stable, consultative, and immobile. Everyone has been heard, and nothing has moved. The DORA insight is that you do not have to choose. The practices that create urgency well (a discovered rather than imposed sense of what “hell” looks like) are the same practices that create the listening. You get both from the same room, or you get neither.
The importance of “reinforcement” in AI change management
Measure the model and the change
One warning from DORA deserves to travel with the metrics. DORA is explicit that the metrics are for improvement, not for targets, and never for comparing teams against each other. Set them as targets and Goodhart’s law takes over: people will optimise the number, and the thing the number was meant to indicate will quietly degrade. A change fail rate that has to be below five per cent will be reported as below five per cent. An adoption dashboard that determines bonuses will show adoption.
The same holds for adoption metrics. Their purpose is to give the change task team a fast, honest signal that the fourth ADKAR outcome, Reinforcement, is actually happening, and to let it intervene while intervention is still cheap. Which brings the argument back to the series on agents that preceded this post. There we argued that the movement everyone forgets in the agentic loop is reflection, and that the gate between reflecting and acting again, disposition, is where experience either changes behaviour or does not. An organisation adopting AI is running the same loop. The adoption metrics are its reflection. The change task team is its disposition gate. Without both, the organisation is a fridge with better marketing: it senses and acts, and it learns nothing.
So the two questions I asked in those residences are the two questions to put to any digitalisation or AI programme. Did we listen to everyone into existence, including the voices of dissent? And did we create the conditions for an unforced discovery of urgency? Add a third, borrowed from the engineers: do we know, this week and not next year, whether the change we deployed is the change that is actually being lived?
Conclusion
Go back to the finance team and their spreadsheet, the claims assessors who stopped reading the model, the dashboard opened twice a week by its own builder. None of that is a technology problem. The model worked. What failed was everything DORA, SCARF and ADKAR between them describe: a large, single-batch deployment that threatened status, certainty, autonomy, relatedness and fairness all at once, with no mechanism to notice the quiet reversion until someone happened to look.
The fix is not a bigger launch event or a better training manual. It is treating adoption the way the best engineering teams treat deployment: in small batches, with fast feedback, measured honestly, and corrected while correction is still cheap. It is asking people what heaven and hell look like before telling them what the roadmap says. It is building the Reinforcement step into the project plan with the same rigour as the model validation step, because a change nobody reinforces is a change that reverts on its own.
Bibliography
Google Cloud and IT Revolution (2025). DORA State of AI-assisted Software Development 2025.