Artificial intelligence (AI) enablement is sitting at the top of nearly every learning team’s plate right now, and the hackathon has become a go-to move: gather everyone in a room, hand them the tools, let them build. It’s a genuinely good way to generate energy. The problem is that energy is not the same thing as enablement, and a build event on its own is not a learning strategy. The event is a single moment in time; whether it leaves behind durable capability depends almost entirely on what you build around it.

So when I was asked to design a “Claude-a-thon” for Workleap’s two-day in-person gathering in Montreal (more than 50 teams, over 300 participants), I stopped treating it as an event to run and started thinking of it as the centerpiece of an enablement arc that included what we did to prepare people beforehand, how we designed the event itself and what we built to reinforce it after. The build session was three and a half hours. The enablement around it spanned the weeks and months before and after the event and is still ongoing today.

Prepare Learners Before They Build

The biggest mistake I see in AI build events is treating the day itself as the learning. People show up cold, lose the first hour to “what does this even do,” and the gap between the confident and the hesitant only widens from there. The enablement needs to begin before anyone walks into the room.

In the weeks leading up to our event, we brought in an external company specializing in AI deployment and training to run two virtual workshops: one on Claude Cowork and the other on Claude Code, the tools our data showed were least used outside of our technical teams. The sessions were recorded and paired with cheat sheets, best-practice guides and tiered learning paths so participants could prepare at their own pace based on their experience level.

Then we shipped a starter kit ahead of the event. A single page pre-flight checklist prompted participants to log in, join the help channel and align with their team on the problem they want to work on before they arrive. We also shared the approved tools and connectors, copy-paste prompt starters and a bank of project ideas with one nudge attached: before you borrow an idea from the list, ask your team what’s the most repetitive or broken thing you deal with, because that’ll be the better project.

The goal was simple: protect the build time. The ones who knew the most about AI coming in wouldn’t necessarily have the advantage. Being prepared, regardless of starting point, was the key differentiator.

Give Teams Room to Learn

We deliberately under-orchestrated the build session.

It would have been easy to fill three and a half hours with a rigid agenda of checkpoints, mandatory stand-ups and a facilitator calling time every twenty minutes. We didn’t. Every team got the same single question to answer (“How can we optimize our operation and increase our velocity with AI?”) and was then left to manage their own time and approach.

Learning to work with AI is, in large part, learning to direct your own work with it: deciding what’s worth automating, scoping something you can finish in the time you have and knowing when to abandon an approach that isn’t working. You can’t lecture that into people; they have to run into the friction of it themselves. A heavily managed session might have produced neater demos, but weaker capability. Self-direction and judgment when using AI were the exact muscles we were trying to build.

What we offered instead was scaffolding they could pick up or ignore. For teams that wanted structure, we offered a ten-minute kickoff, a suggested “driver” role, pacing checkpoints and advice on cutting scope when time got tough. Teams that already knew how they wanted to work never utilized those materials. We also had six AI experts on site to act as coaches, and our direction to them was clear: “Hands off the keyboard.” Their role was to unblock, not to build.

Measuring Whether Learning Sticks

A build event like this rarely kicks off an organization’s AI adoption from zero; more often it accelerates a rollout already underway, and that distinction matters for how you measure impact.

Claude had already been rolled out across Workleap, and we were watching one simple, company-wide signal: how many people were using it. This gave us a clear baseline to measure against post-event. Thirty days post-event, the number of active users had increased 13% to nearly 100% of the of the business actively using their Claude licenses. We also saw an increase in Cowork and Code usage and a decrease in the number of users using Claude mainly as a chatbot. The number of users using multiple connectors, suggesting real integration with day-to-day work, also went up.

I won’t pretend the Claude-a-thon alone moved that line; adoption was already high and rising. An event like this works best when it’s a spike on a curve you’ve already started drawing, not the first mark on a blank page. If you can’t describe where you started, you can’t honestly claim a delta.

We also asked every team to commit to a number up front. Before building, each team logged a “bet:” the problem they were solving and the impact they expected if it worked. Afterward, they logged what actually shipped against that bet, and the space between those two numbers became one of the most useful things we captured. The templates we built to capture this information were designed to force specificity and avoid vague answers; for instance, “we saved time” was not an acceptable outcome. We required teams to commit to a number, even a rough one. That kept the event pointed at real bottlenecks rather than at experiments that were less likely to last.

Then we set the bar for “shipped” deliberately high. The only outcomes that we counted there were the ones that changed how a team works. Thirty days later, a handful had cleared that bar and were in genuine, recurring use. A few that stuck:

• A lightweight integration with our helpdesk tool that compresses incoming customer-conversation data by a median 8.5x, so analyses that used to require multiple Claude sessions now fit in one
• A data-migration converter that has already worked through 527 SQL files and 343 stored procedures — work that would have taken a four-person team roughly four months
• A cleanup agent that has cleared more than 30 stale feature flags in three weeks, at about 10 a week, roughly 70 tasks’ worth of cognitive load nobody has to carry now
• A pipeline auditor that gives sales reps a ranked follow-up list first thing every Monday, flagging which leads need attention now and which can be let go

Another signal that we noticed: some teams started merging their builds into shared, owned initiatives rather than keeping them as personal side projects. That kind of behavior is exactly what the research says separates the builds that go on to have real impact from the ones that die after the event.

And because AI enablement shouldn’t come at the expense of the people doing the work, we watched engagement alongside adoption. Thirty days out, the signals pointed the right way: eNPS ticked up, engagement held steady and favorability on whether leaders are communicating a motivating vision rose meaningfully. This is a key area that sometimes gets forgotten when measuring AI adoption and enablement: adoption bought at the expense of engagement isn’t really adoption; it’s an attrition risk that simply hasn’t surfaced yet.

Reinforce New Ways of Working

If the event is the spark, the weeks after it are where capability either compounds or evaporates. Two weeks after our in-person event, our co-founder and chief product and technology officer launched a new AI operating standard: a clear, organization-wide policy covering how we use these tools responsibly, including the security model everyone is expected to work within and an expectation that every team redesigns at least one workflow with AI each quarter. Because employees had just spent a day experiencing AI’s benefits and limitations firsthand, they were ready to apply the new governance standards.

But a policy nobody internalizes or operationalizes is just words on a page, so the piece we’re building now is an applied eLearning course. Instead of asking people to read rules and pass a quiz, we’re giving them realistic scenarios and asking them to apply the new policy and guidelines to make an actual call:

• Is this an appropriate use of the tool?
• What would you do here?
• Where’s the real risk in this workflow?

Scenario-based practice helps move a policy from something people have technically seen to something that shapes what they do under pressure, which is the entire point of enablement.

We’ve also built an “AI Judgment Coach” skill in Claude that people can use when they encounter situations in their real work where they’re not sure how to proceed. It doesn’t hand them the answer outright because the goal isn’t to have people memorize policy, it’s to build judgment. The skill helps them talk through challenges and operate within the guardrails — building their own muscle for judgment.

An Event Isn’t Enough — L&D Fills in the Gaps

AI enablement is not an event that you run; it’s a system that you design. The Claude-a-thon was the most visible day of that system, but it worked because of everything around it: the on-ramp that got people ready, a build session that made them direct their own learning, measurement honest enough to tell us what actually stuck and reinforcement that turned a day of energy into a standing expectation that AI shows up in everyday work.

Generating energy is the easy part; in L&D, our job is building capability that’s still in use, thirty, sixty, ninety days out, and that depends far more on the system around the event than on the event itself.