What predicts whether an AI cohort actually sticks
Across 700+ practitioners, durable AI adoption tracks three predictors: training on their own codebase, role-specific tracks, and internal champions seeded in the team.
After training 700+ practitioners across SIA, Maybank, Prudential, Manulife and Chanel, spanning aviation, banking, insurance, fashion and beauty, the pattern is clear enough to predict: a cohort sticks when three things are present and fades when they are not. Training happens on the team’s own codebase, not toy examples. The tracks are role-specific, not one generic class. And internal champions are seeded inside the team so the practice survives after the trainer leaves. Where those three show up, adoption is durable. Where they are missing, the skills evaporate within weeks no matter how good the sessions felt on the day. This is a deeper cut than what 700 trained engineers taught me about adoption, focused on the predictors rather than the headline.
Why does training on the real codebase matter so much?
Because the gap between a tutorial and a developer’s actual repo is exactly where adoption dies. A demo on a clean example app teaches someone that AI works in general. It does not teach them that it works on their gnarly legacy service with its undocumented conventions and twelve years of history. The moment they hit the messy reality and the toy lesson does not transfer, they quietly stop.
When the training runs on the team’s own code, the gap closes during the session, not after it. People see AI handle their actual patterns, their actual build, their actual review process. They leave with proof it works on the thing they will touch tomorrow, which is the only proof that changes behaviour.
Why role-specific tracks instead of one class?
Because a backend engineer, a QA lead, and a tech lead do different work and need different things from AI, and a generic class serves none of them well. The backend engineer wants help in the codebase. The QA lead wants help generating and triaging tests. The tech lead wants to reason about architecture and review. Put them in one room with one curriculum and most of it lands as theory for most of the audience.
Role-specific tracks make the value concrete for each person. Concrete value is what gets practised after the session, and practice is what makes a skill stick. This is why enablement that takes role seriously consistently outperforms a single broadcast workshop.
What do internal champions actually do?
They carry the practice after the trainer is gone, which is the whole game. A workshop is a moment. Adoption is a habit, and habits need someone inside the team to answer the small daily questions, model the workflow in real pull requests, and keep momentum alive when the schedule gets tight. Seed two or three champions during the engagement and the cohort has gravity. Skip it and the practice has no anchor, so it drifts back to the old way the first busy week.
Why adoption has to lift the whole squad, not one person?
Because adoption has to lift the entire delivery flow, not one stage of it. A squad is a system. If only one part of it gets the productivity gain, the rest becomes the bottleneck and the gain is lost. A developer who ships twice as fast into a saturated review or QA stage does not double the squad’s output. They just grow the queue in front of the next stage. The work moves faster up to a wall and then waits.
So you optimise the squad as a system, not the individual. The goal is throughput across the whole pipeline, which means the slowest stage sets the pace no matter how fast any single stage runs. Real adoption means every role in the squad moves together: dev, review, QA and release all get faster at once, so the flow stays balanced and the speedup actually reaches production.
The strongest cohorts I have worked with had all three predictors in place, and their productivity gains held rather than spiking and decaying. That is the difference between a memorable training day and a permanent change in how a team builds. If you want the field notes behind these patterns, I cover them in talks and workshops listed on my speaking page, and the way I structure engagements around these predictors is the core of how I run enablement.