AI champion per team

An AI champion per team is a senior or staff engineer who takes on informal or formal ownership of making AI tooling work for their specific team. They are not the "AI enthusiast who has a blog" - they are the person who writes the CLAUDE.md file, discovers which agent tasks work well in their codebase, trains their colleagues on effective prompting, and escalates blockers to the platform team when infrastructure is missing. One champion per team is the organizational structure that makes L2 maturity real rather than aspirational.

The champion role emerges naturally in most organizations before it is formalized. There is almost always one developer per team who experimented first, who has the most sophisticated AI workflow, and who other team members ask for help when their agent does something unexpected. Formalizing this role - giving the champion time allocation, recognition, and a community of peers across teams - is the L2 organizational intervention that converts informal experimentation into systematic progress.

The champion is distinct from the "AI committee" or centralized AI team that some organizations create at L2. Those centralized structures produce policy and tooling standards but don't translate into effective daily practice at the team level. The champion is embedded in the team, knows the codebase, knows the culture, and can demonstrate effective AI use in the team's actual context rather than a synthetic demo environment. Centralized AI programs without team-level champions typically produce high adoption rates on paper (tools installed) and low adoption rates in practice (tools used effectively).

The champion role at L2 is a temporary structure on the way to L3. At L3, the context engineering work the champion was doing becomes a formal role, and the AI practices the champion developed become team standards enforced through tooling. But at L2, the champion is how the team makes the leap from "some individuals use AI tools" to "the team has a coherent approach to AI-assisted development." That leap requires a person, not just a policy.

The champion structure delivers specific organizational outcomes that no other L2 intervention achieves:

• Translates generic AI advice into specific practice - "use AI for tests" is generic; "for our Django codebase, use this prompt pattern for model tests because our fixtures work like X" is actionable; only a team-embedded champion can produce the specific version
• Reduces the learning curve for every team member - each developer who benefits from the champion's expertise skips 3-4 weeks of personal trial-and-error; in a team of eight, this is 24-32 developer-weeks saved
• Creates a feedback loop between teams and platform - champions identify what's missing at the infrastructure level (MCP servers, context tooling, shared CLAUDE.md components) and communicate it to the platform team; without champions, the platform team is guessing
• Provides visible social proof - when the team's most respected engineer openly uses AI tools and talks about what works, it creates permission for others to invest in learning; when that engineer is skeptical and silent, AI adoption stagnates
• Builds institutional knowledge before it's needed - teams that invest in champions at L2 are not starting from scratch when the organization moves to L3 mandatory practices; they already have the workflows, the documentation, and the experience

1. Identify the organic champion - before formalizing anything, identify who is already acting as the informal AI resource on each team. Ask: "Who do people go to when they have questions about AI tools?" That person is your champion candidate. Formal designation of a willing organic champion is more effective than appointing someone who hasn't self-selected into the role.
2. Allocate dedicated time - 10-15% of the champion's time (roughly 4-6 hours per week) should be explicitly designated for AI champion activities. This protects the work from sprint pressure and signals organizational seriousness. Without time allocation, champion activities will always lose to feature delivery pressure.
3. Create a champion community - if you have multiple teams, the per-team champions should meet regularly (weekly or biweekly) to share what's working, what's failing, and what infrastructure gaps they've discovered. This community accelerates learning across teams and prevents each champion from solving the same problems independently.
4. Define the champion's deliverables - at minimum: an up-to-date CLAUDE.md for the team's codebase, a library of 10-15 effective prompt templates for common team tasks, and a monthly summary of AI adoption progress. These deliverables make the champion's work visible and give the champion a clear scope.
5. Give champions access to platform team - AI champions need a direct channel to the platform or DevEx team to escalate infrastructure blockers. When a champion discovers that agents can't access the internal package registry because of authentication configuration, they need to be able to raise that blocker and expect it to be resolved quickly. Without this channel, champions hit walls and lose momentum.
6. Celebrate champion contributions in team retrospectives - when the champion's CLAUDE.md update leads to fewer agent errors, name it. When the champion's prompt template saves the team time, quantify it. This recognition reinforces the investment and makes the champion role visible to people who might become champions on other teams.

Choosing champions for enthusiasm rather than credibility. The most enthusiastic person about AI tools is not always the right champion. If they lack credibility with the team - because of seniority, track record, or interpersonal dynamics - their recommendations won't be followed. The champion needs to be someone whose judgment the team trusts on technical matters, whether or not they are the most enthusiastic about AI.

Not protecting champion time. Champion activities look optional in sprint planning. They produce long-term value but are hard to include in story point estimates. Sprint pressure will consistently crowd them out unless the time is explicitly protected. Champions who are perpetually behind on their "day job" because they're doing champion work will burn out and stop.

Treating the champion as the team's AI helpdesk. A champion who spends all their time answering individual questions and debugging other people's AI issues is not building systemic capability - they're a support function. The champion's job is to create documentation, templates, and training that scale. Individual support is fine as a starting point, but it should convert into shared resources quickly.

Letting champion knowledge stay in the champion's head. When a champion figures out an effective approach, that knowledge needs to be documented and shared. Champions who are the only person who knows how to do something effectively create a single point of failure and don't scale the organization's capability. The champion role is a knowledge-creation and knowledge-distribution function, not just a personal capability function.

Running champions without organizational commitment. Champions need to believe that the organization is genuinely committed to AI adoption, not just testing the waters. If the champion invests time in building context infrastructure and then hears that the AI tools budget might be cut, the investment doesn't make sense. Organizational commitment - communicated credibly by leadership - is a prerequisite for effective champions.