Champion-Per-Department Rollout: Adoption as an Architecture Problem

Everything so far in this task statement -- CLAUDE.md, settings.json, shared MCP servers, team Skills -- assumes the team is actually going to use Claude Code once it's configured correctly. That's not automatic. An architect who gets every configuration surface right can still watch adoption fail, because rolling out a new tool to an organization is its own design problem, with its own well-understood failure modes, separate from getting the tool itself configured correctly.

The Pattern: One Champion, Then Peer-to-Peer

The rollout pattern that avoids the most common failure modes is: designate ONE CHAMPION per department or team, who receives deep onboarding first -- real hands-on time, real use cases from their own work, enough depth to become genuinely fluent rather than just aware. That champion then runs PEER-TO-PEER adoption sessions for their own team, in small batches, rather than the organization defaulting to a single company-wide training blast that gives everyone the same shallow hour and calls it done.

The reasoning behind small-batch, peer-led sessions over one company-wide blast is about who's actually delivering the material. A company-wide session is usually run by someone from outside the team (a vendor, a central enablement group) using generic examples, to an audience with wildly different daily workflows -- a backend engineer and a frontend engineer get the identical generic demo, neither sees their own real workflow addressed, and most of the room mentally checks out within the first fifteen minutes. A champion who already knows the team's actual codebase, actual pain points, and actual daily friction can make the same hour concretely relevant to the six or eight people in the room, adjusting live to which real task the group actually cares about.

A Worked Example: A 60-Person Engineering Org

Consider a 60-person engineering org split into three teams: Platform (22 engineers), Product (25 engineers), and Data (13 engineers). Rather than one all-hands training session, the rollout looks like:

• Week 1: One champion per team (3 people total) gets a half-day, hands-on onboarding session run by the architect directly -- working through that champion's own team's real recent PRs and real recurring pain points, not generic examples.
• Weeks 2-4: Each champion runs three 90-minute peer sessions with their own team, in batches of 7-8 people (Platform: 3 batches of ~7; Product: 3 batches of ~8; Data: 2 batches of 6-7) -- small enough that everyone in the room gets hands-on time with their own real code, not a lecture.
• Week 5: Champions reconvene with the architect to compare what worked, what stalled, and which agentic/Skill-based workflows their teams actually adopted versus which ones landed flat -- feeding directly into what CLAUDE.md conventions and team Skills (7.1.2, 7.1.5) get written up next.

By week 5, all 60 engineers have had genuine hands-on exposure to real work in their own codebase, delivered by someone who already has credibility on that team -- not sixty people who sat through the same generic 45-minute demo in week 1 and never opened Claude Code again.

The Two Failure Modes This Pattern Avoids

• LUMPY ADOPTION -- a few enthusiastic individuals go deep on their own initiative, exploring every feature, while most of the org never meaningfully engages past the initial announcement. Six months later, usage data shows three power users generating the overwhelming majority of activity, and everyone else still hasn't touched it since the kickoff email.
• STALLING AT BASIC CHAT -- teams adopt Claude Code as a slightly-smarter search box ("explain this function," "what does this error mean") and never progress to the agentic, Skill-based workflows that deliver the real productivity gain (multi-step autonomous tasks, custom Skills, CI-integrated agents). The tool gets credit for being marginally useful while the actual leverage -- the reason an architect bothered rolling it out at scale -- never materializes.

A single company-wide blast tends to produce both failure modes at once: the people who were already inclined to explore go deep on their own (lumpy adoption for everyone else), and the shallow, generic content that reached everyone else teaches chat-style usage and nothing about the deeper agentic workflows, so that's where those people's usage permanently plateaus.

Common exam traps

• Treating rollout as purely a training-logistics question rather than an architecture decision. A scenario describing a single all-hands session as the adoption plan, with no mention of champions or peer-led follow-through, is describing the setup for lumpy adoption and stalling at basic chat -- the correct fix names the champion-per-department pattern specifically, not "more training" in the abstract.