Your slow departments are not all the same

It usually starts the same way. The CEO says every department should be using AI and showing the benefits by the end of the year. The transformation office turns that into targets: a number of use cases per function, a percentage of staff trained, a date for the first production deployment.

Twelve months later, the picture is nothing like uniform. One or two departments have shipped things that people actually use. A few have run pilots that never left the sandbox. Some have quietly done nothing. And the transformation office is explaining to the CEO why the same program produced such different results.

I have watched this happen more than once, and the explanation is rarely that some departments are good at change and others are bad at it. The causes are different in each case, and a program built to push everyone at the same speed cannot see the difference. Four of those causes come up again and again.

1. The work itself

The first thing that decides the pace is the nature of the work. Customer support was among the fastest movers I have seen, and it was not because the team was unusually brave. The work is high-volume, repetitive, and mostly text. Chatbots for first-level queries and AI-assisted fault analysis went from pilot to daily use quickly because the input was clean, the output was easy to judge, and the benefit showed up in metrics the team already tracked.

Functions where the work is low-volume and judgment-heavy do not get that gift. Add patchy data and vendor tooling that has not yet matured for their domain, and the same effort produces far less visible result. Nobody is doing anything wrong; the function is simply harder to move.

2. How people see the risk

The second is perception of risk. In one organization, two business groups selling into similar domains adopted AI at very different speeds. The difference was not the market and not the data. It came down to a small number of middle managers in one group who were vocal about IP exposure, and who were listened to.

The easy reading, and the one the transformation office and some of their own colleagues reached for, was that they were blockers. It was also the wrong one. Their concern was not unreasonable. Company-wide AI policies are written to cover everyone, which usually means they fit nobody’s specific situation well, and the people closest to the product often carry the risk if something leaks.

Layer on compliance obligations and the unspoken worry about what automation means for headcount, and caution becomes the default for anyone who feels the downside is larger than the upside. What looks from the outside like a slow department is often a few people making a rational call with the information they have.

3. Capacity and capability

The third is capacity, and I think it is the most underrated. The PLM team I worked alongside had no objection to AI at all. They were simply too busy. Product lifecycle work is a continuous stream of releases, changes, and approvals, and there was no slack in the week to learn a new tool, let alone figure out where it fit. Nobody on the team had the time to get good at prompting or to evaluate whether the output was trustworthy, so the question never got asked.

This is not resistance. It is a queue, and AI was at the back of it. Transformation programs tend to assume that willingness is the constraint, and they miss the departments where the constraint is hours.

4. Structure and incentives

The fourth is structure, and here the fast movers can be as instructive as the slow ones. R&D took to AI immediately. The team enjoyed experimenting and had the freedom to do it. Within months there were three or four separate log analytics tools being built to speed up debugging, none aware of the others, and most of them did not survive. Things did settle down and useful work emerged, but the early period consumed a lot of goodwill. Enthusiasm without coordination is also a form of uneven adoption; it is just the kind that shows up as noise rather than silence.

The same structural forces work in the other direction elsewhere: a central AI team naturally gravitates to functions it understands, usually technology and finance, and other departments get less support without anyone deciding that they should. And where AI gains do not appear in a department’s own KPIs, there is little reason for its leaders to prioritize the effort, however sound the business case looks from headquarters.

What helps

If the causes are different, the remedies have to be too, and the first step is to diagnose before prescribing. That means the transformation office talking to each department about its work and its worries, not only reading its own dashboard, and expecting to find more than one cause at a time; the PLM team had a capacity problem and an incentives problem together. Most programs skip this and roll out the same training, the same town hall, and the same policy to everyone, then wonder why only some departments respond.

• Where the block is perception of risk, the answer is usually a policy written for that team’s specific data and exposure, worked out with the people who raised the concern rather than worked around them.
• Where the block is capacity, nothing moves until time is protected; a champion inside the department who is given hours, not just a title, does more than any amount of central enthusiasm.
• Where the enthusiasts are running ahead, a light register of what is being tried and by whom is often enough to stop the duplication without killing the energy.
• And where the gains are invisible in a department’s own metrics, they will stay invisible until someone makes them count.

In the cases where things eventually settled, two things we put in place did most of the work. One was champions inside each department who were given time. The other was a regular forum where departments showed what they were trying, what worked, and what did not. It surfaces duplication early, gives the cautious a chance to see risk being handled rather than just discussed, and puts the successes of one team in front of the leaders of another. I will go into each of these in a follow-up post; the point here is that the fix has to match the cause.

A last thought

Not every slow department needs speeding up. Some are slow because the risk is real, the data is not ready, or the work simply does not lend itself to what AI does well today, and pushing them harder only produces pilots that go nowhere.

The job of a transformation lead is not to get everyone moving at the same pace. It is to know why each department is where it is, and to be honest about which gaps are worth closing.

Which gaps are worth closing comes down to how much value AI can actually add to that department’s work today.

If you have seen this play out differently, or the same way, I would like to hear about it. Write to me or join the discussion on LinkedIn.

Originally published on LinkedIn on 6 September 2026.