# Enablement workshops fail in the lab, not on the slides

> A two-hour lesson plan with two goals, a lab tested by an outsider, and homework that feeds straight into the client's own project.

Original: https://fdetimes.net/en/guides/enablement-workshop-lab-design/

Handover is two weeks away. The agent you built is running on the client's data, and their manager sends a message: "Could you run a workshop for our AI team? About two hours." The team has five or six engineers, and after this session they will be the ones fixing prompts, adding tests and handling incidents.

If your first move is to open PowerPoint, think again. Two hours of lecture will not help anyone fix the agent alone at 2am. The session succeeds or fails in the lab, and in what you prepare for the days after it.

This skill matters more than it is usually given credit for. A deployment is only truly finished when the client's team can stand on its own, and the enablement workshop is where you hand that capability back to them.

Do it well and you are free to move on to the next project. Do it badly and a month later you are still the only person who dares touch the system.

## How much fits into two hours?

PreSales Collective notes that technical workshops for customers can be as short as a one-hour lunch-and-learn or run to a full day of instructor-led training. Two hours sits in the middle: enough for everyone to do the work by hand once, but too short to teach everything you know.

So the first job is to cut. Maven's guide to running workshops advises building each session around 2-3 core learning goals. In two hours, two goals is the safe number, because each one needs both explanation and hands-on time.

Picture the AI team at an insurance company about to take over an agent that classifies claims. You could teach them the architecture, model selection, the vector store, cost monitoring.

But on handover day they need only two things. First, to fix the prompt when the agent misclassifies. Second, to add a test case to the eval suite so that error does not come back. Everything else can live in the documentation.

Write goals as things learners can do, not things they "understand". "By the time they leave the room, each person can fix a misclassifying prompt and prove it with the eval" is a goal you can check. "Understand prompt engineering" is not.

## A 120-minute lesson plan, block by block

PreSales Collective stresses that a workshop needs a thoroughly tested lab environment, along with a curriculum and learning goals planned in advance. Below is a sample minute-by-minute plan for the insurance team in the example.

| Minutes | Block | What learners do |
|---|---|---|
| 0-10 | Opening and backstory | Look at a claim the agent misclassified, guess why |
| 10-30 | Goal 1: read and fix the prompt | Follow the demo, answer quick questions after each step |
| 30-55 | Lab 1 | Fix the prompt for three misclassified claims, rerun |
| 55-65 | Break | Anyone stuck meets a helper |
| 65-80 | Goal 2: add a test to the eval | Follow the demo, line by line |
| 80-100 | Lab 2 | Turn the Lab 1 error into a test case, run the eval suite |
| 100-108 | Homework handout | Receive the task, the data, the deadline |
| 108-120 | Structured Q&A | Questions collected through the session, answered by theme |

Note that even the demo blocks must not be monologues. Maven advises changing state roughly every 3-5 minutes, with a question, a group discussion or a breakout, so the session does not drift into a one-way lecture.

So in a 20-minute demo you will stop four to six times to ask something like: "If we change this line, how do you think the output will change?"

Questions, by contrast, are collected for the end. Maven recommends reserving a structured Q&A slot at the close of the workshop. During the labs, people post questions in a shared channel; at minute 108 you group them by topic and answer them in one pass, which neither interrupts the labs nor lets any question slip.

## A lab needs a story, not just a list of steps

Skillable's material on designing hands-on labs separates two things. Learning goals, tasks and outcomes are there to guide the lab author. The backstory is for the learner: it gives them a reason to start.

For the insurance team, the backstory is already in the project: "Monday morning, the claims department reports that the agent filed three flood-damage claims under car accidents. You have 25 minutes before your meeting with them."

Those three claims should come from real errors during the deployment, anonymised. Learners will see at once that this is the work they are about to do, not an exercise for its own sake.

If you need a template, look at the interactive prompt engineering tutorial Anthropic has published on GitHub. It has nine chapters, each with a lesson and a set of exercises. Each lesson ends with an "Example Playground" where learners can freely try out the examples, and there is a separate answer key for instructors.

All three features are worth copying. The lesson-then-exercise structure gives each lab block a clear start and finish, the playground keeps early finishers engaged, and the separate answer key lets you or a colleague help someone who is stuck without having to think on the spot.

One more detail. The tutorial also comes in a Google Sheets version, which its authors recommend as the easier one to use. If the room includes business specialists or QA staff who are not used to notebooks, a lab that runs on a tool they already know can decide whether they "do it" or merely "watch".

**Key point:** Learners do not remember your slides; they remember the first time they made the system work with their own hands.

## Test the lab as a stranger would

Skillable warns that internal self-testing is not the same as the learner's experience, and that proper testing takes time and close attention to every detail.

You know the system by heart, so you do not trip where newcomers will: an API key not yet issued, no read access to the bucket, mismatched library versions, an environment variable that exists only on your machine.

The practical approach is to hand the lab to someone who has never seen the project, on a clean machine, with exactly the kind of account the client will use. Explain nothing. Every time they have to ask you something is a line to add to the instructions.

Do this at least a few days before the session, so there is still time to request access from the client's side.

Another format worth knowing: UNC-Chapel Hill once ran a 90-minute hands-on workshop in which attendees played the role of FDEs and built a prototype for a real customer problem. The shorter the workshop, the more the environment has to be ready in advance, because there is not a minute to spare for setup.

## Homework is the second half of the session

PreSales Collective advises having the next step ready for workshop attendees. For an FDE, that next step should be homework on the client's real data, due on the day of the next check-in.

For the insurance team, the homework might be: each person takes five claims misclassified during the week, fixes the prompt for at least one case, adds the matching test case to the eval suite and opens a pull request.

The following week's check-in is spent reviewing those pull requests, and from them you learn who can now stand alone and who needs an extra one-to-one session.

## The mistakes that waste two hours

The most common mistake is cramming goals: four or five topics, labs squeezed to ten minutes, and nobody finishes. Almost as common is being the only person who has run the lab, then losing the first half hour of the session untangling access rights. Then there is lecturing for twenty minutes without a pause, exactly the monologue Maven advises against.

Two mistakes are harder to spot. Letting questions interrupt constantly breaks the concentration of people working on the lab. And ending the session without assigning any follow-up means what was just learned fades before the first time it is needed.

On the career side: when reading FDE job descriptions, look for lines about training or handing over to customers, because that is this skill.

When writing your CV, do not just put "ran customer training". Say which team you taught, what the learning goals were, and what they could do on their own afterwards that they previously had to ask you for.

The real test of an enablement workshop is not the feedback form at the end. It is the first time the agent fails after you have left, and the client's team fixes it before they even think of calling you.

**Try this week:**

- Write down two learning goals for your next handover. Each should start with a verb describing what learners can do when they leave the room.
- Give your lab to a colleague who has never seen the project, explain nothing, and note every place they get stuck.
- Draft a homework assignment with one task, one set of the client's real data and a deadline that falls on the next check-in.

## Sources

- [Building Champions with Technical Workshops (PreSales Collective)](https://www.presalescollective.com/content/building-champions-with-technical-workshops)

- [Guide to running a great workshop (Maven Help)](https://help.maven.com/en/articles/14060754-guide-to-running-a-great-workshop)

- [Building Successful Hands-on Labs (Skillable Docs)](https://docs.skillable.com/docs/building-successful-hand-on-labs)

- [anthropics/prompt-eng-interactive-tutorial (GitHub)](https://github.com/anthropics/prompt-eng-interactive-tutorial)

- [Become an AI-Augmented Forward Deployed Engineer (UNC Junction)](https://junction.unc.edu/event/become-an-ai-augmented-forward-deployed-engineer/)