It's a federal holiday Operators Cut, and this one makes a bold claim up front: across every enterprise NLW and returning guest Nufar have worked with, the single highest-ROI AI transformation move is a well-structured internal champions program. This episode is the full playbook — what the role actually is, how to nominate and train for it, why most networks die the day after certification, and the checklist that separates a power user from a champion.
AI champions are the highest-ROI move in enterprise AI — if you treat it as a real role, not a reward.
Every team already has the person everyone calls when they want to get something done with AI. The companies that win are the ones that formalize that person — deciding where they sit on the spectrum from ambassador to internal forward-deployed engineer, nominating for the right signals instead of seniority or reward, training them on their own team's real work, and above all owning the day after certification. The tools will change every quarter; the playbook — right people, written-down scope, the whole road from idea to production, and someone who owns the continuation — doesn't.
Across all of NLW's experience with enterprises, nothing beats a well-structured internal champions program — and of all the adoption strategies he and Nufar have seen companies try, it's one of the only ones that consistently works. In his words: it never fails.
Everyone has seen the same phenomenon — someone on the team finds a great way to do something with AI, shows people, and it never turns into something the whole team uses. The champion is the person whose job is to fix that: to spread the AI.
Once you're an advanced AI user, the champion role finds you — with friends and family, and definitely on any team. And it's a different muscle than using AI well: communicating how to use it, thinking in process terms rather than just implementation.
A champion sits within the team and does the team's work, but is a step ahead in AI. They show what AI can do on work their peers actually do — real use cases, not theory — connect with other champions and central AI teams, and move people forward without having authority over them.
At one end, ambassadors drive adoption, showcase real use cases, and voice what the team needs. At the other, internal forward-deployed engineers are professional builders embedded in business teams who take solutions from idea to production — some of them subject matter experts who made a genuine career pivot into building. Most companies land in the middle: ambassador-builders who build within a defined scope and act like product managers beyond it.
Who gets to build (the democratization question)? What do we expect from everyone else? How does AI spread from the field? And how do champions work with central teams and vendors? Even if no one in your company holds the title 'central team,' you are living with these questions — they separate opinionated companies from the ones still flailing.
Ask 'what are you planning to accomplish with a champion network?' and companies struggle; ask where on the ambassador-to-FDE line champions should sit and the real conversation starts. Write down goals, responsibilities, and expectations, agreed with IT and security. One company realized its champions should primarily be a funnel of good use cases from the ground to a central team otherwise blind to day-to-day reality — a completely different role and training than full builders.
They use AI without being told to, their peers already come to them for guidance, and their manager actually gives them time to work on AI for others — the signal where great nominations most often fall short. And remember: champion status is a huge perk that makes the person highly desirable on the market, so nominate people you want to retain and promote.
Senior people self-nominating to improve their own skills or steer the build — they belong on an AI steering committee, not training peers. Great candidates who are also the busiest people on the team, with no bandwidth. Nomination as a reward for strong players who aren't actually good enough AI users. And never nominate someone who started yesterday — champions have to know the business ins and outs to spot use cases.
Whatever training format you choose, train champions on their own work. The simple pass/fail: by the end, every champion takes one real use case from their team and shows how they built or promoted it. If they can, they're ready; if not, there's more work to do.
Training usually ends with a kickoff, a certification, and a lot of pride — and that's where many initiatives fail. In every company where an amazing champion course never materialized into business value, the missing piece was the same: nobody owned the continuation, so champions drifted back to working the way they did before.
One community-side sponsor from HR or the people team who keeps the human side alive, and one professional sponsor — savvy about AI, working closely with the chief AI officer — who sets priorities, steers champions toward the company's AI strategy, and clears the path on approvals, access, and tools. The most successful network Nufar has seen runs on a dynamic duo of an L&D expert and an AI expert working together.
AI upskilling doesn't fit old corporate training models — it's too all-encompassing, with no agreed standards — which makes 'how much to invest in whom' genuinely hard. But training the group that then disseminates the most contextually relevant pieces to everyone else is an extremely high-ROI category even relative to other training: a relatively small number of people with huge impact on the company.
A common failure is great champions whose managers have unrealistic expectations, don't know how to use them, or sit too far behind in knowledge — leaving everyone frustrated. Even a very short session for managers on what champions know, what they're expected to do, and how to leverage them makes a big difference in the network's output.
Not everyone nominated will stay a champion — people leave, get busy, or realize the role isn't for them — so the network must be a living entity with easy exits, easy onboarding, and education that never stops. If yours is losing energy: name your two sponsors, check that every champion still has the one or two days of capacity, let people step out with thanks, and nominate new people all the time.
Whatever flavor of champion, they need to understand idea to production in three stretches: before the build (knowing the ground, what the company allows, where use cases live, and whether to build at all), the build itself (POC to production), and after the build — value realization, deployment, and retiring solutions when needed. Most people only know the middle.
Good champions find problems worth solving and are deliberately conservative about the economics. Being able to articulate who suffers from the problem, how often, and what 'done' looks like changes the picture — and checking the idea against what already exists means the company builds a thing once, not 100 times.
Beyond ROI and day-two deployment questions — where does it live, who approves it, who supports it — the big one is evaluation. How do you know what you built is good, when you can trust it, and what the mistakes cost? The champion's defining judgment call is whether a thing is good enough to put in users' hands.
There's a huge bias toward building among individuals and companies — people just go ahead. Check how often the problem comes up, what it's worth, and how costly mistakes are; only then decide between reusing something that exists, buying, building, or putting it on the backlog. Grounded, company-connected decisions — not passion projects.
The current instinct is that everything must be a fully connected agent. A good champion has a mental model of the right technology for the job: sometimes a shared chat setup with prompts and files is enough, sometimes a skill or an automation, and only sometimes a full-blown agent. Start with the simplest thing that solves the problem rather than the most complex thing you can think of — which you'll then have to maintain and test.
Define the core properties up front: who it's for (designing for everybody is designing for nobody), what it needs to know, how people will actually use it, who checks the output, and concrete guardrails — starting with what the solution must never do often creates the clearest picture of what it should do. Configure test cases as early as possible; sometimes the inability to ensure quality rightly kills a project before it's built.
Unlike most things in AI right now, these playbooks aren't transient. Whatever the technology does next, you'll still need the right people with protected time, a written decision on where they sit between ambassador and builder, champions who understand the whole road from idea to production, and someone who owns the day after.
A growing version of the internal FDE is the non-technical person who's figured out agentic coding tools — the best current example of AI's power and challenge at once. It's not just an under-optimized opportunity anymore: agents are powerful and tenacious enough to escape containment and weave into systems, so champions become the role that lets companies move forward safely as jobs fundamentally change.
Nufar's answer to the security worry: instead of banning subject-matter experts from building, invest in enablement and infrastructure and train more of them, because they're the ones who will work on the right use cases. Getting that right, she argues, is more challenging than mastering the technology itself.
Champion training isn't mostly about tool skills: people learn to build through trial and error, and the tools increasingly do the work for you. What separates champions from power users is the stuff nobody accidentally lands on — evaluation, and the in-between business-technology-people side — playbooks that are still being written and that most companies don't know how to train internally.