Adoption spreads through peer networks
Adoption spreads through peer networks rather than mandates: practice travels between people who work together, along the relationships that already exist, and a directive from above does not move it.
- 2-3 pilot teams are designated with explicit AI adoption goals
- Adoption spreads through peer advocacy rather than a mandate, and the org can show where it spread
- Pilot metrics are defined and tracked (adoption rate, usage frequency, developer satisfaction)
- Pilot results are shared with the broader organization
- Champion has direct access to leadership for escalation
- Pilot team designation document with goals and success criteria
- Champion role assignment with time allocation
- Pilot metrics dashboard showing tracked KPIs
What It Is
Adoption spreads through peer networks rather than mandates. Practice moves between people who work together - the colleague in the same codebase, the person who reviewed your last pull request, whoever sits in your team's standup - and it travels along those relationships rather than down the org chart. A directive from above does not move it. It moves licence counts, install rates and attendance at the enablement session, all of which can rise while nothing about how anyone works has changed.
The reason is not that engineers are contrarian. It is that the useful unit of knowledge here is specific and local. "Use AI for tests" transfers nothing. "For this service's fixtures, this prompt shape works and this one loops forever" transfers a great deal, and only a peer in the same codebase possesses it. Mandates can distribute the generic version, which is the version nobody needed; peers distribute the specific one, which is why adoption maps onto working relationships rather than reporting lines.
What travels along the network is not enthusiasm either. Every deployment has enthusiastic users, and enthusiasm on its own produces noise rather than adoption. What propagates is a demonstrated, reproducible workflow in a context the observer recognises as their own, delivered by someone whose technical judgement they already trust. That is a much narrower channel than a broadcast, and it is the only one that works.
Champions are how the network gets seeded. Victor, the Staff Engineer AI Champion archetype in this model, is not the mechanism of spread; he is a well-connected node in it. He has real expertise rather than enthusiasm, a belief grounded in his own experience, and the credibility to be trusted by peers - which is what makes practice move when it passes through him. He is not the person who sends excited Slack messages. He is the person developers go to when they want to know whether a particular workflow is worth trying.
How that person is defined, named and funded is a separate question, and it belongs to Team Structure & Roles: what the role covers, how much time it gets, how it appears in a performance review. This guide takes the champion's existence as given and asks the adoption question instead - how practice gets from that person to the twenty who have not tried anything yet, and why it stops at some team boundaries and crosses others.
At L2 (Delegated), spread is mostly organic and uneven: it follows whoever happens to be well connected, and it reaches the teams adjacent to a champion while stopping dead at the ones that are not. At L3 (Systematic), the paths are deliberate - practices are captured in a form that can travel without their author, and champions are connected to each other so that what one team learns reaches the rest. At L4 and L5 the network is the structure, and a platform group maintains the paths rather than carrying the knowledge itself.
Why It Matters
- Solves the last-mile adoption problem - tool access is not tool adoption, and the gap between them is closed by a peer answering the specific question that is blocking someone's first real win, not by an announcement that the licences are available
- Creates trust that vendor materials cannot - a recommendation from someone in the same codebase, under the same constraints, carries weight that no vendor case study or executive mandate can manufacture
- Mandates buy compliance, networks buy practice - a directive reliably moves the metrics leadership can see (seats, installs, training completion) and reliably fails to move the one that matters, which is whether anybody's working day is different
- Accumulates and transfers institutional knowledge - the champion is the living repository of what works in your specific environment; without one, every developer reinvents the wheel independently
- Provides early warning on adoption problems - people embedded in teams see the ground truth that usage dashboards do not capture: which workflows developers are quietly abandoning, where the friction is, and what is blocking those who have not had a win yet
- The gaps in the network predict the gaps in adoption - teams with no connection to anyone already practising will not pick it up by osmosis, however good the tooling is, and they are identifiable in advance
- Makes the pilot structure viable - pilots without champions follow the same arc as unstructured deployments; the champion is what makes a pilot genuinely different from just buying fewer licenses
Getting Started
-
Seed where the network already is - Start with the people others already ask for technical advice, not with the people who volunteer fastest or with the teams that are most convenient to schedule. Practice spreads along existing trust, so the question is not who is keenest but whose recommendation other engineers already act on.
-
Make the spread visible rather than the tooling - Demonstrations of a real workflow on the team's own code, in front of that team, are the transmission event. Generic enablement sessions, recorded webinars and vendor material reach everyone and convince nobody, because they cannot contain the specific thing that transfers.
-
Map who is connected to nobody - List your teams and, for each, name the person they would ask. Teams that cannot name anyone will not be reached by diffusion, no matter how long you wait. They need a deliberate connection - a rotation, a pairing, an embedded engineer - rather than another reminder that the tools are available.
-
Build a knowledge artifact as the first deliverable - Ask the champion to produce, within the first 30 days, a concrete knowledge artifact: a written guide covering three to five specific workflows, with examples from your actual codebase. This serves two purposes: it forces the champion to articulate what they know, and it creates the reusable documentation that scales their influence beyond 1:1 conversations.
-
Connect the seeds to each other - Where there are several champions, a shared channel or a regular sync turns isolated nodes into a network. Without it each one independently rediscovers the same things, and the organisation pays for the same learning as many times as it has teams.
-
Watch the shape of the spread, not just the total - Adoption that is high in aggregate can be three enthusiastic teams and eleven untouched ones, which is a different problem from an even 40% and needs a different response. Break every adoption number down by team before drawing any conclusion from it.
The best champions are not always the most senior engineers. Look for the developer who is most actively sharing what they're learning - in Slack, in code review, in informal conversations. That curiosity and outward orientation is more predictive of champion effectiveness than seniority.
Common Pitfalls
Reaching for a mandate when the network is slow. Diffusion feels slow from above, and the reflex is to require usage. What a mandate produces is measurable compliance and a quiet consensus that this is a thing being done to the team, which makes the peer channel harder to use afterwards. The honest options when spread is too slow are to seed more nodes or to connect the unconnected teams; requiring it is not a third option, it is a way of stopping measuring.
Reading tool metrics as adoption. Seats, installs and session counts all move under a mandate and all move without anybody's practice changing. If the only evidence that adoption is working comes from a licensing dashboard, you do not yet know whether it is working.
Choosing the champion based on enthusiasm rather than expertise. The most enthusiastic advocate for AI tools is not always the person with the deepest practical expertise. A champion who is enthusiastic but inexperienced will give confident advice that turns out to be wrong, eroding trust. The champion's credibility depends on their accuracy, not their energy.
Letting the network reduce to one person. If every question funnels to one individual, you have a helpdesk rather than a network, and it stops the moment they take a holiday. Spread is working when the people the champion helped start answering each other, which means success looks like the champion being asked fewer questions over time, not more.
Assuming spread continues on its own. Diffusion reaches the people adjacent to whoever already practises and then stalls at the edges of that neighbourhood. The teams left over are not late adopters waiting their turn; they are unconnected, and they stay unconnected indefinitely unless someone builds the link deliberately.
No feedback channel from champion to leadership. The champion's observations are the highest-quality signal about adoption reality that leadership has access to. If there's no mechanism for that signal to reach Bob and inform decisions, the champion's insights are wasted. Build a regular feedback loop into the role structure.
How Different Roles See It
Bob is three weeks into a pilot deployment and hearing mixed signals. Victor (the designated champion) is active and productive. Two other developers on the pilot team are using the tool occasionally. The other eight developers on the team haven't engaged at all. Bob isn't sure whether this is expected at this stage or whether the pilot is already failing.
What Bob should do: Bob should have a direct conversation with Victor to get the ground truth. Not "how's the pilot going" - that produces a polite non-answer. Specifically: "Which developers have engaged and which haven't? What's blocking the ones who haven't? What do you need from me to fix that?" Bob should then act on what he hears. If the blocker is a security review delay on the tool's network access, Bob should resolve that in days, not weeks. If the blocker is that developers don't know where to start, Bob should clear calendar time for Victor to run a workflow demo at the next team meeting. The champion's effectiveness is proportional to the organizational support behind them.
Sarah is trying to understand why adoption rates vary so dramatically across teams. Team A, where Victor is championing, has 70% weekly active usage after 60 days. Team B, which has no designated champion, has 15% usage. Leadership is asking whether the difference is due to the teams themselves or the champion structure.
What Sarah should do: Sarah should use the natural experiment she has. The difference between Team A and Team B in champion support is the most important variable in her dataset. She should interview 3-4 developers on each team: what questions did they have when they started, who did they ask, how quickly did they get answers, what workflows did they land on? The answers will almost certainly show that Team A's developers got fast, high-quality answers to their initial questions, and Team B's developers had to figure it out alone - and most of them didn't. Sarah should present this as evidence for formalizing the champion structure before expanding to additional teams.
Victor has been doing champion work informally for two months. He's answered hundreds of questions, run three workflow demos, and written a 15-page internal guide. His colleagues trust his expertise and his adoption rates are strong. But he's doing this on top of his normal engineering work, his PR throughput has dropped, and he's starting to feel like the champion role is a tax on his career rather than an investment in it.
What Victor should do: Victor is spreading practice one conversation at a time, which is why it works and also why it does not scale past him. The move is to convert the repeated conversations into things that travel without him: a written workflow with examples from their actual codebase beats a Slack answer, and a colleague he has coached into answering questions themselves beats both. He should pick the two or three people on adjacent teams who others already turn to and invest disproportionately in them, because a second well-connected node reaches further than twice as many hours from the first. Victor should also be explicit about which teams he has no path into, and say so, since those are the ones that will show as flat adoption in six months and be misdiagnosed as resistance. The separate question of what his time allocation and recognition should be is a real one and belongs in a conversation with Bob about the role itself.
Further Reading
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
How This Guide Changed
What each edition changed in this guide, newest first.
- V1.6September 2026LATEST
Rewritten around the mechanism instead of the person: adoption travels along working relationships, between people in the same codebase, and a mandate moves licence counts, install rates and attendance at the enablement session while nothing about how anyone works changes. The reason is that the knowledge worth transferring is local and specific, and only a peer in the same code has it. Victor stays in the guide as a well-connected node in that network rather than as the mechanism itself, and how his role is defined, named and funded now lives in Team Structure & Roles.
- V1.5August 2026
L2 was relabelled from Guided to Delegated across the model, which changes how the informal stage of this role reads: the level is defined by what the team hands over, not by how closely somebody watches. The champion's own arc through it - volunteer, then funded, then a network or a platform team - is unchanged.
- V1.3June 2026
A reference repair and nothing more: the developer-advocacy pointer moved to a copy of the piece that still resolves. The claim that a champion is defined by outward orientation rather than enthusiasm was left alone.
- V1.0March 2026
In the first edition this made a claim most adoption material avoids: the champion matters more than the tool, the licence count or the executive mandate. It was aimed at programmes that had funded everything except the person whose job it is to turn one engineer's learning into the team's.
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.