Your AI strategy is an incentive problem

The technical objections to enterprise AI are mostly solvable. Data quality, integration, model choice, cost — these are engineering problems with engineering answers, and the answers keep getting better.

The reason programmes stall is almost never on that list.

Silos are a measurement artefact

The standard explanation for organisational silos is structural: different departments, different reporting lines, different tools. That explanation is comfortable and mostly wrong, because you can merge two departments and watch the silo survive the reorganisation intact.

Silos persist because incentives are misaligned. If one function is measured on cost per contact and another on resolution quality, they will make opposite decisions about the same customer, forever, and both will be behaving correctly. An AI system that spans them does not resolve the conflict — it surfaces it, faster and more visibly, which is why cross-functional AI initiatives so often produce a political problem where a technical one was expected.

This is the most useful diagnostic question I know for an AI opportunity: which two teams here are measured on things that contradict each other? The answer predicts where the initiative will stall far better than any technical assessment. And it is answerable in the first week, by asking people what they are judged on rather than what they do.

Fear is a design input, not a communications problem

The second thing that stalls adoption is that people are asked to be honest about their weaknesses in front of a system that might replace them.

Effective AI adoption requires exactly that honesty. Someone has to say: this part of my job is repetitive and I am not adding much, this decision I make from a rule I could write down, this report takes me four hours and nobody reads two of them. That information is the raw material of a good use case. It is also, in an organisation that has announced efficiency targets, a confession.

You cannot fix this with a communications campaign, and treating it as a change-management afterthought is how programmes get technically correct systems that nobody feeds real problems into. What changes it is structural: if the plan is to redesign roles rather than remove them, the incentive to hide inefficiency disappears, and the same people who would have quietly obstructed become the best source of use cases in the building. If the plan really is headcount reduction, the honest move is to say so — but then do not expect candour about where the work is soft.

There is also a competence dimension, and it is underrated. The people who get the most out of these systems are not the most technical; they are the ones who have developed a feel for when to trust the output and when to step in. That intuition is only learned by using the thing on real work, over time, with permission to get it wrong. Which means education is not a training module. It is sustained exposure with a safety net.

The manager’s job changes shape

There is a real skill shift underneath all of this, and it is not “learn to prompt”.

Managing work done by people means defining tasks: run this report, review this file, call this customer. Managing work done partly by systems means defining objectives and the conditions around them — what outcome, judged by what success criteria, within what constraints, escalating when what happens, reviewed how often.

That is a different competence, and it is closer to what good delivery managers already do than to anything technical. It also explains why AI capability inside an organisation cannot be concentrated in one person or one central team. A single appointed leader cannot scale that judgement across a company; what they can do is distribute fluency and ownership so that the people who understand their own domain problems are equipped to spot the opportunities in them. A central hub keeps the platform, the standards and the evaluation discipline coherent. The spokes know where the work actually hurts.

The mechanism most often missing between them is the one that takes something proven in one team and spreads it. A pilot that succeeds locally has no natural path outward — the team that built it has no incentive to generalise it and no capacity to support it elsewhere. Without someone explicitly responsible for re-applying what worked and turning the repeated parts into shared infrastructure, organisations rebuild the same successful pilot three times in three departments and count it as three projects.

What I would ask in the first month

Not “what is your data maturity”. These:

• What are these two teams each measured on, and where do those measures conflict?
• Who in this process knows it is inefficient, and what would it cost them to say so?
• If this pilot works, whose job is it to make it work somewhere else?
• Which decisions here are reversible, and who currently has the authority to make them?
• What happens to the people whose work this changes — and has anyone told them?

None of those questions are about technology, and all of them determine whether the technology survives contact with the organisation.