Making AI stick: Change management as a first-class discipline in automation programmes

I want to start with a number that I find both striking and entirely unsurprising: the majority of AI automation programmes that underperform their projected value do so not because the technology fails, but because adoption falls short of expectations. The agents are running and the processes are automated, but the people who are supposed to be working with the system are partially or entirely working around it. They’re reverting to manual processes, duplicating work, or simply not using the capability that’s been built. 

This is the pattern that change management is supposed to prevent, and in the programmes I have been involved in, the difference between the ones that achieve high adoption and the ones that struggle is not luck, and it is not technology. It is whether change management was treated as a first-class discipline with the same rigor, the same resourcing, and the same leadership attention as the technical delivery, or as an afterthought. 

Why 'communications' is not change management 

The change management approach in many AI programmes follows a predictable sequence. A launch communication is prepared, typically signed by a senior leader, a town hall is held, FAQs are published on the intranet, and A training session is scheduled for the affected teams. The change is declared managed. 

None of these activities are wrong as they are all necessary, but they share a common limitation: they are one-directional. They inform people of what is happening, but they do not create the conditions in which people can shape what is happening or genuinely engage with the implications for their work. 

Real change management is a two-way process. It creates structured opportunities for the people whose work is changing to contribute their knowledge, raise their concerns, and influence the design. It has mechanisms for capturing and acting on feedback that are visible enough to be trusted. This continues after go-live through the first operational period, through the first significant process update, and through the moments when things don't go exactly as planned. 

Process discovery as a change management tool 

One of the most effective change management practices I have seen in automation programmes is also one of the most straightforward: genuine process discovery workshops with the teams whose work will be automated. 

These workshops are not primarily a technical exercise although they do produce valuable information about process detail, edge cases, and exception handling that the technical team often lacks. Their primary function is to establish the relationship between the automation programme and the people it will affect. They communicate, through the act of asking rather than telling, that the team's knowledge matters and that their input will shape the outcome. 

The contrast with the announcement-led approach is stark. In the programmes where discovery workshops have been run well, I have consistently seen teams move from apprehension to engagement and this is not because the automation is less disruptive, but because they have had a hand in designing how the disruption is managed. The automation is no longer something being done to them, it is something they have helped to build. 

The escalation channel problem 

One of the most common change management failures is the absence of a credible escalation channel for operational concerns. There is almost always a nominal mechanism whether it’s a project email address, a 'feedback' section in the training materials, or a named project manager. What is far less common is a mechanism that the people on the ground actually trust to produce a response. 

The test of a credible escalation channel is not its existence but its track record. Has a concern raised through this channel previously resulted in a visible change? If the answer is yes, people will use it. If the answer is no, or if people don't know, they will not. 

This matters because the people closest to the process are almost always the first to notice when something in the automation is not working as intended. They are the early warning system for operational problems that, if left unaddressed, will compound. If they do not trust the escalation channel, those problems do not get escalated, they get worked around. The manual override rates climb, the agent's effective scope narrows, the programme delivers less value than it should, and nobody quite knows why. 

The role of senior leadership in change 

Executive sponsorship is one of the most discussed and most frequently misunderstood concepts in change management and it is not the same as executive approval. Approval is a decision made before the programme starts. Sponsorship is an ongoing commitment of attention and presence throughout the programme, including at the moments when things are difficult. 

The moments that matter most are not the launch event or the go-live milestone, they are the six-month operational review, when the initial excitement has faded and the real operational challenges are becoming clear. They are the first significant process update when the automation needs to change and the organisation needs to adapt. They are the moments when a team member raises a concern that turns out to be valid, and senior leadership demonstrates that the concern was worth raising. 

People take their signals about what matters from where senior leaders put their attention. An automation programme that receives prominent executive attention at launch and then disappears from the leadership agenda sends a clear signal: this was a project, and the project is done. An ongoing, visible leadership commitment to the programme sends the opposite signal, and that signal is one of the most powerful drivers of sustained adoption. 

Building the capability, not just delivering the project 

The ultimate measure of effective change management in an automation programme is not adoption at go-live, it is whether the organisation has developed the capability to work effectively with AI agents over the long term. This pertains to managing them, updating them, escalating concerns about them, and integrating new agents into the workforce as the programme expands. 

This capability does not develop automatically as it requires deliberate investment in training, in clear role design, in communication channels that remain open after the project team has moved on. The organisations that invest in this from the outset rather than assuming that adoption will consolidate over time without further intervention are the ones whose programmes continue to scale. 

The change management discipline that produces this outcome is not complex. It is consistent, visible, and honest. It treats the people whose work is changing as collaborators rather than recipients and it maintains the same standard of rigor and leadership attention after go-live as before it. This is not a guarantee of success, but the absence of it is a near-guarantee of the underperformance pattern described at the start of this piece.