I met a capable technologist at a prospective client recently. He had spent six months pushing Ai tools into the business and genuinely changing how people worked day to day. He knew his way around the models. What he had never done was any change management, and he told me plainly that he does not get involved with that side of things. The senior leadership team were, by the time I arrived, thoroughly disillusioned with Ai.
The Ai he brought in was not the problem. He is bright and the tools were fine. The problem was everything around the Ai: no one had brought the people who do the work into the change, so the people quietly rejected it. This is the pattern I see most often, and it has almost nothing to do with technology.
The technology question is usually the easy one
When an Ai project fails, the post mortem tends to blame the tool, the data, or the vendor. The real fault line runs somewhere else. The technical question, can the model do this, is usually solvable. The human question, do the people who now have to work alongside this feel they were taken seriously in how it was introduced, is the one that decides whether the project delivers a return or slowly disappears.
I spent fifteen years in regulated engineering before I did any of this, and the lesson held there too. A technically flawless rollout still fails at month six if the people living with it were not part of designing it. Nobody likes change that is done to them. Everybody tolerates change they helped shape. That difference is not soft. It is the difference between a system that gets used and one that gets worked around.
Why good rollouts still fall over
Change fails for reasons that are well understood and still routinely ignored. John Kotter's work on organisational change lists eight steps, and the ones businesses skip are always the human ones: building a real sense of why this matters, finding champions inside the team, communicating the point clearly, and generating a few early wins that people can see for themselves.
What happens instead is that the technology gets bolted on and the people are expected to catch up. There is no time set aside to explain why, no one respected on the shop floor asked to help shape it, and no visible early win to build any belief. Six months in, the tool is technically live and practically ignored. Everyone has found a way back to the old method, and the business has learned to distrust Ai for reasons that were never about Ai.
What good looks like when people are in the room
The businesses that make Ai stick treat the people as the project, not an afterthought to it.
They bring the people who actually do the job into the design early, because those are the people who understand the real pain points and the awkward exceptions that never appear in a process diagram. They pick a respected person inside the team to champion it, rather than imposing it from the top. They pilot with a small group before any wider rollout, prove it works, and let that group tell their colleagues it is worth having. And they decide up front how they will know the change has actually embedded, rather than declaring success on the day it goes live.
There is a better argument for Ai underneath all of this, and it is one people respond to. Used well, Ai takes the mundane, repetitive work off a person's desk: the re-keying, the document handling, the endless small queries. That is not a threat to the job. It is what frees someone up to do the part of the job a machine cannot, which is usually the human contact with a customer or colleague. Richard Branson put the chain simply: look after your staff, they look after your customers, and your customers look after your profits. Ai introduced with that in mind lands very differently to Ai introduced as a cost-cutting exercise.
How to lead the change, not just install the tool
If you are about to put Ai into your business, treat the human side as the real work.
- Name an owner. Not a committee. One person accountable for the change landing, with the authority to make it happen.
- Bring the people who do the job into the design before you build anything. They will tell you where the process actually breaks, and they will be far more willing to adopt something they helped shape.
- Find a champion inside the team. Someone respected by their peers, not just senior. Their endorsement is worth more than any leadership memo.
- Pilot before you roll out. A small group, clear success criteria, and a real chance to fix what does not work before the whole business is watching.
- Decide up front how you will measure adoption. If you cannot say how you will know the change has embedded, you are not ready to start.
The costume it wears
Ai adoption looks like a technology project and behaves like a people project. The model will usually do what you need. Whether your team lets it is a different question, and it is the one that decides the outcome. Get the people right and the technology becomes almost incidental. Get the people wrong and no amount of model quality will save you.
If your last attempt at Ai stalled and you are not sure why, it is worth looking at how the change was led before you blame the tool.