Eighteen months into the firm's AI program, the single most fluent person on it gave two weeks' notice. A senior project engineer who had quietly become the person every PM, super, and estimator messaged when an AI tool misbehaved, who had written the prompt library everyone copied, who had run the lunch-and-learns and fixed the bad outputs before they reached an owner. When she left, the help slowed to a trickle, the prompt library went stale within a quarter, the lunch-and-learns stopped, and adoption in three of the firm's four business units quietly slid back toward the old way of working, because the program had been carried by one person and that person was gone. The lesson she taught the firm, expensively, is that adoption does not live in the rollout deck or the enterprise contract; it lives in people, and if it lives in only one person it is a single point of failure. This lesson builds the answer the firm should have built before she left: a champion in every group, identified, equipped, and rewarded, with an operating rhythm and a recognition program that spread the load so no one person becomes the program, and so the program survives any one departure. You will leave able to name the champions, document the operating rhythm, and design the recognition program that sustains adoption after the rollout.

Why the Champion Carries Adoption Where the Mandate Fails

Top-down mandates announce adoption; they do not produce it. A firm leader can buy the enterprise license, run the kickoff, and email the policy, and adoption still stalls, because the people who have to change how they work do not change because an executive told them to. They change when a peer they trust, doing their own job, shows them the tool earns its place in the day. That peer is the champion: not a manager assigning the tool, not a vendor demoing it, but a working PM, super, estimator, scheduler, VDC coordinator, or project engineer who uses the AI on real deliverables and helps the group do the same. The champion has the one thing the executive and the vendor lack, which is credibility inside the group: they have stamped the work, walked the deck, won the bid, so when they say the tool helps and here is how to make it not lie to you, the group listens in a way it never listens to a rollout deck.

This matters strategically because adoption is local. The RFI workflow looks different in the GC's operations group than in the MEP subcontractor's coordination group; the estimator's takeoff verification is nothing like the super's daily-report verification; the AOR's stamp discipline is its own world. A central program cannot author the prompt, the verification gate, and the failure modes for every group, because it does not do every group's work. The champion does: translating the firm's AI program into the group's actual deliverables, adapting the prompt library to the group's templates and controlling spec sections, knowing where the tool fails on the group's scope, and standing at the verification gate the work requires. Without a champion, the central program is an abstraction; with one, it is a working practice the group can copy. This is why the strategy is a champion in every group, not a center of excellence in the firm: adoption is carried locally by a trusted peer, or it is not carried at all.

The Controlling Analogy: The Champion Is the Working Foreman

Understand the champion the way every builder understands a working foreman. The foreman is not the project executive and not a tradesperson taking direction; the foreman is the most skilled hand in the crew who also carries the crew, who knows the work because they do the work, and who the crew follows because they earned it on the deck, not in the trailer. A foreman cannot be appointed by org chart alone; the crew recognizes a foreman because they are the best at the work and make the crew better. The firm runs a building through foremen who translate the schedule into the day's pour and catch the bad layout before the concrete, not by emailing crews a productivity target.

The AI champion is the working foreman of adoption. They are the most fluent hand in the group, carry the group's AI practice the way a foreman carries the crew's production, and are followed because they have credibility on the group's own work, not because the firm named them. This analogy is load-bearing for the rest of the lesson because it tells you how to build the role: you do not appoint a foreman who cannot do the work, so you do not appoint a champion who is not fluent and trusted on the group's deliverables; you do not run a job with one foreman and no backup, so you do not run a group with one champion and key-person risk; and you do not get a foreman's best work for free, so you do not get a champion's effort without equipping and rewarding it. Identify, equip, and reward the foreman, do not let the whole crew depend on one, and give the foreman a cadence to run the crew by.

Identify, Equip, and Reward: The Three Moves That Make a Champion

Building a champion is three deliberate moves, and skipping any one is why most champion programs fail. The first move is identify. The champion is not the loudest enthusiast or the org-chart-convenient pick; it is the person the group already trusts on the work who is also willing to carry the AI practice. Identify them by two signals together: credibility on the group's deliverables (a PM whose RFIs the team already copies, a super the field follows, an estimator whose numbers hold), and real pull toward the tooling (they already experiment and help peers unprompted). Credibility without pull will not carry it; pull without credibility will not be followed. You need both, one in every group, named, not assumed.

The second move is equip. A named champion with no time, no tools, and no support is a title, not a function. Equipping means four concrete things: protected time (a named fraction of the week for adoption, not stolen from billable work and resented), access (the tools, licenses, early features, vendor training, and a direct line to the firm's AI program lead), authority (the mandate to adapt the prompt library, set the group's verification gates, and speak for the group's AI practice), and a peer network (the other groups' champions, so a champion is never solving alone what another already solved). The third move is reward. Champion work is real work, often invisible, and unrewarded invisible work stops. Reward means recognition (the firm names and credits champions visibly), advancement (champion work counts toward promotion and is written into the development conversation), and material reward where the firm can (a stipend, a bonus component, conference budget). A champion you named but did not equip will not function, and one you equipped but did not reward will burn out, the danger the next section develops.

A champion in every group carries adoption where the top-down mandate cannot, because the champion is the working foreman of the tool: trusted on the group's own deliverables, fluent on the work, and followed because they earned it on the deck. But a single champion is a single point of failure, so the firm names a champion in every group, equips and rewards them, and protects against the burnout and key-person risk that turn the program's strength into its fragility.

The Danger: Key-Person Risk and the Single Point of Failure

The champion model has a built-in failure mode the opening scene names exactly: the champion becomes a single point of failure. When a group's entire AI practice lives in one person, that person is load-bearing in a way the firm does not notice until they leave, go on leave, get pulled to a troubled project, or burn out. The fluency is in their head, the prompt library is maintained by their hand, the help comes from their messages, and the verification discipline is enforced by their presence. Remove them and the practice does not degrade gracefully; it collapses, because nothing was written down, distributed, or backed up. This is key-person risk, the same risk a firm manages when one super knows where every buried utility is and there is no record.

The defense is to make the champion's knowledge institutional rather than personal. Everything that lives only in their head must be externalized: the prompt library is version-controlled and documented, not a private file; the group's verification gates are written down as the group's standard, not enforced as the champion's habit; the failure modes the champion knows are captured in a living document the group owns. And no group should have exactly one champion: the firm names a primary champion and a backup in every group, so the practice has two carriers and one departure does not end it, the same redundancy a job runs with a foreman and a lead who can step up. Run the test deliberately: if this champion left tomorrow, what would the group lose? The work is to move that out of the person and into the group before the departure, which is the lesson the firm in the opening scene learned a quarter too late.

The Danger: Burnout and Why the Best Champion Is Most at Risk

The second danger is burnout, and it has a cruel structure: the better the champion, the more the group leans on them, so the firm's best champion is its most at-risk asset. Champion work is additive on top of the actual job; the PM is still a PM, the super is still a super, and the champion work, answering questions, fixing bad outputs, running the lunch-and-learns, maintaining the library, is layered on top, often uncompensated and invisible to the people setting their workload. A capable champion absorbs more and more of the group's AI dependence until the load becomes unsustainable, and then they either quietly stop championing (and the program decays) or leave (and it collapses), the burnout-to-departure path the opening scene walked.

Protecting against burnout is the core sustainability discipline of the program, with four concrete levers. Protected time: the champion's adoption work must be a named, funded fraction of their week that their project workload is reduced to accommodate, not unpaid overtime stolen from their evenings. Distributed load: the primary-and-backup structure spreads the work, and the cross-group champion network means a champion routes a hard question to the group that already solved it rather than absorbing every problem alone. Visible reward: burnout accelerates when effort is unseen, and a champion whose work is recognized, credited, and counted toward advancement sustains it far longer. Bounded scope: the champion is not the firm's free AI help desk for every group; their scope is their group, and the firm staffs cross-group support rather than letting it fall on whichever champion answers first. The firm that does not manage these levers loses its best champions on exactly the schedule the opening scene set.

The Operating Rhythm: The Cadence That Sustains the Practice

Identifying, equipping, and rewarding the champions creates the role; an operating rhythm makes it run. A program without a cadence is a set of names that drifts; adoption is an ongoing practice that needs a recurring beat, the same way a project runs on a daily huddle, a weekly look-ahead, and a monthly OAC, not on a single kickoff. The operating rhythm is the documented set of recurring touchpoints that keep champions connected, the practice current, and the firm informed. A weekly group touchpoint, where the champion is available to the group, fields the week's questions, and surfaces the week's good and bad outputs, often folded into an existing meeting so it adds no new burden. A monthly champion network call, where champions across groups meet, share what worked and what failed, update the shared prompt library, and route hard problems to whoever solved them, the mechanism that distributes load and prevents each champion from solving alone. A quarterly program review with the firm's AI program lead, where champions report adoption signals, surface the tools and features the groups need, and the firm reports back on direction, closing the loop between field practice and firm strategy.

The rhythm is documented so it survives turnover: when a champion changes, the cadence continues because it is the program's written rhythm, not the old champion's habit. It also carries the metrics lightly: champions surface the adoption signals their groups generate (which workflows are used, where the verification gates catch things, where the tool keeps failing), which feeds the firm's measurement program, the subject of the next chapter. The discipline is that the rhythm is named, scheduled, owned, and documented, not improvised, because an improvised cadence is the first thing to lapse when the champion gets busy, and a lapsed cadence is how a program quietly dies between two project crunches.

The Recognition Program: Making the Reward Real and Durable

Reward was named as the third move; the recognition program is how the firm makes it real, durable, and not dependent on a manager remembering to say thank you. Ad hoc recognition fades; a documented program institutionalizes it so champion work is reliably seen and credited, which keeps champions from the invisible-effort burnout the prior section named. It has three layers. Visible credit: the firm names its champions publicly, in program communications and at the all-hands, the way it names its top safety performers, so the role carries status. Career advancement: champion work is written into the firm's development and promotion criteria, so a PM who carried their group's AI adoption sees it count in their review, which makes the role something people want rather than a thankless extra. Material reward where the firm can fund it: a stipend for the protected-time commitment, a bonus component tied to the adoption the group achieves, a conference or training budget the champion controls, so the firm puts money behind the words.

The program also has to be fair and legible, because one that rewards the loudest rather than the most effective produces performers instead of champions and demoralizes the quiet champion whose group actually adopted. So recognition ties to the adoption signals the operating rhythm surfaces (the group's real usage and verification discipline) rather than to visibility alone. This closes the loop the opening scene opened: the firm that recognized, credited, advanced, and paid its champions would not have lost its best one without warning, because the role would have been seen, valued, sustainable, and worth staying for. That is the difference between a role people burn out of and one they compete for.

The Applied Problem: Name the Champions, the Operating Rhythm, and the Recognition Program

For your firm, produce the champion program in three named parts. First, name the champions: list every group (GC operations, precon and estimating, field and superintendents, VDC and coordination, design and AOR, scheduling, and any others your firm runs), and for each name a primary champion and a backup, chosen on the two signals together (credibility on the group's deliverables and real pull toward the tooling), so no group is uncovered and none has a single point of failure. For each, state what equips them (protected-time fraction, access, authority to adapt the group's prompt library and set its verification gates) and the key-person risk you mitigate by naming the backup and externalizing the knowledge.

Second, document the operating rhythm as a standard the program owns, not the champions' habit: the weekly group touchpoint (where it lives, who runs it, what it surfaces), the monthly champion network call (who attends, what gets shared, how hard problems get routed to distribute load), and the quarterly program review with the firm's AI lead (what adoption signals the champions report and what the firm reports back), so the rhythm survives any departure. Third, design the recognition program: specify the three layers, visible credit (how the firm names and credits champions), career advancement (how champion work counts in development and promotion), and material reward (the stipend, bonus component, or budget the firm can fund), tied to the real adoption signals the rhythm surfaces rather than to visibility alone.

The lasting product is a program that carries adoption locally through a trusted peer in every group, protects against the burnout and key-person risk that turn the program's strength into a single point of failure, and runs on a documented rhythm and durable recognition rather than one good person's uncompensated effort, so when any one champion leaves, the program does not leave with them. That is the difference between the firm in the opening scene and the firm that sustains adoption after the rollout: not a better tool or a louder mandate, but a champion in every group, equipped, rewarded, and never a single point of failure.

Key Takeaways

• Top-down mandates announce adoption but do not produce it; the champion, a trusted peer in every group, carries it because they have credibility on the group's own deliverables that the executive and vendor lack, and because adoption is local and must be translated into each group's actual work by someone who does that work.
• The champion is the working foreman of adoption: the most fluent and trusted hand in the group, followed because they earned it on the work, not because the firm named them; the analogy governs the whole program, so you identify, equip, reward, back up, and give the champion a cadence the way a job treats its foreman.
• Building a champion is three deliberate moves: identify (the trusted, fluent peer chosen on both credibility and real pull, one in every group), equip (protected time, access, authority, peer network), and reward (recognition, advancement, material reward); skipping any one is why champion programs fail.
• Key-person risk is the structural danger: when a group's entire AI practice lives in one head, their departure collapses the practice rather than degrading it gracefully, so the firm externalizes the knowledge (version-controlled prompt library, documented verification gates and failure modes) and names a primary champion and a backup in every group.
• Burnout is the second danger and targets the best champion: the more capable they are, the more the group leans on them, so the additive, often invisible, uncompensated load becomes unsustainable; the defenses are protected time, distributed load, visible reward, and bounded scope.
• The operating rhythm sustains the practice: a weekly group touchpoint, a monthly champion network call that distributes load across groups, and a quarterly program review with the firm's AI lead, documented as the program's standard so the cadence survives any departure rather than lapsing as a personal habit.
• The recognition program makes reward real and durable through three layers, visible credit, career advancement, and material reward, tied to the real adoption signals the operating rhythm surfaces rather than to visibility alone, the difference between a role people burn out of and one they compete for.
• The named artifact is the three-part champion program: named champions (primary and backup in every group, with what equips them and the key-person risk mitigated), the documented operating rhythm (weekly, monthly, quarterly, program-owned), and the recognition program (credit, advancement, material reward, tied to adoption), so adoption survives any one champion's departure.