I have seen teams resist change even when the new tool is objectively useful. I recommend treating that resistance as information, not attitude, because people are often protecting delivery, identity, or hard earned judgment.
That caution is not automatically a problem. A team that protects production, customers, compliance, and hard earned operational knowledge is doing something useful. The leadership problem starts when we treat all hesitation as resistance. Some resistance is politics. Some is fear. Some is rational memory from the last migration that took too long, broke too much, or left the team owning a tool they did not choose.
People are not only resisting the tool
When I talk about "People are not only resisting the tool", I am looking for the behavior change, not the wording of the principle.
When pagers gave way to email and ticket systems, teams did not lose only a device. They lost a familiar operating model. When IDEs replaced simple editors for many developers, people did not question only the software. They questioned speed, control, shortcuts, memory, and whether the tool would hide what was really happening.
The same pattern shows up in cloud migrations. A data center team may hear "move to cloud" and think about outages, network controls, cost surprises, audit evidence, vendor contracts, and the skills they have built for years. A C team may hear "move more services to Java" and think about runtime overhead, garbage collection, deployment patterns, and whether the new stack will be treated as a fashion instead of a fit.
With AI, engineers hear both promise and risk: faster drafts, better search, and automated support, but also hallucinations, data leakage, review gaps, unclear ownership, and shallow work replacing real understanding.
Explain why now
A weak change message says, "This is the future." A stronger one says, "Here is the business or engineering pressure that makes the current model insufficient now."
For example, a leader asking teams to move from manually provisioned servers to infrastructure as code should not start with tool enthusiasm. Start with the facts: production and lower environments drift every month, release recovery takes too long, firewall changes are not traceable, and audit evidence requires manual screenshots. The change is not about liking a new tool. It is about making recovery, repeatability, and review easier.
Respect what the old system did well
My recommendation in "Respect what the old system did well" is to make the next action small enough that the team can try it quickly.
Teams trust leaders who can describe the old system fairly. Telephones were direct. Pagers were immediate. Text editors were fast and portable. Data centers gave teams physical control and clear boundaries. C gave engineers power, predictability, and closeness to the machine. The old way survived because it solved real problems.
If a leader cannot say what the old system did well, the team will assume the leader does not understand what is being replaced. Respect does not mean staying stuck. It means carrying forward the strengths that mattered.
Make the first step small enough to be safe
Big change becomes easier when the first move is reversible and measurable. Do not ask every team to adopt the new platform, language, AI workflow, or deployment model on day one. Pick one workflow with high pain and contained blast radius.
Turn skeptics into design partners
What I learnt around "Turn skeptics into design partners" is that people trust change more when the cost is visible and the first step is safe.
The people who challenge a change often know where it will fail. A senior engineer who says the new deployment platform will break audit evidence may be protecting a real control. A support lead who worries AI answers will confuse customers may know the edge cases better than the implementation team.
Invite the skeptics early, but give them a real role. Ask them to define failure modes, review the migration path, write rollback criteria, and help decide what evidence would make the change trustworthy. That turns resistance into quality control.
Measure trust, not noise
Adoption is not the same as trust. A team can use a new tool because leadership mandated it and still keep a private workaround. Real trust shows up in different signals.
- Teams stop asking for exceptions because the default path is good enough.
- Incidents, manual handoffs, or repeated review comments go down.
- New team members learn the new path faster than the old one.
- Teams bring new use cases to the platform instead of avoiding it.
- Skeptics can explain both the benefit and the remaining risks.
AI is the current leadership test
AI is where this pattern is playing out now. Some people see acceleration. Some see risk. Both can be true. A responsible leader does not dismiss either side.
For software teams, a good AI adoption path might start with internal documentation search, incident summary drafts, or test case suggestions. It should define what data can be used, when human review is required, how wrong answers are caught, and which tasks are out of scope. That is how a team learns safely instead of being pushed into a vague transformation slogan.
The framework I try to use
I use "The framework I try to use" to check whether the idea reduces friction for builders or only sounds good in a meeting.
When leading change, I try to use a simple sequence:
- Name the pressure that makes change necessary now.
- Describe what the old system did well.
- Start with one painful workflow and a limited pilot.
- Let skeptics define the failure cases.
- Measure operational outcomes, not announcement energy.
- Expand only after the team has proof.
- Write down the decisions, tradeoffs, owners, and rollback path.
Closing
The way I close this topic is to bring it back to trust: did the change become safer, clearer, and easier for the team to try?
People usually embrace change after it becomes useful, safe, and ordinary. The internet became work infrastructure. Email became a default collaboration path. IDEs became daily engineering workbenches. Cloud became normal for many teams. Java became a practical business platform for large systems. AI will follow the same pattern only where leaders do the hard work of trust building.
The goal is not to make the team less skeptical. The goal is to make the change worthy of their trust.