What predicts whether an AI crew actually sticks
Across 700+ practitioners, durable AI adoption tracks three tells, choom: training on their own codebase, role-specific tracks, and internal champions seeded in the crew.
After training 700+ practitioners across SIA, Maybank, Prudential, Manulife and Chanel, spanning aviation, banking, insurance, fashion and beauty, the pattern is clear enough to call ahead of time: a crew sticks when three things are present and fades when they are not. Training happens on the crew’s own codebase, not toy examples. The tracks are role-specific, not one generic class. And internal champions, your seeded netrunners, get chipped into the crew so the practice survives after the trainer deltas. Where those three show up, adoption holds like preem chrome. Where they are missing, the skills evaporate within weeks no matter how nova the sessions felt on the day. This is a deeper cut than what 700 trained engineers taught me about adoption, zeroed in on the tells rather than the headline.
Why does training on the real codebase matter so much?
Because the gap between a tutorial and a dev’s actual repo is exactly where adoption flatlines, choom. 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, a real borg of a codebase. The moment they hit the messy reality and the toy lesson does not carry over, they quietly stop.
When the training runs on the crew’s own rig, the gap closes during the session, not after it. People see AI handle their actual patterns, their actual build, their actual review process. They walk out 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 crew, a gonk way to spend eddies.
Role-specific tracks make the value concrete for each choom. 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 outruns a single broadcast workshop.
What do internal champions actually do?
They carry the practice after the trainer is gone, which is the whole game, choom. A workshop is a moment. Adoption is a habit, and habits need a samurai inside the crew 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 crew has gravity. Skip it and the practice has no anchor, so it deltas back to the old way the first busy week.
Why adoption has to lift the whole squad, not one choom?
Because adoption has to lift the entire delivery flow, not one stage of it. A squad is a system, a crew that runs together. If only one part of it gets the productivity gain, the rest becomes the bottleneck and the gain is lost. A dev 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 lone merc. 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 crew 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 crews I have worked with had all three tells locked in like chrome, 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 crew builds, choom. 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 tells is the core of how I run enablement.