Adoption is a behaviour change, not a tooling rollout
Tools do not change behaviour, practice does. A launch plus a generic workshop spikes then fades, while role-specific practice and champions make adoption durable.
The single mental model behind every successful AI enablement programme I have run is this: tools do not change behaviour, practice does. Announcing a tool and bolting on a generic workshop produces a usage spike that fades within weeks. Role-specific practice on real work, reinforced by internal champions, produces change that sticks. The difference is not the tool. It is what you do after the tool arrives.
Across more than 700 practitioners trained at organisations like SIA, Maybank, Prudential, and Manulife, the pattern is consistent enough to be a law. The teams that achieved durable 2 to 3x productivity gains did not have better licences. They had better habits, built deliberately.
Why does a tool rollout spike then fade?
A rollout treats adoption as a distribution problem: get the tool to everyone and the value follows. It does not. People try the tool during the buzz, hit friction on their actual work, and quietly revert to the workflow they already trusted. The usage chart spikes on launch day and decays back to baseline by the end of the month.
A generic workshop makes this worse, not better. It shows a developer and a compliance analyst the same toy example, neither of which resembles their Monday morning. Everyone nods, nobody changes, and leadership concludes the technology underdelivered when the enablement was the part that failed.
What actually changes behaviour?
Practice on real work. Not a sandbox, not a demo dataset, but the developer’s own pull request and the analyst’s own report. When someone uses a new tool to finish a task they were already going to do, the new approach competes directly with the old habit and wins on the merits. That is when behaviour shifts, because the person has lived proof it is faster for their work.
This is why enablement has to be role-specific. The prompt patterns that help an engineer refactor are not the ones that help a risk analyst summarise a filing. Teach each role the moves that apply to their day, and the lesson survives contact with reality.
Why do internal champions matter so much?
Champions are how a habit outlives the workshop. An external trainer leaves on Friday. A champion sits two desks away and answers the awkward question on Tuesday, when the friction would otherwise send a colleague back to the old way. They translate general capability into your team’s specific context, tools, and codebase.
Champions also carry social proof that no external voice can. When a respected peer says this changed how I work, that lands harder than any slide. Picking and supporting champions is the highest-leverage move in any rollout, which is why I treat it as core to the 700-engineer adoption work, not an afterthought.
How do you design for durability from the start?
Stop measuring launch-day usage and start measuring usage in week eight. Build the programme backwards from the habit you want, give each role real tasks to practise on, and name champions before training begins so the support structure exists on day one.
That reframing is the whole job: adoption is a behaviour-change programme that happens to involve a tool, not a tool rollout that happens to involve people. I cover this in more depth when I speak on enablement, but the headline never changes. Buy the tool in an afternoon. Earn the behaviour over a quarter.