How do I handle job-loss fear in the team?

Take it seriously rather than talking it away – it isn’t irrational. Three things work: honesty about what’s actually changing (tasks genuinely do shift), a clear commitment about where freed-up time goes (more demanding work, not job cuts – and that promise then has to hold), and the experience of control: anyone who confidently operates AI themselves feels empowered rather than replaced.

What does AI training actually achieve?

The classic lecture-style session, not much – the half-life of tool knowledge is short and the transfer into daily work is low. More effective: working together on real tasks people actually bring with them (team learning sessions where everyone brings a genuine case), making internal role models visible, and documenting standard cases. As a side effect, structured enablement like this satisfies the AI-literacy duty under the AI Act too.

How long does it take for a team to genuinely accept AI?

Experience suggests months rather than weeks – trust comes from repeated, personal positive experience, not a single good presentation. A realistic timeline allows for several learning cycles: first contact, first personal wins, and only then independent, routine use. Anyone wanting to speed this up should invest in support rather than speed.

What do you do when a single manager is blocking adoption?

Understand first, rather than simply overriding them: blockages rarely come from pure rejection – they usually stem from the same three patterns as in the team – fear, pride, or a bad first experience – just with more reach and role-model influence. A personal conversation with a specific use case relevant to that person often works better than any directive from above. If the blockage persists, it quickly becomes a culture problem, because the team picks up the signal.

Should we officially name internal AI ambassadors?

The informal version usually works better than an official title: someone appearing as an “appointed ambassador” quickly reads as a directive from above, whereas the same person as a respected colleague with genuine hands-on knowledge is more convincing. More useful than a title is visible time – a fixed slot, say, where these people can answer questions or show their own use cases, without it turning into an extra, unpaid side role.

Technology · AI at work

AI Adoption in Teams: Fears, Training, Culture

Most AI projects fail not because of the technology, but because people don’t use it. How leaders can take fears seriously and turn sceptics into experts.

By Boaz Lichtenstein

Article image: AI Adoption in Teams: Fears, Training, Culture

The post-mortems of failed AI projects rarely read “model too weak” – what’s written there, usually unspoken and rarely admitted openly, is: “the team didn’t use it.” With today’s tools, the technology question is usually the smaller one; the real rollout happens in people’s heads. And there it runs into concrete, human complications that leadership should understand rather than simply override.

Key takeaways

AI projects rarely fail because of the technology – usually because the team doesn’t use the tools.
Resistance has three typical causes: job-loss fear, wounded pride over one’s own expertise, disappointment after a bad first attempt.
Classic lecture-style training works poorly; learning sessions built around real, personal tasks work well.
Internal role models spread adoption more reliably than any memo from the top.
Whether AI is experienced as a control instrument or as a tool people own comes down, in the end, to the team’s culture – not the software itself.

The three faces of resistance

Resistance to AI in a team is rarely pure scepticism about the technology – usually one of three understandable reactions is behind it: fear for one’s own job, wounded pride in hard-earned expertise, or disappointment after a botched first attempt. All three deserve a targeted answer, not a blanket reassurance.

The fear: “Does this make my job pointless?” is the most obvious reaction to a tool that takes over parts of your own work – and it deserves an honest answer, not platitudes (see the FAQ). The pride: anyone who’s built twenty years of expertise quickly experiences the suggestion to “let the AI do it” as devaluation. The key lies in clarifying roles: AI supplies drafts and grunt work – the judgement, the experience, the responsibility stay with the professional, and become more valuable through this, not cheaper. How this shift in roles actually plays out is also covered in our article on AI agents at work. The disappointment: many sceptics are former users who gave up after a bad first attempt. Usually it came down to missing context and the wrong tasks – a guided second attempt with well-chosen cases turns around a surprising number of them. Importantly, the second attempt shouldn’t repeat the same, already-failed task, but deliberately pick a different, simpler one where success is likely – a second failure often cements the rejection for good.

Lecture or learning session? What actually works

The format of enablement determines success more than its length. A direct comparison shows why many AI training sessions achieve little:

Format	Typical outcome	Why
Lecture-style training, generic examples	Brief interest, barely any transfer into daily work	No connection to the person’s own task
One-off tool tutorial	Knowledge fades fast	No routine without repetition
Learning session with a real, personal case	Immediate “aha” moment, high adoption rate	Personal benefit felt straight away
Internal role models as points of contact	Lasting, organic spread	Trust among colleagues beats instruction

What actually builds adoption

Real cases instead of demos: nothing convinces like your own task suddenly done in a quarter of the time. Learning sessions where everyone brings a real case beat any presentation.
Role models instead of mandates: every team has two or three natural enthusiasts. Make what they do visible, and establish them as points of contact – adoption spreads through colleagues, not through memos.
Time as a signal: expecting people to learn a new way of working on the side signals that it doesn’t matter. A protected learning slot each week says the opposite.
Rules that provide security: the data policy and clarity that responsibility stays with the human take the risk feeling out of using AI – more in our roadmap for AI adoption at SMEs.
Make the error culture explicit: AI output is a draft; anyone who spots and reports an AI mistake has improved the system – not embarrassed themselves.
Make progress visible: share small, concrete wins within the team – “this saved us this much time this week” lands harder than abstract announcements.
Plan for repetition: a single workshop isn’t enough – fixed, recurring sessions (monthly, say) keep the topic alive instead of letting it fade after the kick-off.

The most common leadership mistakes when rolling out AI

Mandating tools without allowing time: anyone who introduces a new tool but creates no time to learn it generates silent resistance. Only showing wins at the top: a board presentation convinces nobody who hasn’t had their own win yet. Dismissing resistance as ignorance: scepticism almost always has an understandable reason – ignoring it costs credibility for the next attempt. Sanctioning mistakes instead of discussing them: a team criticised rather than supported for AI missteps stops using AI at all – and stops reporting problems openly.

From experience: the quiet test before the real project

Before launching a big rollout project, it’s worth running a small, informal test: show one person from each of the three resistance groups (fear, pride, disappointment) a specific task relevant to them, supported by AI, and observe the reaction. Anyone who meets rejection there gets valuable clues about which of the three causes actually dominates in their own team – and can tailor the rollout accordingly, instead of running the same standard programme across all three groups equally.

The culture test

Whether the rollout succeeds shows up in a simple observation: do people talk about AI like a control instrument (“now we have to do this too”) or like a tool that belongs to them (“look what I built with this”)? Leadership can’t mandate that difference – but it creates it: through honesty, time, and the discipline to invest the hours saved in better work rather than a tighter pace.

The bottom line

Tools take over tasks. Whether people experience that as loss or advancement is decided by culture – not the choice of model and not the training hours alone. The pragmatic next step is small: set up a first learning session with real cases, identify the natural role models in the team and make them visible, and then consistently protect time for it. Adoption doesn’t grow through announcements, but through repeated personal experience.

Anyone who follows this path consistently solves a second problem along the way: the mandatory AI-literacy training required under the AI Act turns from a tedious box-ticking exercise into genuine skill-building that actually lands in daily work – two goals with one measure, instead of an exercise that only exists on paper.