It's been a few years of intense talk about AI. Our feeling, at Offbeat, is that no matter how many LinkedIn posts, articles, podcast episodes, and webinars cover how L&D should be enabling colleagues to use AI, there's still not enough talk about what we're actually doing and what we're learning in the process.

The reason for the relative silence isn't that we aren't working on this. Even though L&D isn't usually the one driving AI adoption, we're involved one way or another. We think the real reason people delay sharing is that the process is messy, and so far there's no clear winning strategy.

There's so much nuance to AI that companies often change their minds about their statements and investments. And it doesn't feel great to share something publicly only to walk it back a few months later. But here's what isn't said enough: we're all in the same boat. Or at least in very similarly sized boats. So coming together to share how we're rowing the same waves might help all of us reach the other side faster, wiser, and more effectively.

That's why, a few months back, we set up L&D x AI Week: to bring L&D folks together to discuss the messy journey of supporting AI enablement. It wasn't easy to convince people to come forward, but thankfully 8 peers decided to be brave and share their experiences, lessons, and failures. We're grateful they did, and we're happy to share some of our reflections.

During L&D x AI Week, we hosted guest speakers from companies that are embracing AI overall and where L&D is involved in some way. We didn't cover companies that aren't open to AI adoption yet, or L&D teams that aren't involved at all. So if you're an L&D professional desperate to convince your stakeholders to adopt AI, the advice that follows might not apply to you. Otherwise, you'll find below the common threads we heard across the 8 sessions we hosted.

1. Diagnose where you are

Almost everyone who had made real progress started in the same unglamorous place. They found out what was actually happening before they designed anything.

How they did this looked a little different from company to company. 

• Several teams ran a dedicated AI survey across the whole organization. 
• One asked everyone to place themselves on a usage scale that ran from "yet to adopt" through "explorer," "generator," "integrator," and finally "solutioneer," meaning the people already building their own AI solutions. 

• Others added AI questions to an existing engagement survey, then moved to a standalone survey when a single question stopped being enough to make sense of thousands of comments. 
• A few also ran a "listening tour," which meant structured interviews with identified points of contact across business areas, using the same set of questions: "What are your objectives? What's blocking you? If I had magic powers, what would you ask for?" The survey gave them breadth and anonymity, and the listening tour gave them texture and faces.
• Almost everyone also cross-referenced what people said with the usage data pulled from admin panels and IT dashboards, and the two often told different stories. One speaker found that 57% of people said they used AI daily or weekly, but the actual usage data from IT painted a less rosy and already-outdated picture.

The thing to keep in mind is that survey data, in one speaker's words, "becomes old very fast." Some questions stay fairly stable, like how people feel about their jobs or about AI's environmental impact. But anything about usage or tooling is a snapshot of a single moment, and that moment passes quickly. So be clear with yourself about which questions you're asking for a lasting baseline and which ones are just a temperature check, and plan to run them again.

2. Define what AI capability looks like

Once you know where people are, the next question is where you're trying to get them. Several speakers warned about the trap of the vague mandate. One described a CEO who kept saying "do more with AI," which added pressure but no clarity. More of what? Another pointed to well-known companies that briefly tied performance reviews to the sheer quantity of AI usage, then quietly walked it back when people reasonably asked whether they were supposed to use AI just for the sake of it.

The teams that avoided this defined capability at two levels.

At the organizational level, a shared maturity model gave everyone a common language. One company used a seven-stage scale that ran from basic awareness through to full transformation, honestly placed themselves between stages four and five, and set a goal of reaching six and seven. The model itself wasn't magic. What helped was that, in the speaker's words, "instead of saying we need more AI training, we could say we want to move from stage three to stage four," and everyone understood the specific gap that implied.

At the individual level, the strongest example was a company that published a fluency framework describing what good looked like for every single role, not just at a high, abstract level. People could see exactly what competence meant for their own job.

There's a simple point underneath all of this, raised in more than one session. You can't have the behavior-change conversation until you've defined the behaviors. And the frameworks that lasted described behaviors, not tools, things like framing a task, giving context, and evaluating an output. Those skills carry over across Claude, Gemini, ChatGPT, and whatever other tool will be launched in the future.

This shared language only works if it lives inside your existing people processes. The companies that made it stick wove AI into performance conversations, career frameworks, and hiring. One added AI as a core competency to performance reviews precisely so that a manager and employee would sit down and ask, "How are you using AI? What's working? How can I support you?" That moved it out of the "another L&D initiative" bucket and into a real, forward-looking conversation.

3. Run labs, not workshops

If there was a single most-repeated idea across the week, this was it.

One speaker built his entire talk around the image of teaching a child to ride a bike. You don't do it by handing over a manual on balance, or a lecture on physics, or a diagram of the handlebars. You put them on the bike, on soft grass, with someone running alongside encouraging them. Learning starts when they wobble, fall, adjust, and try again. The argument was that principles, safety, and tool knowledge all matter, but behavior actually changes in the practice environment.

The contrast drawn again and again was "a launch versus a lab." A launch says: here's the tool, here's the training, go use it. A lab says: bring in a real workflow, test the tool against it, get support, learn from the output. One team described exactly how their lab ran. They centered it on a strong "how might we" question, brought in coaches who were domain experts (HR professionals who happened to know the tools, rather than technical trainers showing generic prompts), broke people into small groups by similar workflow, and had each group pick one of their own messy, real challenges and iterate on it live. Talent acquisition worked on job descriptions, total rewards worked on summarizing dense benchmark reports, and comms worked on matching an executive's voice. Each group's work looked completely different, because their workflows were different.

This connects to a warning several people raised: don't treat AI like another piece of software. As one speaker put it, "this isn't HubSpot." A normal tool you teach by showing which buttons to click. AI is exploratory, and the hardest parts happen before anyone touches the interface, when you're deciding what problem to solve and why. The cautionary tale was a large rollout of a thousand licenses where people liked the tool but it didn't move the needle, possibly because it was taught like software rather than like a new way of thinking.

The lab doesn't need to be elaborate. You can start with one team, one session, and two or three workflows. The non-negotiable part is supported practice on real work.

4. Build a recurring rhythm

A lab gets people on the bike once. A rhythm keeps them pedaling.

The phrase that captured it was that AI capability is "a habit sport." You don't learn to ride a bike from a workshop, and you don't change how you work from one either. A one-off workshop followed by silence gives you a sense of activity, but it rarely changes how people actually work day to day. One large professional-services firm shared that it had stopped relying on its old style of scheduled, classroom-based training, because the work was changing too fast for a course planned weeks in advance to stay relevant by the time people sat through it.

What worked instead was cadence. The standout example was a biweekly, 30-minute session at lunchtime, dropped into everyone's calendar, opt-in, hosted by internal colleagues sharing real use cases. It pulled 150 to 200 people per session and stayed steady across a year. Tellingly, teams started running their own versions in the off weeks, going deeper on their specific use cases. The format deliberately stripped away structure, with no mandatory slide template, no review-and-approval process, and no required learning objectives. That lightness was the point, because it let people who'd never presented before share something useful without friction.

Alongside the steady drumbeat, teams layered other rhythms. Some ran a monthly "expert corner" deep dive (one had the VP of sustainability lined up to address environmental-impact concerns), a monthly newsletter, and occasional intensive bursts. One team ran a two-week "AI Summer School," with a session every day at lunch, and around 300 people dialed in daily despite it being vacation season. Another took an all-company learning day and turned it into a single AI hackathon.

The takeaway here is practical. People build new habits through repetition, not through a single big event, so put a small, regular slot on the calendar and keep showing up in it, rather than treating a one-time launch as the finish line.

5. Make space for the hard questions

This was the quietest thread of the week, and probably the most honest.

One speaker named it directly as the thing they didn't do well. They never addressed "the elephant in the room," which is "Will AI take my job?" They admitted it's genuinely hard, because there often isn't a clean, reassuring answer. But it kept coming up across teams, and ignoring it didn't make it go away.

Others described the emotional reality their people were carrying. When asked how their colleagues felt about AI, audiences offered a full spectrum in the same breath: excited and scared, curious and nervous. One company with 100% tool adoption still reported "a healthy amount of skepticism," with about a quarter not trusting the outputs and about half holding serious ethical concerns. Another framed AI not as a tool but as "a new teammate," which reframes the question from "what can it do" to "who am I becoming when I work alongside it."

A note of caution on that last point, since it sits outside what we covered during the week. How we talk about AI, and especially whether we describe it in human terms, is a genuinely researched and sensitive topic. Language like "teammate" or "colleague" can help people relate to the tools and lower their fear, but it can also quietly shift how much people trust, defer to, or over-rely on a system that is not, in fact, a person. We'd encourage you to use this kind of framing thoughtfully rather than as a default, and to stay aware that it carries more weight than it first appears.

The shift several speakers pointed toward was from "How do I do this faster?" to "Why am I doing this at all?" and, by extension, "How will my role change?" One speaker reflected that people are "losing their professional identities," including managers, and that leadership programs now need to help people navigate ambiguity, not just learn features. Another felt we may have rushed past reflection. We went hard on "let's use AI," which is great, but we gave people little room to process where humans still make the difference and where their work is genuinely shifting.

You don't need a perfect answer. You need to create room in your programs for the question to be asked out loud, without judgment. When that room is missing, people notice, and the silence tends to make them more anxious rather than less.

6. Activate leadership

Everyone agreed leaders matter. The interesting part was how honest people were about why this is hard and what actually works.

The recurring failure mode was leaders who sponsor AI but don't use it. One survey of thousands of executives found many used it only around 1.5 hours a week, with roughly a quarter not using it at all, which is a wide gap between what they declared a strategic priority and what they personally did. As one speaker put it, leaders modeling adoption matters more than leaders endorsing it. The research several cited points the same way: teams whose leaders actively use AI adopt it faster. "What you do matters more than what you say."

The obstacle often isn't unwillingness. It's that very senior people don't want to raise their hand and admit they need help learning. So the tactics that worked were designed around that sensitivity.

• Private 1:1 coaching. Several teams invested office hours coaching individual executives away from the crowd. The turning point was almost always value. The moment a leader built their own "thought partner" or got an AI-generated daily brief of their inbox and open action items, "it opened their eyes."
• Tiered programs by seniority. One company designed distinct tracks: an exercise for the executive committee on rebuilding the company from scratch if AI disrupted the model, a track for VPs on how to set and lead a strategy, and one for managers on how to enable their teams to adopt. Different levels of complexity, same direction.
• Space to share their own learning, not their results. One CEO openly shared what they'd tried over a weekend. Another company explicitly asked its executive team to model being on a learning journey, with the message "we're also just learning here," rather than performing mastery. At this stage the goal is establishing a learning culture, not showing off outcomes.

The most vivid example came from a team that live-coached their head of strategy on stage, building an agent in front of 500 leaders, then had material ready so every leader in the room could start building immediately. The demand that followed ("come live-coach me in front of my team") became a bridge to far wider adoption.

7. Map who owns what

A clear theme across the week was that AI enablement is not an L&D project. It's a change-management effort, and L&D usually can't and shouldn't own all of it.

The most useful mental model came from a speaker who listed the pillars that have to be owned by someone: the tech stack and tools, process and governance (policy, security, privacy), the knowledge hub and communication, the people and champions, and the actual AI solutions teams build. Their team owned the people-and-champions pillar and acted as a partner on the rest.

The strongest partnership pattern was L&D, or the people function, working hand in glove with the tech or IT side. One company described a "very strong partnership" between the talent-development team and an automation-and-empowerment team in the tech org, and credited it as crucial. The tech side did the heavy lifting on systems, agents, and connectivity, while L&D drove the human layer. Another put it bluntly: "we would have gone nowhere without the collaboration with IT and the people in our business."

There's a related lesson worth flagging. One speaker pointed out that they could build the best learning offer in the world, but if people didn't know how to request the tool, or if the policy to get access "takes six months," or if managers didn't give people time, the learning "lands nowhere." So part of orchestrating is having the standing to nudge other parts of the org, for example by flagging that the tool-request process is confusing, even when those things aren't strictly L&D's job.

There was also healthy honesty about what L&D should refuse to own. One team was clear that they would never run a training on AI's environmental impact or on what AI means for job security. Those belong to senior leadership and to ethics and compliance. L&D could amplify the message and surface the questions, but owning answers it isn't positioned to give would be a mistake.

So map ownership of tooling, policy, governance, comms, and manager enablement explicitly. Aim to be the orchestrator, not the sole owner.

8. Protect learning hours

A small, concrete, repeatedly-confirmed lesson: people don't experiment because they don't have time, and goodwill alone won't fix that.

"Lack of time" came up as a top blocker in nearly every survey discussed. One put it at 28% of respondents, and the speaker suspected they were underestimating it. People aren't resisting AI. They're at 120% capacity already, and "then you want them to learn AI too."

The teams that took this seriously made dedicated learning time an explicit policy and made managers accountable for protecting it. One company ran a "Five Days of Development" policy, not a rigid quota, but a clear signal that you can take the time and that managers are expected to ring-fence it. When the AI survey surfaced the time complaint, they ran a dedicated campaign to push that policy front and center again. Another increased their learning-time allowance from four hours a quarter to twelve, required that six of those be spent on AI, tracked it in their HRIS, and counted attendance at their AI sessions toward it, which lowered the barrier to entry. They actually overachieved the goal, hitting 124% of target, which only happens when the permission is real and visible.

A few speakers admired companies that go further and literally block "building time" on calendars, though several hadn't tried it yet.

The principle is simple. If you want experimentation, you have to fund it in the only currency that's actually scarce, which is time, and you have to make managers responsible for honoring it.

9. Activate champions in every function

You cannot personally enable thousands of people across dozens of functions, time zones, and languages. The teams that scaled did it through champions.

The pattern was to identify the people already experimenting, give them a more intensive program and a platform, and let them run local initiatives in their own departments. One company built a "builders" bootcamp for non-technical AI champions across functions, meaning people who don't write code but become the builders for their teams. The bootcamp was relentlessly hands-on, so you build something real by the end rather than just understanding the theory, and it produced around 45 active AI initiatives and a community that runs demo days and becomes the go-to support for their colleagues. Demand to join was so high they "had to stop" people.

This works for two reasons that came up explicitly. First, champions know their own function's workflows, so the use cases they build have real business impact. They "know what they need, what's working, what's not." Second, it solves the visibility problem. In one company's words, individual experimentation without sharing means you "rediscover a great technique over and over," two steps forward and three steps back. Champions surface and spread what's working.

Several teams also leaned on a voluntary, open-to-everyone network alongside the smaller expert community. One had 300 to 400 members acting as a feedback loop on the ground, translating for their business areas and helping build new initiatives. The two layers complemented each other, with a tight expert group that builds and a broad network that spreads and reports back.

A related design choice is worth stealing. Champions made excellent subject-matter experts when designing the broader programs. One team pulled three or four SMEs from each function to bring the real use cases, challenges, and data that made the general sessions resonate.

10. Make learning visible

If experimentation happens in private, the organization can't learn from it. Making learning visible was a deliberate strategy, not an afterthought.

The infrastructure most teams converged on looked remarkably similar.

• A single knowledge hub as an anchor, described by one speaker as "a one-stop shop, no confusion." One company built theirs to be the central home where policy, governance, opportunities, curated resources, and key contacts all lived together, deliberately not as a separate entity. Several later restructured these hubs to be more AI-searchable.
• An active community channel (usually Slack or Teams) that is "not a ghost town."
• A monthly newsletter. One team built theirs end to end with AI, which kept the effort low and modeled the behavior at the same time. It shared internal use cases, team spotlights, and which tools people were using.
• Company-wide moments where leaders address AI directly, like all-hands, town halls, and QBRs. One speaker's recommendation was to build "we're going to talk about AI adoption" into the team's regular rhythm.

The thing that turns this from nice comms into real strategy is that peer learning is what people actually want. In one survey, over half of respondents said they wanted to learn from their peers. When a company finally got teams together across functions to share how they each used AI, it was "illuminating." One team's approach unlocked something for others, and it directly led to new tools being adopted into client work. None of that happens if everyone learns alone.

Some teams added light gamification, like badging or "belt" systems, to make the conversation part of how the company talks. The mechanism matters less than the commitment, which is to surface the learning, repeatedly, where everyone can see it.

11. Track what actually matters

The week was refreshingly humble about measurement. Everyone agreed it's hard, nobody claimed to have nailed it, and one speaker simply said L&D measurement in general "is very hard," and made peace with that.

The shared diagnosis was the gap between usage and capability. As one participant noted, most AI measurement tracks usage, not capability. Plenty of teams could report inputs, like the number of workshops, licenses handed out, or completion rates, but inputs aren't outcomes. Several speakers were openly skeptical of completion as a metric. If 95% of your company "completed" something, one argued, your bar isn't high enough, because real, useful learning is hard and that number is unrealistic unless the exercise was trivial.

What the more advanced teams tracked instead:

• Stage progression. Are people moving along the maturity model or fluency levels you defined back in lesson 2? The goal was to see the whole distribution shift "to the right."
• Things created, not things completed. One company tracked how many people had built their own assistants or agents. It's an imperfect proxy, but far more telling than a click at the end of a course. The reframe was "creation, not completion."
• Use cases shared. This meant the size of the library of reusable assistants, prompts, and workflows people contributed.
• Validated quality changes. Several teams sourced this from clients, who reported quality gains rather than the company grading itself. One reported clients telling them quality had roughly doubled.
• Confidence lift, measured before and after. One team was proud of a roughly 29% confidence increase, captured by asking before and after.

The most-cited piece of advice on measurement was that you can't prove you moved if you never measured where you started. So establish a baseline, which loops right back to lesson 1, and define the real behaviors that signal fluency rather than relying on self-reported impressions. Several speakers pointed to published fluency research as a way to identify which concrete behaviors are worth tracking, and accepted that even the best instruments only capture a subset of what matters.

The honest bottom line is to aim for capability, behavior, and results, not activity. You won't get it perfect. Get a baseline, track the right direction of travel, and keep iterating.

A closing thought

If you read these eleven lessons looking for a sequence, where you first diagnose, then define, then run labs, and so on, you'll be slightly misled, and several of our speakers would gently push back. The work isn't linear. It's a loop: diagnose, set expectations, build capability, support implementation, then go back and diagnose again, because the ground has moved. One speaker's whole framework put experimentation in the middle of an infinity loop, on purpose.

What unites the eleven is a single shift in posture. The teams making progress stopped treating AI enablement as content to be delivered and started treating it as conditions to be created: the lab, the rhythm, the protected time, the champions, the visible learning, and the honest space for hard questions. As one speaker described their own change, they spent the year "architecting the conditions" for others to bring the content, rather than building all the content themselves.

And maybe that's the most reassuring takeaway from a week full of people admitting they hadn't figured it out. Nobody has a finished playbook, because the thing we're enabling people to do keeps changing. So the real capability, for our colleagues and for us, isn't mastery of any one tool. It's the ability to keep learning, together, as the waves keep coming.

We're grateful to the eight peers who came forward to share. We're all in similarly sized boats. The more we compare notes on how we're rowing, the faster we all get across.