Episode #12: The 4 forces behind tech adoption
Why users resist, where adoption breaks down, and what leaders can do early to protect ROI.
Go-live is a milestone. Adoption is the business result.
That distinction matters more than many IT leaders admit. A system can launch on time, training can be completed, and the dashboard can look green in week one. Then hypercare ends, local pressure returns, workarounds creep back in, and the investment starts losing value quietly in the background. That is the real risk: not technical failure, but post-launch erosion of usage, process discipline, and ROI.
Tech adoption does not succeed because a system is live. It succeeds when people use it consistently, correctly, and long enough for the business value to materialise. In practice, that depends on four forces: the technology itself, the individual user, the social environment around the user, and the wider organisational system around the change.
Each of these forces can either support adoption or weaken it. For CIOs, ERP leads, and transformation leaders, the implication is clear. Low adoption is not just a usage issue. It drives support costs, weakens data quality, extends the path into business as usual, and puts both program ROI and leadership credibility at risk.
Go-live does not protect value
One of the biggest mistakes in large IT programs is to treat go-live as proof of success. It is not. Early login activity, training completion, or short-term compliance under close scrutiny do not tell you whether the new system has actually landed in day-to-day work.
The real test comes later. When dedicated support starts to fade, when attention moves to the next priority, and when local teams are left to make the new way work under real business pressure, adoption either holds or starts to slip. That is when old habits return, workarounds reappear, and users quietly drift back to familiar behaviours.
This is where ROI starts to erode. Not because the technology failed, but because the surrounding conditions for sustained adoption were never strong enough. A program may be technically ready and still be weak on user readiness. It may have the right architecture and the wrong behaviour on the ground. It may have delivered the system and still not have secured the result.
For senior IT leaders, this is not a communications detail. It is a delivery issue. If adoption is fragile, business value is fragile too.
The four forces behind tech adoption
1. The technology force
The first force is the user experience of the system in real work. Not whether the solution works in principle, but whether it feels useful, manageable, and credible in practice.
This matters especially in ERP and S/4HANA programs. Many legacy environments were shaped over years around local exceptions, manual fixes, and highly familiar shortcuts. A more standardised environment may be strategically right, but still feel less flexible to the people expected to use it every day. From a programme perspective, the new system may represent simplification. From a user perspective, it may feel like capability has been taken away.
That gap matters. Users do not compare the new solution with the target operating model. They compare it with the old reality they know. If the new system feels harder, slower, or less intuitive at the moment they first encounter it, resistance triggers start early.
This is why honest expectation-setting matters. Leaders need to explain what will improve, what may feel harder at first, and why the change is still necessary. They also need to make the future tangible early through demos, hands-on exposure, and realistic previews of the new experience. Adoption improves when people can picture what is coming and why the trade-offs make sense.
2. The individual force
The second force is the individual reaction to change. Every user makes a fast assessment, often before they say anything openly. Will this help me? Will it slow me down? How hard will this be to learn? What do I lose if the old way disappears?
This is where behavioural science becomes useful in plain terms. People do not push back only because they lack information. They push back when a change threatens competence, certainty, control, or status. In tech programmes, that happens more often than leaders realise. A person who was confident and efficient in the old environment can suddenly feel inexperienced in the new one. A local expert can lose informal influence. A manager can worry about short-term disruption more than long-term transformation value.
These concerns are rarely voiced in a clean or rational way. They show up as delay, low engagement, avoidance, scepticism, or surface-level agreement without real follow-through.
That is why adoption cannot be treated as a pure training exercise. Training is necessary, but not sufficient. Leaders also need to shape belief, reduce uncertainty, and support the transition from understanding to action. A useful rule is to think in three layers: head, heart, and hands. People need a clear reason to change, confidence that the change is manageable, and practical support to use the system when daily pressure returns.
3. The social force
The third force is the environment around the user. Adoption is social. People look sideways before they commit. They notice what their manager rewards, what respected peers do, and what local influencers say when the project team is not in the room.
This matters because users rarely make adoption decisions in isolation. If their team leader still relies on old reports, if experienced colleagues keep bypassing the new workflow, or if the most credible local voice treats the rollout as a burden, those signals spread fast. In those conditions, formal communication has limited power.
The opposite is also true. When visible peers adopt early, when line managers reinforce the new behaviour consistently, and when local champions are credible rather than symbolic, the norm starts to shift. The new way becomes more socially accepted, and the cost of staying with the old way increases.
That is why stakeholder engagement needs to go beyond broadcast messaging. Leaders need to identify who shapes opinion locally, where visible behaviour matters most, and how to make progress tangible. Recognition can help when it is tied to actual behaviour. Early examples of teams using the system well can reduce uncertainty and signal that the new standard is real.
The point is simple: adoption spreads through social proof faster than most programmes plan for.
4. The system force
The fourth force is the broader organisational system in which the change lands. This includes KPIs, incentives, reporting lines, workload, support structures, escalation paths, and whether old alternatives remain available.
This is often the most important force because it determines whether the organisation truly requires the new behaviour. If leaders say the new system matters, but local targets still reward old ways of working, users receive mixed signals. If teams are overloaded and short-term delivery pressure remains untouched, the easiest workaround will win. If legacy tools stay open indefinitely, many users will keep one foot in the past.
In that situation, weak adoption is not a people problem. It is a system design problem.
This is why adoption must be reinforced by operating conditions, not just expectation-setting. Metrics need to align with the new way of working. Support must be accessible and practical. Managers need to know what is expected of them, not just what is expected of users. Escalation paths need to exist for issues that stall local adoption. And at the right moment, the old route needs to become harder than the new one.
Without that alignment, a programme may achieve launch and still fail to stabilise. Plateau is then predictable rather than surprising.
What IT leaders should do with this
The value of the four-force model is not that it sounds neat. The value is that it gives IT leaders a sharper way to steer adoption before problems become expensive.
Instead of waiting for weak usage after go-live, leaders can assess where the friction is building earlier. Does the system feel credible in real work? Are hidden concerns being surfaced or ignored? Are local norms helping or hurting? Do KPIs, support, and leadership signals reinforce the new behaviour, or quietly undermine it?
Those are not abstract questions. They are practical early warning signs. And they can be managed.
This is where many programmes go wrong. They focus heavily on build quality, cutover readiness, and training plans, then treat adoption as something that should naturally follow. But adoption does not naturally follow. It follows when the surrounding conditions are designed for it.
For CIOs and programme leaders under pressure to show ROI, that is the discipline that matters. Sustainable usage. Reduced workarounds. Stronger data quality. Shorter support tails. Faster stabilisation into business as usual. Better credibility for the programme and the leadership behind it.
That is what good adoption work protects.
Key Takeaways: What IT Leaders Should Remember
Go-live is not proof of adoption.
User readiness is different from technical readiness.
Hidden concerns often surface as delay, avoidance, or low engagement.
Social norms shape adoption faster than formal messages.
If the system around the rollout stays misaligned, ROI will suffer.
About your host
Arne Kötting founded COSYN after years of seeing organisations struggle with the human side of tech change. He built the Change Playbook to codify what actually works based on 20 years of watching these patterns.
The Change Playbook is designed for IT program teams to confidently manage the human side of tech change in-house, without expensive consulting dependencies.
His conversational style cuts through complexity to reveal the fundamental principles that make tech change communication work - principles you can apply 1:1 to your own transformation challenges.
Get in touch
More podcast episodes from
a Change in Conversation
