Not everyone on your team is excited about AI. Some are worried about what it means for their job. Some have tried it, found it underwhelming, and written it off. Some are carrying a general distrust of technology that has been oversold before and did not deliver.
That scepticism is rational. It is based on real experience. And trying to overcome it with enthusiasm, mandate, or a vendor's marketing material will not work.
Getting a sceptical team to genuinely adopt AI tools is a change management problem first and a technology problem second. The approach that works is the same one that works for any significant change: start with the people, not the tool.
Understand what the scepticism is actually about
Scepticism about AI in a workplace setting tends to come from one of a few places.
Concern about job security is the most common and the most significant. If the message the team is receiving, explicitly or implicitly, is that AI will reduce the need for their role, their resistance to adopting it is not irrational. It is self-protective.
Past experience with technology that was oversold is another common source. Teams that have been through system implementations that did not deliver, or that were trained on tools they were then never given time to actually use, approach the next wave of technology with understandable wariness.
Some people are simply unfamiliar with the tools and uncomfortable with that unfamiliarity. The scepticism is really anxiety about being exposed as someone who does not know how to use them.
Understanding which of these is driving the scepticism in your specific team determines the right response. They require different approaches.
Address the job security question directly
If there is a genuine concern about job security, the worst thing to do is avoid it. Leaving the question unanswered does not make it go away. It makes it louder, because people fill the silence with their own assumptions.
Be direct about what the organisation is and is not trying to do with AI. If the intention is genuinely to use AI to remove repetitive tasks so that people can do more interesting work, say that clearly and mean it. If there are roles that will be affected, be honest about that too, and explain what the plan is.
The teams that adopt AI most successfully are the ones where the leadership has been honest about the intent, specific about what is changing, and credible in following through on what they said.
Start with the problem, not the tool
Introducing AI by saying "we are going to start using this tool" is the wrong starting point. Introducing it by saying "this task takes everyone four hours a week and we think there is a better way" is the right one.
When the starting point is a real problem the team actually experiences, the conversation about the solution is different. People who are frustrated by the problem are open to solving it. They evaluate the tool on whether it actually helps rather than on whether they were asked to use it.
Pick a use case that is clearly painful and clearly contained. Not the most ambitious AI application you can think of. The one where the benefit will be most immediately visible to the people using it. A first experience that saves real time, that the team can see and feel, changes the dynamic for everything that follows.
Give people space to be bad at it first
AI tools have a learning curve. The first few attempts at using them tend to be clumsy, produce mediocre results, and take longer than the manual approach. That is normal. It is also the point at which most reluctant adopters give up and conclude the tool does not work.
Create the conditions for people to try, fail, and try again without it mattering. Dedicated time to experiment. A shared space to post outputs and get feedback. Permission to produce a bad first result without it reflecting on them. The team members who are enthusiastic early adopters are a resource here: pairing them with the more sceptical members, informally and without making it a formal training exercise, tends to be more effective than any structured training program.
Measure and share the results
Nothing changes minds faster than evidence from someone on your own team. Not a vendor case study. Not a conference presentation. A colleague who used the tool for a specific task, saved three hours, and will tell you about it honestly.
Track what is happening in the early weeks. Where is the tool being used? What results are people getting? Share those stories in the team, in normal conversations, not as a formal communication about the AI rollout. The organic social proof that builds within a team is more persuasive than any top-down message.
If the results are not materialising, that is worth knowing too. Either the use case was wrong, the tool needs more configuration, or the support has not been sufficient. Measuring honestly surfaces those issues before they become permanent barriers to adoption.
What not to do
Mandate adoption without addressing the concerns that sit underneath the resistance. The tool will be used minimally and in ways that satisfy the mandate rather than in ways that create value.
Roll it out to everyone at once before you have a clear success story from a smaller group. The success story is what makes the wider rollout easier.
Treat the sceptics as the problem. They are asking questions that deserve answers. The organisations that get genuine AI adoption are the ones that take those questions seriously rather than trying to move past them.