The champion model: how agent adoption sticks

Every stalled agent rollout we get called into has the same shape. An outside team (consultants, a platform squad, sometimes an energetic CTO) runs a strong pilot. Usage climbs, the demos land, the engagement ends. Three months later, usage has collapsed back to the two engineers who would have adopted the tools anyway. The practice left with the people who carried it.

The fix that holds is unglamorous: name an AI champion in each engineering team, and give the role real, protected time. Not a center of excellence, not a task force, not a Slack channel. A person in the squad.

Why one champion per squad beats a central AI team

A central AI enablement team produces guidelines, and guidelines do not transfer practice. What transfers practice is someone at the next desk who ships the same backlog, knows this codebase’s traps, and can look at your screen when the agent goes sideways. Proximity is most of the value: the champion sees where teammates actually get stuck, not where a quarterly survey says they do.

Credibility is the rest. Engineers discount advice from people who do not share their constraints. A champion who shipped a feature on the same legacy module last sprint cannot be waved off the way a central team can.

The feedback loop closes faster too. When a workflow trick works, the champion turns it into a shared skill the same week. When something breaks, whoever maintains the toolchain hears about it in days. Central teams learn these things a quarter late, from surveys.

How to pick them

The obvious pick is the loudest enthusiast, and it is usually wrong. The best champions we have seen share three traits: teammates already ask them questions, they are patient with people slower than themselves, and their standing comes from shipped work rather than opinions. Enthusiasm for the tools matters less than trust inside the team.

Ask for volunteers, then filter on those traits, one champion per squad of six to ten engineers. And do not rule out a converted skeptic: a respected engineer who adopted the tools reluctantly and can say precisely where they disappoint is more persuasive than any believer. Your skeptical seniors are often the strongest candidates on the list.

What a champion owns

The role needs a concrete perimeter, or it dissolves into vibes:

• The squad’s context files and skill library, kept current and reviewed like code.
• First response for workflow questions, so nobody loses a day to a config problem.
• Onboarding: every new joiner pairs with the champion on the toolchain in week one.
• Upstream feedback: what works locally gets contributed to the shared library, what fails gets reported with a reproduction.
• A monthly look at what the squad still does by hand that it could delegate.

Just as important is what they do not own: policy, procurement, or other people’s adoption numbers. A champion carrying targets becomes a salesperson, and the squad smells it immediately.

The time budget that makes it real

A champion needs 10 to 20 percent of their time, protected and visible in sprint planning. This is the part organizations refuse, and it is why the model fails when it fails. Unprotected champion time loses to sprint pressure every single week, the skill library goes stale, and within a quarter the role is a title on a slide. Priced against the alternatives (a standing consultant retainer, or the adoption gap between your two fluent engineers and the other ten) half a day a week is one of the cheapest line items in the whole program.

The signs it is working

Healthy signals: skills get committed by people who are not champions. Questions in the shared channel get more specific over time, from "how do I start" to "how do we handle this migration pattern". Usage spreads past the early adopters into the middle of the team, which is where rollouts are won or lost.

Failure signals: the champion does the work for teammates instead of teaching them, which creates a proxy user and a bottleneck. The library’s last commit is six weeks old. The adoption numbers still map to the same two names they did in month one.

The champion model is the exit strategy of a rollout done properly: outside help should be building its own irrelevance from day one. It is how we structure the final phase of our agentic engineering engagements, because the real test of the work is what is still standing a year after we leave.