- In short
- The champion-per-department rollout pattern grants early access to one champion in each team or department, who converts a real workflow and becomes the first line of support before adoption spreads batch by batch. It contrasts with an all-at-once switch-on, which tends to produce confused first attempts and a quiet retreat to old habits. The champion role is ongoing mentoring, not a one-time personal adoption.
Why adoption is engineered, not announced
Team adoption of AI tooling rarely succeeds as a single all-hands switch-on. The Claude Certified Architect - Professional (CCAR-P) exam frames this as an understand-level skill because the wrong instinct - flip it on for everyone at once to move fast - is exactly the one the exam marks wrong. Adoption is something you engineer through structure, and the structure that works is a staged rollout led by a champion in each team or department.
The reason a mass switch-on fails is human, not technical. When everyone starts at the same moment with no local expert and no proven example, the result is a spike of confused first-time prompts, uneven early experiences, and no one nearby to unstick people. Many quietly conclude the tool does not fit their work and retreat to old habits before it ever had a chance to prove its value. The staged pattern removes that failure mode by making sure every group has a working example and a local expert before it starts.
- Champion-per-department rollout
- A staged adoption pattern where one champion per team or department gets early access, converts a real workflow into a working example, and becomes the first line of support, after which adoption spreads batch by batch. It contrasts with an all-at-once switch-on that tends to produce confused first attempts and a quiet retreat to old habits.
How the pattern runs
The champion in each department is granted access first. Their job is to convert a real workflow - a code-review assist, a test-generation step, something the team already does - into a working example, absorbing the early friction so their peers do not have to. In doing so they also tune the shared baseline, so the team's CLAUDE.md and tool set arrive already fitted to how that department actually works.
Once the champion has a working local example, adoption seeds outward in batches. The champion runs a short onboarding session for their first batch of peers, who now start with a proven workflow, a local expert to ask, and a tuned configuration instead of a blank slate. Each batch strengthens the next, and the Architect is not the only person who can answer questions - the champion is the first line of support inside the team.
The champion's job does not end at personal adoption
A common misreading is that the champion's role finishes the moment they themselves are productive. It does not. Their ongoing job is mentoring the next batch: running the onboarding, keeping the shared configuration current, and fielding the questions that would otherwise all land on the Architect. If the champion stops once they personally adopt the tool, the pattern collapses into a single power user and the rest of the department never gets the working example and local support the pattern is designed to provide.
What the CCAR-P exam trips candidates on
Two traps recur. The first is choosing a mass simultaneous rollout across all departments as the fastest path to adoption. It looks efficient - one action, everyone enabled - but the exam marks it wrong because it maximizes confused first attempts and minimizes local support. The credited answer almost always stages the rollout through champions and batches, even when the scenario pressures you toward speed.
The second trap is assuming the champion's role ends once they personally adopt the tool. A scenario may describe a champion who is now highly productive while the rest of the department barely uses the tooling, and ask what went wrong. The point is that the champion stopped at their own adoption instead of mentoring the next batch; the fix is to restore the mentoring role, not to pick a new champion or add training for everyone at once.
Worked example
A 200-person engineering org wants Claude Code across four departments and wants it fast. The VP proposes a single company-wide enablement email on Monday. The Architect pushes back. What rollout should the Architect propose instead, and why?
The company-wide email is the all-at-once switch-on the pattern exists to avoid. On Monday morning, 200 people would open the tool at once with no proven workflow, no local expert, and no tuned configuration. The predictable outcome is a wave of confused first-time prompts, wildly uneven early experiences, and a large fraction of people concluding it does not fit their work and going back to how they worked before. Speed on paper becomes a stalled rollout in practice.
The Architect proposes a staged rollout instead. Enable one champion in each of the four departments first. Give each champion about two weeks to convert a real workflow - a code-review assist, a test-generation step - into a working example, tuning the department's shared CLAUDE.md as they go. Then have each champion run a short onboarding session for a first batch of about five peers, who now start with a proven example, a local expert, and a configuration already fitted to their work.
By the time the broad rollout reaches everyone, every department has a working example, a local expert, and a tuned baseline. The champions keep mentoring the following batches, so support scales with adoption rather than all funneling back to the Architect. It feels slower for the first two weeks and is dramatically faster to real, sustained adoption - which is the outcome that matters.
Common misreadings to avoid
Misconception
Enabling everyone at once is the fastest way to get a team adopting AI tooling.
What's actually true
Misconception
A champion's job is done once they personally start using the tool.
What's actually true
How this shows up on the exam
Domain 7 questions on this knowledge point describe an org planning a rollout, or a rollout that stalled, and ask for the best next move. The reliable pattern is champions first, then batches: prove the workflow locally, seed outward, keep the champion mentoring. Watch for the tempting mass switch-on distractor - it is there specifically to be rejected.
This knowledge point builds on the shared team environment baseline, since the champion is the person who tunes that baseline for their department, and it connects directly to the adoption failure modes of lumpy adoption and chat-stalling, because deliberate staged rollout is the direct countermeasure to usage concentrating in a few early adopters. Engineer the rollout and you avoid both failures at once.
A company wants Claude Code across four departments and adoption is currently uneven. What is the best next move?
People also ask
What is the champion-per-department rollout pattern?
Why not roll AI tooling out to everyone at once?
What does a champion do after they adopt the tool?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.