When a company introduces automation, the most delicate change isn't technical: it's human. The software works sooner or later. Guiding the team through change is the part that decides whether the new way of working will be adopted or merely endured. What lands on my desk isn't software problems: it's people who need answers nobody has given yet.
The four questions nobody asks in meetings
In meetings, the questions are few and technical. The real concerns come later:
- “Does my work still matter?” — the fear of becoming redundant.
- “Will I be able to use it?” — the fear of being exposed as inadequate in front of colleagues.
- “If it gets it wrong, whose fault is it?” — feeling responsible for something you don't control.
- “What will I do with the time that frees up?” — a role that changes shape.
Naming them first takes the oxygen out of rumours: you don't need all the answers, you need to say what you know and what you don't.
Where resistance really comes from
Resistance is almost never a rejection of technology: the same people use digital tools all day long. It comes from three things.
- Loss of control. The work goes into a box whose rules you can't see.
- Loss of recognition. That task was professional identity: “that part was mine to run”.
- Fear of judgement. If the process was full of exceptions, someone fears the analysis will prove they were doing it wrong.
The first two are addressed with transparency; the third depends on the analysis: if exceptions are gathered as information, people talk about them.
The three roots of resistance
Loss of control
“The work ends up in a box whose rules I can't see”
Transparency: show how it works
Loss of recognition
“That part was mine to run”
Redefine the role and give it value
Fear of judgement
“They'll find out I did it my own way”
Gather exceptions as information
The four phases I've seen repeat
The announcement to the team, the process analysis, the first few weeks, the months that follow: projects always go through the same four phases, and each one calls for a different kind of support. At the start people need information, in the middle presence, at the end recognition.
The typical trajectory of team trust. A qualitative sketch, not a measurement.
The hardest moment isn't the announcement, as you might expect, but the first few weeks: that's when the old and new methods coexist, mistakes are more frequent and the effort doubles. And it's exactly when the company's attention moves elsewhere.
| Phase | What the team goes through | What I do |
|---|---|---|
| The announcement to the team | Suspicion: “they're getting ready to cut jobs” | I say which roles are affected and which aren't, even when not everything has been decided yet |
| The process analysis | Feels under scrutiny, fears having done something wrong | I let the people who do the work speak as experts, not as the object of the analysis |
| The first few weeks | Double workload: old and new methods side by side, with inevitable mistakes | Protected time to learn and explicit permission to make mistakes in the first few weeks |
| The months after | A role to redefine: “so what do I do now?” | I update duties and objectives, and recognise those who carried the transition |
The four phases of an automation project, seen from the people's side.
Change management isn't support: it's half the project
In most companies HR comes in downstream: it handles training and, if things go badly, discontent. That's a sequencing mistake: the part that decides the outcome — who will do what afterwards, which skills are needed, how to communicate — is our job, and it can't be delegated to IT or to the vendor.
Three things nobody else can do for us:
- Read the project as a map of roles, not of processes. Where the flow changes, duties and responsibilities change too, and that has to be put in writing before go-live.
- Tell apart those who are exposed from those who are merely involved. Anyone whose role is centred on that process should be met one-to-one, before the announcement.
- Hold two different timelines together. The project's ends at go-live, the people's lasts for months: someone has to look after the second when everyone else has moved on.
An automation project rarely fails because of the software: it fails months later, because of the people who leave or carry on as before.
What happens to the time that frees up
It's the question people ask first and the one that gets answered last. If nobody decides where it should go, the time recovered from an automated process gets swallowed up by whatever is urgent at the moment, and the message people receive is that the goal was to get more out of the same people.
Giving it a recognisable destination — quality checks, relationships with customers and suppliers, the tasks that have been put off for months — changes how the whole project is read. And this is when recognition really counts: those who carried the transition should be named, in performance reviews and in front of the group. It costs nothing and is worth more than any internal communication.
Guiding the team through change: how much it matters
It isn't a “soft” issue: according to Prosci, projects with excellent change management meet their objectives 88% of the time, against 13% for those managed poorly.1
Projects that meet or exceed objectives, by quality of change management. Source: Prosci, Best Practices in Change Management.
And when the change is AI
With an automated process, the question is what will become of that task. With AI it gets more uncomfortable: what will become of my judgement. And there's a practical difference: AI has already entered the company without anyone announcing it. According to Sharp Europe, 45% of employees use it without saying so, and a third of managers worry they'll look like they're cutting corners if they admit it.2
And it isn't just about tools: a well-written answer looks true, and checks get skipped exactly where they're needed. The problem isn't adoption, it's what stays hidden.
- Write the usage rules early, even if they're imperfect. What can be used, for which tasks, which data must never be entered. Without rules nobody stops using it: they stop saying so.
- Say who remains accountable. AI proposes, the person signs off: judgement has to be trained, not delegated.
- Ask openly who already uses it and how. With no consequences, starting with the managers: if they describe how they use it, what's hidden comes to the surface.
- Share how it's being used. Everyone builds their own prompt library and the work splinters into silos: half an hour of exchange between colleagues is worth more than a course.
- Put training on record. The AI Act requires those who use AI systems to take measures for an adequate level of AI literacy among their staff: it's no longer just good practice.3
- Don't use it to assess people without telling them. That's where trust is lost in a single day.
In short
Automation doesn't replace a team: it redraws its boundaries. Making that redesign understandable and gradual — listening before, presence during, recognition after — doesn't take budget: it has to be planned together with the project.
The difference between a successful adoption and an endured one isn't in the technology, but in when people start talking about the people. If it happens before the roles are decided, guiding the team through change becomes ordinary work instead of an emergency. The signal is simple: in one-to-ones, people talk about the new work, not the work they've lost.
Write to us to talk about itIf an automation project is about to start at your company, the first question isn't which tool to choose: it's whose work will change, and by how much.
Sources
- 1.The Correlation Between Change Management and Project Success — Prosci, Best Practices in Change Management — oltre 2.600 professionisti del cambiamento (aggiornato 2026)
- 2.New Sharp research reveals the hidden cultural friction slowing down responsible AI adoption across European SMEs — Sharp Europe, 1 giugno 2026 — indagine Censuswide su 2.500 titolari di PMI (50-250 dipendenti) in 10 Paesi europei
- 3.AI Act, Article 4: AI literacy — Regolamento (UE) 2024/1689 — Commissione europea, AI Act Service Desk


