Stacking rational arguments
A third demonstration, a fourth comparison table, another webinar: you are answering an objection nobody raised. Until the real fear is named, every additional argument reads as additional pressure.
Change management
How do you handle an employee who resists change?
Resistance to change is rarely conservatism. It is an anticipation of loss — of competence, of status, of bearings. So the lever is not another argument about the tool’s benefits. It is to name the feared loss, address it explicitly, then give the resister an actual role in the transition.
Adrien VasseurUpdated
Practise this scenarioSign in required — practice scenarios live in the member area.
The situation when a team digs in against a change
The new project management tool has been live for six weeks. Philippe, twenty years in the company, is still on his spreadsheet. He does not object openly: he just needs to finish this file first, he will look at it next week. His colleagues have started maintaining both systems for him. The new tool’s data is incomplete, therefore unusable, therefore nobody really believes in it. One well-placed silent refusal is enough to sink an entire rollout. What is actually happening is almost never said out loud: nobody announces «I refuse». You hear «I’m not against it», «it’s just not the right moment», «I’ll get to it once this is out of the way». Those sentences are the real signal, because they protect the relationship while freezing the calendar, and because they give you nothing to answer.
Why it is difficult when a team digs in against a change
You arrive with efficiency arguments while the other person is having an identity problem. Twenty years of mastery become suddenly irrelevant, and hard-won expertise loses its exchange value inside the team. No time-saving demonstration answers that. On top of the asymmetry sits a positional trap: a respected senior has more pull than you do on questions of practice, and a head-on power contest usually ends in minimal compliance without buy-in, which costs more than open refusal. There is one more factor managers rarely admit: you did not choose this change either. Defending a tool you privately find imperfect casts you as a spokesperson, and the reflex from there is to overplay the enthusiasm — which a team detects within one meeting, and which destroys exactly the credibility you need in order to hold the date.
The most common mistakes when a team digs in against a change
Dismissing the old method
«The spreadsheet was always a hack» attacks twenty years of work in six words. You will get instant hardening. The old method worked; saying so sincerely is the entry price for the conversation.
Letting one exception run
Tolerating a single island of double entry «until things settle» kills the rollout. Everyone else does the maths quickly: if the exception is permanent, we may as well all go back.
Confusing slow learning with refusal
Someone who takes three times as long on the new tool is not necessarily hostile — they may be humiliated at being a beginner again in front of juniors. Treating them as an opponent creates the opposition that was not there.
Implying the decision is still negotiable
To sound open, you let slip «we’ll see whether it holds» or «nothing is set in stone». What is received is not openness, it is a reprieve: the person stops learning the tool and starts lobbying colleagues again. Scope and pace are open for discussion; the decision itself is not — and that line has to be drawn in the same words for everyone.
An approach that works when a team digs in against a change
Ask about the loss, not about the tool
Open somewhere other than the software: «What worked well in your way of doing this that we’re at risk of losing?» The answer almost always comes, and it is rarely technical. Write it down — it is your anchor for everything that follows.
Acknowledge what worked, specifically
One sincere, dated sentence: «Your tracking held this workshop together for ten years, nobody disputes that.» This is not a diplomatic concession: without it, everything you say next will be heard as a verdict on their career.
Give them a role in the transition
Change the position: «You know the awkward cases better than anyone. I need you to list the three situations the new tool can’t handle so we can escalate them.» The resister becomes a tester, which is both honest and far more effective than a forced conversion.
Set a date and the support together
Leave with something precise: which deadline, what help, which first file migrates. «The Vernet file moves across on the 12th, and we spend two hours on it together on the 5th.» Flexible on the support, firm on the date — never the reverse.
Check at the first milestone, not at the review
The check is early and short: «We said the 12th for the Vernet file — where are you with it?» If it is done, you say so in front of the team in one sentence, without irony and without turning it into an event. If it is not, you ask what blocked it before setting another date — once — and you say what happens if that one slips too. A missed milestone nobody mentions is a licence for every milestone after it, and that is the exact moment rollouts die.