What 700 trained engineers taught me about adoption

After training more than 700 practitioners across SIA, Maybank, Prudential, and Manulife, the lesson is consistent: AI adoption is a behaviour change, not a tooling rollout. The teams that stick with it are not the ones with the best tools, they are the ones who practised on real work, in role-specific tracks, with internal champions who kept the momentum after the training ended.

Generic training does not transfer

Slides about prompting do not change behaviour. Exercises built on the team’s own codebase do. The single biggest predictor of whether a cohort kept using AI was whether the training used their real work instead of toy examples. People adopt what they have already used successfully under realistic conditions.

Roles need different tracks

An engineer, a tech lead, and a product owner use AI for different things. Training them in one undifferentiated session means everyone gets material that is half-relevant. Role-specific tracks, each grounded in that role’s actual tasks, dramatically outperform the one-size session.

Champions, not mandates

A mandate from leadership gets compliance during the workshop and reversion the week after. An internal champion (a respected peer who uses AI well and helps others) sustains the change. I deliberately grow these champions during every engagement, because they are what keeps adoption compounding for the long run.

What this means for you

If your AI rollout is a tool announcement plus a generic workshop, expect a spike and a fade. If it is role-specific practice on real work with champions seeded inside the team, expect durable change.

This is the heart of enablement & training. See also why AI pilots stall before production and the speaking page for the workshops behind these numbers.