How to Go from AI Power User to AI Leader

The host opens by saying that every professional group now has “power AI users”—people who try new models and products, report what works, and often become informal or formal internal ambassadors. Based on his and Nufar’s work with enterprises of different sizes, he calls a properly structured internal champions program one of the few strategies that has consistently improved employees’ experience and use of AI. Nufar agrees, describing an AI champion network as one of the highest-ROI activities a company can undertake for AI adoption. Nufar says the recurring problem is familiar: one person discovers an excellent way to use AI, shows it to two colleagues, and the practice never spreads across the team. The champion’s job is to fix that by converting individual experimentation into shared adoption and business value. The role may be called an evangelist, leader, or adoption-support person rather than a champion. The host adds that even people outside large enterprises are likely to be pushed into this role once they become advanced AI users—at least among friends, family, or teammates. Using AI effectively requires a different skill from explaining the process in a way others can reuse.

Nufar defines an AI champion as the person responsible for moving AI adoption and value forward in a team or environment. The champion is usually a “peer plus one”: they perform the team’s regular work but are somewhat ahead in AI capability. They demonstrate practical use cases drawn from colleagues’ day-to-day work, connect with other champions and central AI teams, identify what the company’s tools can support, and move peers forward without necessarily having formal authority. She places champion roles on a spectrum. At the ambassador end are the strongest AI users, who showcase real examples, train colleagues, surface the team’s needs, and communicate useful requests to central teams. At the other end are internal “FDEs,” or forward-deployed engineers: professional builders embedded in business teams who can take an idea into production. Between them are ambassador-builders, who can build within a defined scope but hand larger requirements to vendors or specialized internal teams. Nufar stresses that companies must explicitly decide where their champions sit on this spectrum, what they may build, and what remains the responsibility of central AI, IT, security, or professional engineering teams.

Before establishing a network, Nufar recommends answering four questions: who is allowed to build, what is expected of ordinary users versus champions, how useful practices will spread from teams into the wider company, and how champions will work with central teams or vendors. Companies should write down goals, responsibilities, and expectations with IT, security, and other stakeholders. One company decided its champions would primarily act as a funnel, bringing valuable use cases from operational teams to a central group that otherwise lacked visibility into daily work. Other companies have instead trained champions to become full builders, almost like AI engineers developed from within the business. For nominations, Nufar looks for people who already use AI in sophisticated ways without being instructed to do so, whom colleagues approach for advice, and whose managers will give them time to help others. Influence without authority, deep knowledge of the business, initiative, and curiosity are also important. She warns against senior leaders nominating themselves; they belong on an AI steering committee rather than in a peer-training role. Other bad choices include highly capable people with no bandwidth, employees named as a reward despite lacking the necessary AI or interpersonal skills, and newcomers who do not yet understand the team’s work. Champions should be people the company wants to retain and promote, because the role builds both visibility and market value.

Nufar recommends training champions on their own work rather than relying only on generic AI instruction. Her preferred test is concrete: each participant should take a real use case from their team and show that they can build or promote a solution by the end of training. If they cannot, they need more preparation. A boot camp, gradual training, or internal program can all work, provided the training produces evidence that champions can apply AI in context. The critical test comes after certification. Nufar says successful networks need two sponsors: a community-oriented sponsor from HR, learning and development, or the people team, and a professionally knowledgeable AI sponsor who can connect with a chief AI officer or central AI strategy. The first keeps the community functioning; the second sets priorities, clears access and approval barriers, and connects champions with IT, security, tools, and vendors. She cites one successful company where an L&D expert and an AI expert operate as a “dynamic duo,” regularly checking what champions need and what they are building. Programs that delivered excellent courses but no business value lacked this continuation and ownership, causing participants to return to old habits. The network should include regular meetings, easy sharing and recognition, and brief training for champions’ managers. Managers need to understand what champions know, what they are expected to do, and how to use them effectively. Membership must also remain fluid: people should be able to leave when the role no longer fits, hand it to a colleague, and allow new members to join. If a network loses energy, Nufar recommends checking its sponsors, confirming that champions still have roughly one or two days—or otherwise sufficient capacity—to do the work, and re-establishing manager commitments.

For the individual champion, Nufar says the core capability is understanding the entire path from an AI idea to a production solution that people use every day. That includes knowing the team’s problems, the company’s rules, and where useful cases exist; deciding whether and what to build; building from proof of concept to production; deploying and realizing value; and eventually retiring a solution. These responsibilities apply even to unofficial power users. The first discipline is use-case identification. Champions should explain who suffers from a problem, how often it occurs, what the current cost is, and whether the expected value justifies the investment. They should be conservative because costs often exceed initial estimates and value may be lower at launch. They should also check what already exists so the company does not build the same solution repeatedly. ROI means explaining what the solution is worth, how it affects a critical performance indicator, how it will be measured, and what will happen after the initial excitement. Deployment requires deciding where the solution lives, who approves it, who supports it on “day two,” and how to get it into the right users’ hands often enough. Evaluation is equally important: champions must determine whether outputs are good enough, trustworthy enough, and safe enough to sign off for users.

Nufar says champions should first ask whether anything should be built at all. They should assess how frequently the problem occurs, its value, the cost of mistakes, and whether the answer is to reuse an existing tool, buy something, build it, or put it on a future backlog. She sees a strong bias toward building as a recurring problem: a champion should make a grounded, company-connected investment decision rather than pursue a passion project. She also argues against assuming every problem requires a fully connected agent. The simplest adequate solution might be reusable prompts, instructions, and files; a skill or playbook that runs on demand; a deterministic automation; or, only when justified, a full agent. More complex systems are harder to build, maintain, and test. Before building, the champion should specify the target users—not “everyone”—what knowledge the solution needs, how people will use it, what it must never do, who checks its output, where human judgment enters the process, and how quality and safety will be balanced against business value. Test cases should be defined early, including edge cases, because they may expose that the project cannot be evaluated reliably and should be stopped before more resources are spent. For an example involving hours spent assembling a customer summary, an ambassador would clearly describe the problem and business case for a central team or vendor, then help ensure adoption. An ambassador-builder might create a team-level version within an approved scope before another team productizes it. An internal FDE could take the project through the entire build and deployment process.

Near the end, the host says the internal FDE role is increasingly being filled by people who are not traditionally technical but have learned to use code and agent-coding tools to solve parts of their jobs. He sees this as both a major opportunity and a major challenge: employees can do work they previously could not, but they also need help choosing appropriate uses, understanding how to work this way, and dealing with security and guardrail risks. Because agents can be powerful and persistent, they may escape their intended containment and reach into multiple systems. The host therefore expects champions to become more mission-critical. Their role will not simply be to improve an underused opportunity; it will also be to help companies manage fundamental changes in how work is performed. Nufar agrees that companies should enable these users rather than shut them down merely because less-professional builders create risks. She recommends stronger infrastructure, guardrails, and training for more subject-matter experts, because they understand the right business problems even if they are not technology specialists. Asked whether champion training should emphasize current AI-building skills or internal communication and process, Nufar says both matter, but the building itself is comparatively easy to learn through tools, experimentation, and trial and error. The harder, more distinctive skills are evaluation, use-case selection, ROI, deployment, and the business-technology-people connections between an idea and a reliable organizational capability. Those durable playbooks matter even as models and tools change every quarter. The episode closes with Nufar promoting an AI champions boot camp and the host pointing listeners to the episode’s companion materials.