← narwal.one/Second Brain
SecondBrain
Ask the Brain
Index/Sourceupdated Tue Oct 20 2026 08:00:00 GMT+0800 (Philippine Standard Time)

How to Go from AI Power User to AI Leader (AI Daily Brief)

ai-daily-briefwhittemorenufar-gasparoperators-cutai-championsenablementadoptionupskillingforward-deployedinternal-fdechange-managementoctober-2026

How to Go from AI Power User to AI Leader (AI Daily Brief)

An Operator's Cut episode of The AI Daily Brief (aired 2026-10-12, a US federal holiday; captured 2026-10-20). Nathaniel Whittemore and Nufar Gaspar (Super Intelligent) on AI champions programmes — the internal network of power users who spread AI adoption. Whittemore's bold claim up front: across all his enterprise work, "the single highest ROI transformation activity that I have seen is when companies structure this sort of internal champions program well" — "one of the only consistently always successful ways" to improve how a company uses AI. Gaspar's version: the highest-ROI thing you can do, and a relatively small number of people with outsized impact versus training everyone.

The problem it solves: someone on the team finds a great way to do something, shows two people, and it never becomes something the whole team uses. The champion's job is to fix that transmission gap. Full playbook filed as AI Champions Network.

Definition and spectrum

A champion is the person in a team "responsible for moving AI adoption and value forward" — peer plus one: they do the team's work but are a step ahead in AI, whether appointed or de facto. They show what AI can do on the work peers actually do, connect to other champions and central teams, and move people forward without authority over them. Names vary (evangelist, ambassador, adoption lead); "champion" is most common.

Roles sit on a spectrum, and where a company puts them is a strategic decision:

Ambassador Ambassador-builder (where most companies land) Internal FDE (forward-deployed engineer)
Builds? No — showcases, trains peers, voices team needs For self and immediate team, inside a defined scope Idea to production
Beyond scope Clean request to central team/vendor Acts as product manager: gathers requirements, hands off Owns it
Example (customer-renewal summary) Spots it, costs it, makes the case, ensures adoption after Builds the team version; another team productises Takes it all the way

Many internal FDEs are subject-matter experts who made a real career pivot into building, not engineers by origin.

Company side: building the network

Four questions every company is really asking: who gets to build (democratisation); what is expected of everyone else; how does AI spread from the field; how do champions work with central teams, IT, security and vendors.

  1. Goals first. "What are you planning to accomplish?" — companies struggle to answer. Then: where on the ambassador→builder line do you want champions? Write down goals, responsibilities, expectations, agreed with IT/security. Revisit periodically — one company decided its champions were primarily a use-case funnel to a central team "blind to the day-to-day reality"; others later re-trained champions into full builders.
  2. Nomination — three signals: among the most sophisticated users without being told; peers already come to them; their manager will give them the time (where great nominations most often fall short). Also: influence without authority, business knowledge, initiative, curiosity. Nominate people you want to retain and promote — the title is a market-visible perk. Anti-patterns: very senior people self-nominating (they belong on a steering committee, not building/training); the busiest person on the team; nomination as a reward for strong players who aren't strong AI users; anyone who started yesterday (use-case identification needs business knowledge).
  3. Training — one test. Whatever the format (bootcamp, gradual, internal), train on their own work; every champion takes one real team use case and shows they built or promoted it by the end. Ends in a kickoff/certification.
  4. The day after — "the biggest predictor of whether this succeeds." Needs two sponsors: a community sponsor (HR/L&D, keeps the people side alive) and a professional sponsor (close to the chief AI officer, sets priorities, clears approvals/access/tools, bridges to central teams). The best network she has seen runs on an L&D-expert + AI-expert duo. Every failed champions course lacked this continuation: nobody owned it, so champions reverted.
  5. Community hygiene: regular meetings, easy sharing, celebration; a short session for champions' managers on what champions know and how to use them (knowledge gaps between champion and manager frustrate everyone); a living network — easy to leave and hand over, easy to join, education never stops. Reviving a tired network: name the two sponsors, confirm each champion still has 1–2 days of capacity, re-commit managers, thank and release those who can't, nominate new people continually.

Whittemore's addendum: enterprise AI training doesn't fit old corporate-upskilling models and has no agreed best practice yet, which makes "how much to invest in whom" hard — but training this group is the high-ROI exception because they disseminate the contextually relevant parts.

Champion side: the whole road from idea to production

Champions (and serious power users) must understand the full road, whatever slice they own: before the build (know your ground, what the company allows, where use cases live; decide if/what/how to build), the build (POC to production), after (value realisation, deployment, retirement).

  • Use-case identification: find problems worth solving where cost justifies investment — be conservative (investment higher, day-one value lower than you think); articulate who suffers, how often, what "done" looks like; check against what exists so the company builds once, not 100 times.
  • ROI realism: does it move a critical indicator; what must be measured.
  • Deployment: where it lives, who approves, who supports on day two.
  • Evaluation — the champion's signature skill: how do we know it's good, when we can't trust it, what mistakes cost; the ability to sign off that it's good enough for users. Gaspar: evaluation "is not something someone accidentally lands upon" — it, and the business/technology/people in-between, is what the bootcamp emphasises; the building part is "the easy part."

Three playbooks — "the builders' checklist":

  1. Should we build at all? How often does it come up, what's it worth, how costly is a mistake; then reuse / buy / build / backlog. "There is such a huge bias towards building" — a good champion decides from the company-connected view, not as a passion project.
  2. Simplest thing that solves it. A technology ladder: shared chat setup (prompt + instructions + files) → a skill (on-demand playbook) → an automation → a full agent. Go right only with justification; otherwise you're left with something hard to build, maintain and test.
  3. Define core properties before building — the spec you hand to a vendor, central team, or yourself: who it's for ("everyone" = nobody); what it must know (often a hidden knowledge-curation project); how people will use it (not "a glorious vibe-coded app nobody remembers the URL to"); what it must never do (starting from guardrails clarifies what it should do); who checks the output / where human judgment sits; how you know it works — define test cases early, which surfaces edge cases and sometimes kills the idea before it's built.

These playbooks are deliberately the parts that stay valid as tools change quarterly: you still need the right people with time, a written position on the ambassador–builder line, the whole road, and someone owning the day after.

The emerging edge case: non-technical people who code

Whittemore flags the version of the internal FDE "that's not necessarily a technical person" — someone who has started using agentic coding tools to do parts of their job. "The best example right now… of the power and challenge of AI all at once": huge leverage, but new security/guardrail problems "not just because people are doing it wrong, but because the agents are powerful and tenacious enough that they tend to escape containment pretty quickly." He expects champions to become more mission-critical as a result. Gaspar: instead of shutting down less-professional builders, do the enablement and infrastructure, and train more subject-matter experts — "even more challenging than mastering the technology itself."

Plug: Super Intelligent is launching an AI champions bootcamp; the slides are on the episode's companion page at aidailybrief.ai.

Caveats

  • Practitioner testimony from a consultant who sells champion training (and a host who co-runs the training business); no measured outcomes, no named companies. The "never fails" claim is experience, not evidence.
  • Auto-captioned transcript: the guest's name is rendered "Nofar"/"New Far"; confirmed as Nufar Gaspar via podcast listings.

Connects to your work

  • Directly operational for the 10x IT programme / Manila IT capability work. The nomination signals and anti-patterns, the two-sponsor model, the one-real-use-case certification test and the "day after" ownership are a checklist to audit any existing champions/ambassador cohort against. The "manager will give them the time" signal is the one most likely to be missing. See DRAG for AI Upskilling at Manila IT Site for the vault's delivery-format playbook; this episode supplies the who and the governance that page lacks.
  • Builds on the vault's existing arc: How to Help People Thrive with AI (AI Daily Brief) (champions as "show them what they could be doing," not internal PR; "internally deployed vibe coders") → Agentic Pods (Uber's pairing recipe) → this episode (the full programme design). The ambassador→internal-FDE spectrum is the missing taxonomy that links them.
  • Pays the The Upskilling Bill: champions are the "transmission, not instruction" mechanism Whittemore reported enterprises struggling with at KPMG — and the "simplest thing that solves it" ladder is a governance tool against agent sprawl.
  • Thought-leadership hook: "peer plus one" and "the biggest predictor of success is what happens the day after you certify someone" are both clean LinkedIn lines.

Cross-links

Source

  • source — YouTube, The AI Daily Brief, captured 2026-10-20