Almost nobody kills an AI rollout outright. They just don't schedule the review, don't mention it to their team, and keep using the old template.
Getting an AI tool approved and getting it used are different projects with different obstacles. The budget conversation happens once and it’s the easy one. What actually costs you months is the security review nobody scheduled, the manager who never says no but keeps the old process running, and the team who heard about it from a group email. Each of those groups is withholding for a different and mostly reasonable reason. This piece maps who to engage and when, what each group specifically needs answered, a script for the manager conversation that’s usually skipped, and how to read resistance as information rather than opposition.
A marketing ops lead I’d describe as unusually well organised got budget approval for an AI tool in a single meeting. Twenty minutes, one slide, done. She then spent eleven weeks waiting.
Not on a rejection. On a security review that had never been booked, because the person who needed to run it first heard about the tool from a vendor’s marketing email that landed in his inbox before anyone internally mentioned it to him. By the time she reached him, he wasn’t evaluating a request from a colleague. He was evaluating something that had been decided without him.
That’s the shape of most stalled rollouts, and it isn’t a communication failure in the way the phrase usually gets used. Nobody misunderstood anything. The right conversation just never happened with the right person, in the right order, and once it’s out of order you’re not asking for input any more, you’re asking for ratification.
Every group has a different reason to say no. Find out which one you’re getting.
What makes this hard is that hardly anyone says no. Refusal is visible and costs the refuser something. What you get instead is a review that stays unscheduled, a manager who agrees in the meeting and never mentions it again, a team that tries it for a fortnight. All of that is deniable, none of it is a decision you can respond to, and it adds up to the same outcome.
There’s a figure in the 2026 Microsoft Work Trend Index that reframed this for me. Only about a quarter of the AI users surveyed, 26%, say their leadership is clearly and consistently aligned on AI.[1] If you’re running a rollout, that’s the room you’re walking into. Three quarters of the people you’re asking to change how they work can’t currently see a direction to follow.
Which means the first job isn’t persuasion. It’s supplying the clarity that’s missing, group by group, in the terms each group actually cares about. Four groups, four conversations, and they’re not interchangeable.
If you’re earlier than this and still deciding what to roll out at all, the adoption checklist covers the planning sequence. This piece assumes you know what you want and now have to get everybody else there.
Four groups. The order isn’t arbitrary, and the most common sequencing mistake is doing leadership first because they’re the ones with the budget.
Do a quiet version of the IT and security conversation before the budget conversation. Not the approval, just the sounding-out. Otherwise you get funding for something that turns out to be unapprovable, and now you’re the person who wasted a budget line.
| Group | When | What they actually care about | How they block it if you skip them |
|---|---|---|---|
| IT and security (informal first pass) | Before anyone signs anything | Where the data goes, who can reach what, whether this creates a new thing to monitor | An open-ended review with no end date. Perfectly reasonable, and it costs you a quarter. |
| Senior leadership (budget holders) | Once you know it’s approvable | What decision they’re being asked to make, what it costs, what changes if it works, what happens if it doesn’t | Approves it without owning it. You get money and no air cover, which is the harder version. |
| Middle managers (whose teams change) | Before the announcement, individually | Whether their numbers hold while their team learns, and whether they’ll look uninformed in front of their own people | Never objects. Keeps the old process running in parallel. This is the one that quietly wins. |
| The people using it | At announcement, with examples ready | Whether this is aimed at replacing them, and whether it’s relevant to what they actually do on a Tuesday | Tries it once, doesn’t see their own work in it, concludes it isn’t for them. Very hard to reverse. |
The four groups, sequenced. Built from Future Factors’ work running adoption programmes with client teams, not from a published change-management model.
The row people underestimate is the third one. Middle managers get treated as a communication channel, something you send a briefing pack to so they can pass it down. They’re not a channel. They’re the group with the most to lose in the short term and the least visible way of expressing it.
One practical note on sequencing: individually, not in a group. A room full of managers being told about a change produces public agreement and private reservations, and the private reservations are the ones that determine what happens on Monday.
The instinct is to bring a demo. Resist it. A demo shows what the tool can do, which is a question they didn’t ask and can’t evaluate.
What a budget holder needs is a decision with edges on it. Four sentences, in this order, and you should be able to say them without slides.
The last one matters more than it looks. A proposal with no failure condition reads as advocacy, and experienced executives discount advocacy automatically. A proposal that names what would make you stop reads as a plan.
There’s a second thing to ask for, and it’s the one people forget because it isn’t money. Ask leadership to say something specific and public, once, at a moment their managers will notice. Not a paragraph in a newsletter. A named commitment in a meeting where the managers are in the room.
The Microsoft survey suggests leaders and their teams are seeing quite different rooms: 81% of leaders said it feels safe to suggest new ways of working with AI, against 67% of employees.[1] That gap is worth taking seriously when a sponsor tells you the culture is already supportive. From where they sit it probably is. That isn’t the same as it being true fourteen levels of visibility further down.
So the ask is narrow: not enthusiasm, which they’ll offer freely, but one visible act that makes their support legible to people who can’t see their calendar. In our experience that single act does more for a rollout than another round of internal comms, though I’d hold that loosely, since it’s an observation from the programmes we run rather than something anyone has measured.
Something I got wrong for years: treating the security conversation as an obstacle to be got through rather than a set of questions with correct answers.
Security teams aren’t being difficult. They’re being asked to take on an unquantified risk on behalf of an organisation, usually with less information than they need and less notice than they’d like. When they slow you down it’s normally because they can’t yet describe what they’d be approving.
Bring answers, not reassurance. Reassurance is what they’re paid to distrust.
Bring one page with these already filled in. If you can’t fill a row, say so rather than guessing, because a wrong answer here costs you the relationship and the timeline.
| Question | What a usable answer looks like |
|---|---|
| Where does the data physically go, and is it used for training? | Named region, named contractual position on training, with the clause reference. “The vendor says no” is not an answer, the contract is. |
| What can it reach on our systems? | The specific scope. Which mailboxes, which sites, which drives. If the answer is “whatever the user can see,” say that plainly, because it changes the whole review. |
| Who is allowed to turn it on, and how do we turn it off? | Named admin role for provisioning, and a tested route to revoking access for one person in under an hour. |
| What does it do without a human present? | If nothing, say nothing, and it’s a much shorter conversation. If it can act on a schedule or send anything, that’s a different risk class and they need to know now. |
| What are we asking people not to put in it? | Four plain categories, already written, in the words your staff use. Not a link to a 30-page policy. |
| What’s the pilot boundary? | How many people, which department, for how long, and what specifically would end it early. |
Six questions worth answering before the meeting rather than during it. The fourth row is the one that most changes how a security team responds.
Microsoft’s own 2026 report names the three risks security teams are actually weighing where tools can act rather than just answer: data leaving where it shouldn’t, actions taken that nobody intended, and access reaching further than expected.[1] Reading that was useful mostly because it’s the vendor saying it. If the company selling the software is listing those three, a security lead raising them isn’t being obstructive.
There’s one more thing worth bringing, and it answers the question underneath all six: when this thing gets something wrong, who is accountable? Have that written down per use case before the meeting rather than improvised in it.
| What AI does | What a named person still owns | How that’s evidenced |
|---|---|---|
| Drafts a first-pass response to a customer query using the knowledge base | Anything that reaches the customer. Nothing sends without a person clicking send. | The tool has no send permission at all. That’s a configuration, not a policy, and security can verify it. |
| Summarises a contract or policy document for an internal briefing | Every claim the briefing is acted on. Named owner per document. | Two claims per summary spot-checked against the source, logged in the same place the summary lives. |
A worked example of the accountability split for two use cases. Security teams read the third column first, because a control they can verify is worth more than an assurance they can’t.
The single most useful thing you can offer is a boundary. An open-ended request to approve a tool for everyone is a large, undefined risk. Forty people in one department for ninety days, with a named end date and a stated condition for stopping early, is a small, defined one. Security teams are usually far more willing to approve a bounded thing quickly, and the pilot gives you something more persuasive than any business case: evidence.
A team lead I worked with never objected to a rollout once. Sat in every session, nodded, asked one polite question. He also never removed the old Friday reporting template from the shared drive, and never said anything when his team kept using it. Four months later the tool was live, licensed, and doing nothing, and there was no meeting you could point at where it had gone wrong.
He wasn’t being obstructive. His team’s numbers were his, his people were already busy, and nobody had told him what happened to his targets during the weeks his team was slower because they were learning something. So he did the sensible thing and protected the thing he’d be measured on.
A manager who wasn’t asked will not defend it.
The Work Trend Index puts a number on the pressure he was under. Around 45% of AI users say it feels safer to focus on current goals than to redesign work with AI, and only 13% say they’re rewarded for reinventing how work gets done if the results don’t land.[1] Both of those describe a system, not an attitude. You can’t out-message a system that pays people for this quarter’s numbers.
What you can do is have the conversation nobody has. Individually, fifteen minutes, before the announcement. Here’s the version I’d actually use, with the words in it, because “engage your managers” is advice that dies on contact with a calendar.
| Beat | Roughly what you say |
|---|---|
| Name the cost first | “Your team will be slower for about a month. I’d rather tell you that now than have you discover it.” |
| Say what protects them | “I’ve spoken to Dan about your Q4 numbers. Nothing changes on the targets, and he knows why there may be a dip in October.” Only say this if it’s true. If you haven’t had that conversation, have it before this one. |
| Ask, don’t inform | “Which of your team’s recurring tasks would you pick to try this on first? You know their week better than I do.” |
| Give them something to be right about | “Can I use your example in the launch note and credit you?” A manager who is publicly the source of a good idea has a reason to defend it. |
| Name the exit | “If it’s not working for your team by the end of November, tell me and we stop. I’d rather know than find out from your reporting.” |
A worked example of the pre-announcement manager conversation. The second beat is the one that decides the rest, and it’s the one that requires you to have done real work upstream first.
Worth being specific about who “manager” means here, because the conversation differs. A first-line manager with a delivery number is worried about throughput this quarter. A functional lead two levels up is worried about whether their function looks behind. A team lead in a support function is often worried about neither and simply doesn’t want to become the person who fields everyone’s questions. Same fifteen minutes, different second beat.
Then there’s the part that’s genuinely uncomfortable. If a manager’s honest position is “my team is at capacity and I have nothing to give,” that isn’t resistance to manage. It’s accurate information about your plan. Either you find the capacity or you pick a different team to start with, and picking a different team is usually the better answer.
Most advice on resistance assumes it’s a misunderstanding, and that better messaging fixes it. Sometimes true. Often not, and treating a legitimate concern as a comms problem is how you turn a sceptic into an opponent.
Treat a specific objection as information. Only the vague ones are about feelings.
Four kinds show up repeatedly, and only one of them is really about communication.
| What you hear | What it usually is | What actually helps | What makes it worse |
|---|---|---|---|
| “So what happens to the two people who currently do this?” | A real question about job security, asked on someone else’s behalf because asking for yourself is harder | Answer it directly, including the part you don’t know. “Headcount isn’t changing this year. Beyond that I can’t promise, and I’m not going to pretend I can.” | “AI won’t replace you, it’ll augment you.” Everyone has heard it. It answers nothing and signals you won’t engage. |
| “I don’t have time to learn something new right now” | Usually literally true, and a workload question wearing a technology costume | Fix the workload or move the start date. Name the hours it needs and where they come from. | Framing it as an investment that pays back later. They already know. That’s not the constraint. |
| “We did this with the last system and it went nowhere” | Accurate memory. They watched a rollout fail and nobody acknowledged it | Say what was different last time and what you’ve changed. If you were involved, say so. This one is repaired by specifics, not by optimism. | “This time is different.” Unsupported, and it tells them you weren’t paying attention last time either. |
| “I’m not comfortable putting our data into that” | Frequently a well-informed position, sometimes the most informed one in the room | Bring them the actual answers from the security review. Ask them to help write the never-do list. Sceptics make excellent authors of guardrails. | Deferring to “IT has approved it.” That’s an appeal to authority against someone who wants the reasoning. |
A triage table for the four objections that come up most. The third column is where the work is; the fourth is where most rollouts go instead.
The pattern across all four: the specific objection is a gift. It tells you exactly what to fix. What should worry you is the meeting where nobody objects at all, because that’s the room where everyone has decided it’s easier to wait this out.
So a diagnostic worth running: after your manager conversations, count how many gave you a concrete concern. If it’s fewer than half, you didn’t get the truth, and the eleven weeks are still ahead of you rather than behind.
If the room stays quiet, three things usually unstick it, in ascending order of how uncomfortable they are:
The last thing, and it’s the one that turns all this into something other than a project plan. Every conversation above ends with the same promise, which is that people will be supported once this is live. That promise is where rollouts are actually won or lost, and it’s a different discipline from getting agreement: quick-start materials, worked examples from the team’s own tasks, and somewhere to ask a question. We’ve written that up separately in the AI user enablement guide, which is the natural next piece if the buy-in part is already handled. If the underlying question is whether to invest in the skills at all, that argument is here.
Teams run this alignment work internally all the time and it works. Where an outside facilitator earns their fee is in the rooms where the honest objection won’t be said to you, because you’re the person asking for the change. Our corporate workshops often start with exactly that session. Either way, the first move this week is small and it isn’t an email: pick the manager most likely to quietly ignore this, and book fifteen minutes.
Four groups, and they need different conversations in a specific order. IT and security come first, informally, before anything is signed, because getting funding for something that turns out to be unapprovable is an expensive way to lose credibility. Senior leadership and budget holders come second, once you know it’s approvable. Middle managers whose teams will change come third, individually and before the general announcement. The people who’ll actually use it come last, at announcement, with worked examples of their own tasks already prepared. The order matters because each group’s willingness partly depends on the previous one: managers ask what leadership has said, and leadership asks whether security has looked at it.
Arrive with answers rather than reassurance, and offer a boundary. The six things worth having written down before the meeting: where the data goes and the contractual position on training, with the clause reference; exactly what the tool can reach on your systems; who provisions it and how access is revoked for one person quickly; whether it can act without a human present, which is a different risk class entirely; the specific categories of information staff are asked not to put into it; and the pilot boundary. That last one does the most work. Approving a tool for everyone indefinitely is an undefined risk. Approving forty people in one department for ninety days, with a stated condition for stopping early, is a defined one, and defined risks get decided much faster.
Usually because they’re being measured on this quarter’s output while being asked to accept a period where their team is slower. That’s a rational response to a system, not an attitude problem, and it can’t be fixed by messaging. Microsoft’s 2026 survey found around 45% of AI users say it feels safer to focus on current goals than to redesign work with AI, and only 13% say reinvention is rewarded when results don’t land. The specific fix is to have the numbers conversation with the manager’s own manager first, then tell the manager you’ve had it. Without that, the most likely outcome isn’t objection, it’s a manager who agrees in the meeting and leaves the old process quietly running alongside the new one.
An announcement tells people a decision has been made. Engagement asks them something before it has, and then visibly uses the answer. The practical test is whether anything in your plan changed because of a conversation. If the launch note is identical to the draft you wrote before you spoke to anyone, you ran a communication exercise, and the people you spoke to know it. The version that works is unglamorous: fifteen minutes each, individually rather than in a group, and one real question, like which of their team’s recurring tasks they’d pick to start with. Asking that question and then using their answer, with credit, buys more defence of the rollout than any amount of internal comms.
Before the budget conversation, which is earlier than most people expect. The informal check with IT and security should happen while you’re still shortlisting, because the answer occasionally rules an option out entirely and it’s far cheaper to learn that before you’ve asked for money. Manager conversations should happen before the general announcement, without exception. The failure pattern is consistent enough to plan around: the moment a group hears about a change from a mass email, or from an external source before an internal one, you stop asking for their input and start asking them to ratify a decision. Those are very different requests, and the second one is where reviews stop getting scheduled.
The three figures in this article come from the Microsoft Work Trend Index 2026 annual report itself, read on 27 August 2026, rather than from coverage of it. All of them are self-reported survey responses from 20,000 knowledge workers who already use AI at work, collected at one moment in time, and the report states in its own methodology that its analysis shows statistical association rather than causal effect. That is worth holding onto, particularly for the leader-versus-employee gap, which measures a difference in perception and not a difference in fact. Four further manager-behaviour comparisons from the same report would have supported the middle-manager section and were deliberately left out, because stacking four percentage pairs into one paragraph is what turns a blog post into a spec sheet. The stakeholder sequencing, the fifteen-minute conversation structure and the resistance triage are Future Factors’ own, developed from running adoption programmes with client teams, and are described that way rather than presented as research findings.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.