Leadership Alignment: Why Your Exec Team is Blocking AI ROI

Why do exec teams block AI adoption?

Almost never on purpose, and almost never with a clear no. An exec team blocks AI adoption by agreeing to it in the room, then quietly failing to give it the calendar space, the authority or the admission of past mistakes it actually needs in order to work.

In twenty years running transformation programmes inside some of the UK's largest organisations, I can count on one hand the number of times a board or exec team voted against a change programme outright. That was never the hard part. Nobody stands up in a steering committee and argues against the future. What I have seen, over and over, is the version that looks like agreement and behaves like resistance: the budget gets approved, the working group gets its charter, everyone says the right things, and six months later almost nothing in the business has actually changed, least of all the return anyone was promised at the outset.

That gap exists because the real cost of AI adoption is rarely the technology, and it is almost never named in the room where it should be. For any individual exec, agreeing to an AI programme quietly implies at least one of three things: that a process they built or championed years ago is now part of the problem, that their team's workload is about to be rebalanced in ways they have not agreed to yet, or that there is a skills gap in their own function that is easier left undiscussed than surfaced in front of their peers. None of that gets said out loud. It does not need to be said for it to work. It only needs to sit there, unspoken, until something more familiar and more urgent turns up to compete for the same three hours in the diary. It always does.

You do not need nine layers of management or a stock market listing for this pattern to show up. If you are running a business with a hundred and fifty people and a leadership team of six or seven, the same dynamic plays out at your Monday morning meeting. The scale is smaller. The psychology is identical.

What does an exec's diary reveal that a steering committee vote didn't?

The vote tells you what a leader is willing to say in front of their peers. The diary tells you what they are actually willing to give up for it, and those are frequently two different answers.

I have sat across the table from plenty of executives who were entirely sincere in the steering committee. They meant it when they said the AI programme mattered. Then the working sessions got scheduled, and their team's calendar never actually cleared to make room for them. Not through any single decision. Through a hundred small ones: the workshop that moved because a client needed something that week, the review that got pushed because quarter end came first, the two people who were meant to be seconded onto the project but somehow never quite came off their existing workload. Each individual deferral was reasonable. The pattern was not.

Nobody had to actively cancel the programme. It simply lost, quietly and repeatedly, every time it competed with something more familiar. And it always competed with something more familiar, because the AI work was new and uncomfortable and the client fire was neither. If deprioritising the change never costs a leader anything specific and visible, and running the department the old way costs them nothing either, there is no real pressure pushing the harder choice to the top of the list. The diary is the only honest scorecard in the building. Read it before you read the minutes.

Why do function heads insist their department is different?

Because it is a respectable way to avoid admitting the process needs to change, and because it is often partly true, which is exactly what makes it so effective.

Almost every function has some genuine nuance: a regulatory constraint, a client relationship that depends on one particular person's judgement, a technical dependency that a generic rollout genuinely would not handle well. I am not suggesting those objections are invented. What I have watched happen, in function after function, across more organisations than would be useful to describe individually, is that a genuine nuance gets used to argue for something much bigger than the nuance justifies: a bespoke exception to the change programme, rather than a version of it properly adapted to the real constraint. The distinction matters. One is a design problem to solve together. The other is a permanent exit.

The exception sticks because nobody schedules the follow-up. It gets granted in a moment of goodwill, on the reasonable-sounding basis that this function will rejoin the programme once its special circumstances are worked through, and then no one ever comes back to work through them. Six months later, the exception has quietly become that department's permanent operating model, unexamined, because reopening it would mean reopening an argument everyone would rather leave settled.

It is worth noticing which functions tend to claim this exception most confidently. In my experience it is disproportionately the ones where the current process carries the clearest fingerprints of the leader now being asked to change it. Accepting that the process needs to move on is close to accepting that a decision they made, and were probably praised for at the time, has a shelf life. That is a genuinely uncomfortable thing to sit with in front of colleagues, and "our department is different" is a far easier sentence to say out loud than "the thing I built five years ago now needs to change."

Why doesn't a group endorsement create real commitment?

Because a room full of nodding heads lets every individual leader shelter inside the collective yes, without any one of them ever having to say what they personally will do differently.

Most exec teams run AI adoption the same way they run most change initiatives: an all-hands presentation, a general statement of support, a shared sense that the direction is right. That kind of endorsement is easy to get precisely because it asks so little of any one person. Everyone can agree that the business should become more capable with AI in the abstract, in much the same way everyone can agree that communication should improve or that silos should break down. Nobody has committed to anything specific enough to be held to it afterwards, and if nothing changes in three months, there is no individual conversation to be had, because the decision belonged to the room, not to anyone in it.

Collective sign-off is the right tool for plenty of decisions. It is close to the wrong tool for this one. What a collective yes conceals, deliberately or not, is that each function is going to have to change in a different way, at a different cost, carried by a different person. Treating that as one shared decision is precisely what lets every individual leader avoid ever being asked, directly, what their function specifically has to stop doing.

What should you actually ask each executive, one to one?

Not whether they support the programme. Ask what would have to stop in their function for it to work, whose role changes as a result, and which part of that they are personally uneasy about.

This conversation does not happen in the steering committee, and it should not. It happens in a room with one leader at a time, ideally before the wider programme is announced, and it is built from specific questions rather than general ones. What, in your function, are you going to have to stop doing or stop protecting? Whose workload changes, and have you actually agreed that with them yet, or only assumed it? What does this require that your team, or you personally, do not currently know how to do? What is the one part of this you are hoping nobody asks you about directly?

That last question is usually the one that matters most, and it is rarely comfortable to ask a peer or a direct report. It should not be comfortable. The discomfort is not a sign the conversation is going badly. It is the conversation finally addressing the actual obstacle, rather than talking around it in front of an audience. An executive who can answer those four questions specifically has told you more about whether their function will actually change than an hour of steering committee discussion ever will.

Who should be accountable for AI adoption in each function?

One named person per function, not a steering committee. Committees are good for visibility and for making sure information reaches the right people. They are a poor mechanism for forcing a specific, personally uncomfortable change, because responsibility spread across a group is responsibility no one individually carries.

Every function going through this needs one person whose name is on the outcome, and whose regular performance conversation includes a specific, checkable line: did the thing we agreed actually happen, yes or no. Not "is the programme broadly on track." Whether the process this function owns has genuinely changed, on the timeline that was agreed, in the way that was agreed. A steering committee can still exist above that layer, tracking progress and clearing obstacles across functions. It should not be where the accountability for any single function's change actually sits, because that is precisely where it currently goes to disappear.

None of this makes the process fast, and I would be doing you no favours pretending otherwise. Naming the specific ask to each leader, and giving one person a job they can actually be judged against, takes longer than a single steering committee presentation, and it is considerably more uncomfortable for everyone involved, including whoever is running the room. But the alternative is the version most businesses are already living: broad agreement at the top, and almost nothing different happening underneath it. The point of this work was never to do the same things with fewer people. It is to build a business capable of five to ten times what it does today, with the same people you already have. That only happens function by function, conversation by conversation, and it starts with asking each of your leaders a question most of them have never actually been asked.