Reassurance rarely moves a skeptical team. Handing them a real decision about how the rollout runs often does.
Resistance usually quiets down when the doubtful hold a real decision, not when they’re reassured. Hand over a one-page draft workflow with a review brief, publish the fixed list first, reply to every request in writing, and check Use, Persistence and Impact after 30 days.
The people most likely to resist an AI rollout rarely say so. They attend the kickoff, finish the module, and use the tool just often enough to stay off the report. For the first few weeks that looks like adoption, and the gap shows up later, when the workflows that were meant to change are still running the old way.
Three triggers come up again and again behind this pattern, based on how rollouts tend to go rather than on a study:
The first two deserve their own conversations, and we’ve covered them in our guide to empathy in AI adoption, which is about working out what a particular person is protecting, and in what to say when your team is afraid AI will replace them. This guide picks up from the third trigger, the one a leader can change directly, and asks what the rollout looks like once the people it affects help design it.
A claims team lead opens the Monday meeting by showing the new drafting assistant. The prompts are saved, the review step is set, and the usage report goes to a director. Nobody in the room was asked about any of it. The senior adjuster who handles the awkward files says it looks useful, then writes her file notes the way she has for years.
Nothing about that is hostile. She has worked out that her view has no route into the rollout, and not changing is the only vote she’s been offered. That’s closer to a design problem than an attitude problem, which is why reassurance tends to fall flat at this point: it answers a feeling when the complaint is that the decisions were taken without her.
The worry underneath is not made up. In Pew Research Center’s survey of U.S. workers, fielded in October 2024, about a third expected AI use at work to mean fewer job opportunities for them over the long run.[1] A leader can’t promise that away, and I wouldn’t try. What a leader can do is hand over real decisions about how the change happens, which is a different offer from reassurance and a more credible one.
Everything below is a Future Factors working model, built from how rollouts tend to go and not from a validated study. It assumes the decision to adopt AI has already been made, and asks how much of the how can be shared.
A rollout contains more decisions than the announcement suggests, and most of them are made quietly before anyone outside the project team sees the tool. Four are good candidates for sharing, because each one answers a worry people already have.
A Future Factors working model based on our own judgment. The four decisions are where we see rollouts most often settle things before the people affected have seen them.
Share a decision people can change, not a survey they can only answer.
The test of “real” is whether the answer could change what ships. If the prompts, the review step and the reporting are final, a feedback form is theater, and people tend to notice that quickly. They also tend to remember it the next time they’re asked for input.
You won’t share all four on day one. I’d start with one decision on one workflow, usually how it runs, because that’s where the people doing the work know the most and a leader knows the least. Which task goes first and how it will be judged can follow once that first round has gone well.
The usual objection is that this slows the rollout down. It adds a round before launch, and that’s a real cost. The trade is against the rework that tends to come later, when a workflow nobody trusted gets quietly bypassed and has to be redesigned anyway.
Who sits in which seat matters as much as which decisions are open. “The team” is too broad to be useful here, because the person whose craft is changing, the person who reviews the output and the person who signs off on data have different things at stake.
The people with the least say are often the people with the least information. In Gallup’s August 2025 survey of employed U.S. adults, 26% of individual contributors said they didn’t know whether their organization had implemented AI, against 16% of managers and 7% of leaders.[2] The report’s own reading is that employees further from decision-making are less aware of what’s happening. Pick seat-holders by role and by how much their work changes, not by who is loudest or who volunteered first.
That last point is the difference between this and a champions network. Our guide to building an AI champions network is about enthusiasts who spread use. The people in these seats are mostly the opposite: the doubtful, the most affected and the people well placed to spot what’s wrong.
Asking a team “what do you think about AI?” gets polite answers. Handing them a one-page draft of how a workflow would run, and asking for a mark-up, gets objections you can use. People who can’t easily say they’re worried can usually say that step three is wrong.
A content editor handed a one-page draft of a newsletter workflow reads it at her desk and stops at step three, where the assistant rewrites the headlines. Headlines are the part of the job she’d keep. She strikes the step, writes in its place “assistant offers five alternatives, editor picks or discards,” and sends it back the same afternoon. The tool didn’t change. The person who owns the craft drew the line on it.
The brief below is the cover sheet for that kind of draft. It’s filled in for a finance example so you can see the standard, and the fields people most often leave blank are the third and fourth: what you’re unsure about, and what is fixed.
| Field | Filled in |
|---|---|
| The job | Monthly variance commentary in the finance team: a first draft of the “what moved and why” notes that go to the controller. |
| The draft | Step 1: the analyst exports the variance table. Step 2: the assistant drafts one line per variance above the agreed threshold, citing the ledger lines. Step 3: the analyst rewrites or deletes each line. Step 4: the controller reviews the final notes as before. |
| Who decides what | Assistant: first-draft lines only. Analyst: every word that goes forward. Controller: sign-off, unchanged. |
| What we’re least sure about | Whether step 2 saves time once the analyst has checked each citation. Whether the assistant should see last month’s commentary. |
| What’s fixed | No customer-level data goes in. Controller sign-off stays. Reasons are attached to each. |
| What you can change | The order of the steps, the threshold, the wording of the instructions, and whether this runs for one month before anyone else uses it. |
| How to respond | Mark up the draft or leave a comment by Thursday. Two analysts and the controller are asked directly. Anyone else is welcome. |
| What happens next | Replies in writing within a week. Every request goes in the change log with what was decided and why. The first month runs as a trial and gets reviewed together. |
Fields chosen by Future Factors; the workflow and dates are an illustration, not a client case. Adapt the fields to the workflow, but keep the fixed and open rows.
Ask for objections to a draft, not opinions about an idea.
Before you hand a draft over, you can use AI to find the weak spots first. Treat the output as a list of questions to bring to the real person, not a forecast of what anyone thinks.
| Read the draft workflow below as a [role, for example senior editor] who is worried about [concern, for example losing control of the final wording]. List the three steps most likely to feel like a loss of control, skill or accountability to that person. For each step, give the question they would probably ask and one change that would make the step acceptable. Use only what is in the draft. Do not reassure, and do not guess what any individual thinks. Draft: [paste the one-page draft] |
Use only a tool your organization already approves for internal documents. The output prepares your questions. It does not replace asking the person.
Sharing decisions only works if people know where the edges are. A leader who invites input on everything, then overrules it on the points that matter, teaches the room that asking is theater. The remedy is to publish the fixed items first, with a reason for each, and then invite input on everything else.
Say what’s fixed before you ask what’s open.
This is the list I’d publish before the first review round. Each fixed item needs a named person who can explain it when someone pushes back, and each open item needs an owner who will act on what comes in.
Fixed, and who explains it:
Open, and who acts on it:
A labor contract is an unusually formal example of a fixed line, and it shows the shape well. The Writers Guild’s 2023 agreement with the studios says a company can’t require a writer to use AI software, lets a writer choose to use it with the company’s consent, and requires the company to disclose when material it hands a writer was generated by AI.[3] Few employers will write something like that for every role, and it came out of collective bargaining, which is a different setting from most teams. What carries over is that the limits were stated up front, and the people whose work was affected took part in setting them.
The thing that turns a one-off review into collaboration is what happens afterward. People who spoke up and heard nothing back draw the obvious conclusion. A change log fixes that by recording every request, what was decided and what changed, including the requests you declined.
| Raised by (role) | What they raised | Decision | What changed | Told on |
|---|---|---|---|---|
| Senior editor | The assistant rewrote headlines, the part of the job she’d keep | Accepted | Step now offers five alternatives; the editor picks or discards | Same week, in person |
| Claims adjuster | Summaries didn’t show where each point came from | Accepted | Output must link each point to the source line, or the step doesn’t pass review | End of week one |
| Analyst | Usage report listed individuals by name | Accepted, in part | Team-level counts go to the director; each person sees only their own | End of week one |
| Security lead | Customer names being pasted into prompts | Accepted | Added to the off-limits list, with the reason | Next team meeting |
| Several team members | Make use optional for all tasks | Not changed | Use stays expected for the first workflow only. Reason given; revisit at the 60-day review | In person, by the team lead |
A Future Factors working tool; the entries are an illustration, not a client case. The last row matters most: a visible no, with a reason and a date to revisit, builds more trust than a quiet yes.
If nothing changed because of what people said, nothing was shared.
To tell whether the collaboration is real, use the lens we apply to any AI workflow. Use asks whether people took part: how many of the seat-holders sent back a mark-up, and, just as telling, who didn’t. Persistence asks whether, a month later, the same people are still raising issues and still running the workflow without a reminder. Silence after a good first round can mean people have decided it doesn’t matter. Impact asks whether the workflow now differs from the original draft in ways people can name, and whether there are fewer corrections at the review step.
A comment count is only the first of those. A rollout can collect plenty of feedback and still be measuring access, not whether anything changed.
A fair amount of this work is paperwork: sorting comments, drafting replies, keeping the log current. AI can take much of that preparation, and the decisions and the conversations stay with people.
| What AI does | What people still own | How it gets checked |
|---|---|---|
| Sorts the mark-ups and comments from a review round into themes, with the original wording attached | Deciding which requests to accept, change or decline | The team lead reads every raw comment, not only the theme summary |
| Drafts a change log entry and a reply for each request | Telling the person, and in person for any declined request | The person who raised it confirms the entry describes what they meant |
| Plays the skeptical role to find weak spots in a draft before you hand it over | Asking the real people, and not treating the AI’s list as their view | At least one real mark-up for every step the AI flagged |
| Summarizes usage and review data at team level | Whether the numbers show persistence and impact or only use | The sponsor and team lead review it monthly, with the change log beside it |
| Keeps the fixed-and-open list tidy and consistent | What goes on it, and any statement about roles or headcount | Leadership signs off the fixed items, and HR reads anything about jobs |
Use only tools your own policy approves for internal documents. Don’t send individual comments to a tool you haven’t cleared for that data.
This is also where the usual chain of terms earns its keep. Training builds capability, so people can use the tool well in principle. Workflow design gives that capability a recurring task to land in, and the shared decisions in this guide are workflow design done with the people who’ll live in the workflow. Reinforcement, through the review rounds, the change log and managers who check, turns it into behavior. Adoption is what you see when all three have happened. That’s the Behavior part of our Tool x Workflows x Behavior idea, and it’s why collaboration shows up in the numbers late and not on day one.
A team can run these rounds internally. Structured training and a facilitated session shorten the learning curve and build shared capability across a team instead of in one enthusiastic person, and an outside facilitator can be useful in rooms where the honest objection is hard to say to the person sponsoring the change. If your question is who to bring in and when, our guide to stakeholder engagement for AI adoption maps the groups, and change management for AI adoption covers the sequence of communication around them.
I wouldn’t start with a company-wide consultation. I’d pick one workflow, one decision, and the people whose work it changes most, then run one round properly.
If you only do one thing this week, write the fixed list. It’s short, it takes an hour, and it’s the page that makes everything you ask afterward believable.
Let them decline, and ask for the smallest contribution instead: one step marked up, or one line on what they’d need to see before trusting it. A refusal can also be information about an earlier rollout that went badly. Keep their seat open, keep the change log visible to them, and pick the conversation back up one-to-one.
Expect it. Two reviewers will often want opposite things from the same step. The workflow owner decides, using the fixed list as the boundary, and writes both views into the change log with the reason for the choice. If it’s close, run both versions for a month and compare corrections at the review step before settling.
Send the review brief as a shared document with a five-working-day window, and ask named roles to respond, not everyone. On a large team, have each role group choose its own representative instead of appointing one, and publish the change log where everyone can read it. Representatives hear the objections; the log shows the rest of the team what happened to them.
About a week for a single workflow. Shorter than that and the quiet people don’t get to it, longer and the draft goes stale and the replies thin out. Close the round with a thirty-minute readback where you walk through the change log, and extend the window once at most, saying why.
Champions are usually enthusiasts who spread use. The seats here go to the people whose work changes most and the people most likely to find what’s wrong, who are often the doubtful ones. The same person can be both, but they’re chosen for different reasons and given different authority: a champion helps others use the workflow, and a seat-holder helps decide what the workflow is.
Sources were read on October 9, 2026: Pew Research Center’s February 2025 report on U.S. workers and AI (survey fielded October 2024), Gallup’s December 2025 analysis of AI use at work (survey fielded August 2025), and the Writers Guild of America’s AI rights page describing the 2023 agreement, last updated December 2025. The Pew and Gallup figures are survey results, and the guild terms are a labor contract from a different setting than most teams, so they illustrate a pattern and don’t prove one. We left out the classic 1948 study of employee participation in factory change because the full text is behind a paywall and we could only read it through secondary summaries. The four shared decisions, the review brief and the change log are Future Factors working methods based on our own judgment, not research-validated models. The scenes are illustrations, not client stories.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.