What Repeated Workshops Taught Me About AI Adoption

The tools change between workshops. The human problems are remarkably consistent.

A new model launches, interfaces improve and a task that was difficult six months ago becomes straightforward. Yet teams still lose time on the same things: a vague problem, missing access, fear of looking slow, nobody empowered to decide and no owner after the session.

These are the lessons I now design around.

1. The quality of the problem shapes the whole room

“Explore AI” is not a workshop problem. “Reduce the time it takes support to turn repeated questions into a reviewed help article” might be. A good problem has a user, a current workflow, an owner and a visible definition of better.

When the brief is vague, teams spend their energy inventing a context. When it is too narrow, they merely follow instructions. The useful middle is a real constraint with room for judgement.

2. Confidence is uneven—and often invisible

In the same room, one participant may have shipped an agent while another is opening the tool for the first time. Job title is a poor predictor. If the format rewards speed alone, experienced builders take over and everybody else watches.

I use small teams, explicit roles and early checkpoints. The person framing the problem, testing the flow or documenting failures contributes as much as the fastest prompter.

3. Access is part of the curriculum

Logins, permissions, repositories, APIs and approved data are not administrative details. They determine what can be learned. A workshop that ignores access teaches participants how to build a demo in an artificial environment.

Test the setup before the event. Provide synthetic data where real data is inappropriate. Name what people may not upload. Prepare a fallback that preserves the learning objective.

4. People need help at different depths

One participant needs a better prompt. Another needs to understand state, authentication or an event schema. A single facilitator cannot support a large room at every level.

Create visible help routes: peer support inside teams, roaming mentors, a question queue and short interventions for issues affecting several groups. Avoid solving every problem on the main screen.

5. A deadline creates useful focus

The demo is not theatre when it changes how teams work. A fixed show-and-tell forces scope decisions. Teams stop polishing secondary screens and make the core path understandable.

The rule should be simple: show the working thing, the problem it addresses, what failed and what you would test next. A polished deck is optional.

6. Failure needs to be made discussable

AI tools fail in public. Integrations break. Generated code introduces a problem. The team discovers that its idea depends on data it cannot use. If the room treats those moments as embarrassment, people hide them.

Make recovery part of the method: observe, narrow, inspect, change one thing and retest. A documented stop decision is a valid outcome.

7. Leaders change the energy of the session

A leader who asks good questions, removes a blocker and accepts an imperfect demo creates permission to learn. A leader who arrives only for judging can turn the event into a performance.

The strongest leadership contribution is often a fast decision: yes, the team may test this workflow; no, that data is out of bounds; this person owns the follow-up.

8. The day after matters more than the closing photo

Every promising build should leave with an owner, a next test and a date. Without those three things, workshop energy dissolves into normal priorities.

• Owner: one person, not “the team”.

• Next test: a specific user, flow or technical risk.

• Date: close enough that the context remains alive.

• Decision: continue, adapt, integrate or stop.

9. Repetition beats a grand launch

One workshop can prove that a new way of working is possible. Repeated cycles create shared language, examples, mentors and governance patterns. Adoption grows when the second team can start from the first team’s learning.

That is why I think of workshops as part of an enablement system, not isolated events.

What I would protect if everything else had to go

• A real, owned problem.

• Time to build, not only discuss.

• Clear data and security boundaries.

• Support for mixed levels of confidence.

• A working demo that includes what failed.

• An owner and a dated next test.

For the full sequence, use the 90-day AI enablement plan. For a team session, explore workshops and buildathons.