HyperTeamsChange management
What you will learn Why things stall on people rather than technology, what faces resistance wears, and how to survive the three to six months after rollout.
The half the roadmap does not write down
The previous four chapters covered how the work flows. But people do that work, and most failures happen here.
Published surveys agree on something consistently:
- A substantial share of AI projects fail at the scaling stage, and the main cause is change management, not algorithms.
- One survey attributed about 38% of adoption difficulty to user proficiency and about 16% to technical issues.
The figures differ by survey. But the direction — the people side is larger than the technology side — is common across many of them.
Spend 10 on technology and 1 on people and your allocation is the inverse of the causes.
Resistance does not arrive as opposition
Someone who says "I'm against this" is actually easy to handle — you can hear their reasons. Real resistance arrives like this:
| What is said | What is meant |
|---|---|
| "I'm too busy to attend the meeting" | I do not want to be involved |
| "Our work is a bit special" | do not touch my job |
| "Why not try another team first" | I would like to watch this fail |
| "We tried this before" | this will fizzle out again |
| (silence) | I am waiting for it to pass |
The last is the most common and the most dangerous. Nobody objected so you thought it was going well, and after rollout nobody uses it.
Three roots of resistance
graph TD
R1["Will my job disappear?"] --> A["Avoid cooperating"]
R2["Will I be able to keep up?"] --> A
R3["This will fizzle out again"] --> A
A --> B["Real information about the work never surfaces"]
B --> C["The wrong thing gets built"]
C --> D["Nobody uses it"]Root 1 — will my job disappear
The most direct fear. As covered in cost, the answer is saying where the freed time goes, first.
Words alone are not believed. Choosing a first project nobody wants to do proves it faster than any explanation.
Root 2 — will I be able to keep up
Especially strong among senior staff. The anxiety that the expertise they built becomes worthless.
This anxiety has a real basis. But the direction differs — what disappears is not the expertise but the place where that expertise was applied. Judgement becomes more important, not less. As we saw in things to watch out for, deciding whether an AI result is correct requires someone who knows the work.
For that explanation to land, you have to make that person the verifier. Not "this replaces your job" but "we need you to verify this" — and their position changes.
Root 3 — this will fizzle out again
Strong in organisations with a failed IT project behind them. And it is usually an accurate prediction — things really did fizzle out before.
Words do not work here. Only actually finishing one small thing works. The advice to keep the first project small lines up here too.
What to do
1. Tell a different story to each role
Broadcast the same content company-wide and it reaches nobody.
| Audience | What they want to know |
|---|---|
| Executives | what it costs, what comes back, what the risks are |
| Middle managers | how my team's work changes, and headcount |
| Practitioners | how my job changes, what I need to learn |
| IT | what we have to do, and security |
Explain ROI to a practitioner and it sounds like "so you're cutting people."
2. Put the people affected into the design
The single highest-impact action. When the person doing the work participates in the design:
- The real procedure and its exceptions surface (otherwise they blow up in POC)
- They stop being someone whose job is removed and become someone redesigning it
- After rollout they become the advocate
3. Treat the first 3–6 months as an intensive support window
Do not deploy and walk away. In this window, someone who gets stuck once and gives up does not come back.
4. Keep talking
One announcement is not enough. Announce results, announce improvements, announce what is next. The moment it goes quiet, "this is fizzling out again" is confirmed.
Watch especially — the half-life of skills
AI tools change quickly. Train once and the content no longer fits a few months later. Schedule training as a cadence, not an event.
Common misconceptions
"In our organisation people do what they are told."
Following instructions and cooperating are different. Instructions get people to the meeting; they do not produce "here's an exception in this work." Build without that information and it collapses at POC.
"Won't enough training fix it?"
Training works on root 2 (can I keep up) only. It does nothing for root 1 (will my job go) or root 3 (this will fizzle out). Those two are solved by action, not words — actually showing where the freed time went, and actually finishing one small thing.
Check yourself
1. What is the most dangerous form of resistance?
Answer
Silence. Nobody objected so you thought it was fine, and after rollout nobody uses it. Explicit opposition is easier to handle because you can hear the reasons.
2. Why does explanation not work against "this will fizzle out again"?
Answer
Because it is usually an accurate prediction. It comes from actual experience, so words do not overturn it. Only actually finishing one small thing does.
3. Why does explaining ROI to practitioners backfire?
Answer
Because it sounds like "so you're cutting people." What practitioners want to know is how their job changes and what they need to learn. Each role wants something different, so a single company-wide broadcast reaches nobody.
That is the adoption process. The next part is the footing for everything technical that follows — skip it if you already have that background → What your computer is doing right now