Direct answer
Start from one measurable objective ("by the end you can do X on your own"), make at least half the time hands-on (the worked example below is 100 of 180 minutes, about 56 percent, with the rest on a demo, share-back and admin), design labs with known expected outputs plus facilitator notes for likely mistakes, and gather feedback in three ways: during, at the end and after two weeks. Send pre-work before and follow-up materials after so people can build a first piece independently.
Worked example: a 3-hour workshop, "read and act on a service dashboard" (illustrative)
Objectives: by the end each participant can (1) find the latency and error-rate panels (individual charts on the dashboard) for a service, (2) tell whether a spike lines up with a deployment (a release of new code to the live service), and (3) write a two-line status note for it.
Pre-work (30 minutes): install nothing new; open the sandbox dashboard link and check login works. A one-page glossary defines p95 latency (the response time that 95 percent of requests beat) and error rate.
| Time | Activity |
|---|
| 0:00-0:15 | Purpose, agenda, environment check |
| 0:15-0:35 | Demo: reading the dashboard, done live |
| 0:35-1:15 | Lab 1 |
| 1:15-1:25 | Break |
| 1:25-2:25 | Lab 2 |
| 2:25-2:50 | Share-back: two participants present, group critiques |
| 2:50-3:00 | Feedback form and next steps |
Lab 1: given a sample dashboard, find p95 latency for the checkout service in the last hour. Expected output: they report the value from the panel and the time window. Facilitator note: the most common mistake is reading average instead of p95; ask "what would a slow user see?"
Lab 2: a planted fault (a spike in errors at 14:05). Expected output: "error rate rose from about 1 to 8 percent at 14:05, matching the 14:03 deploy; suggest a rollback (going back to the previous version) and check logs." Facilitator note: if they blame the database, ask what evidence links it.
Evaluating participants' work
Use a rubric (a scoring guide) on the written status note, the short update a teammate who was not there would read:
| Criterion | 0 | 1 | 2 |
|---|
| Accuracy (numbers and time) | wrong | partly | correct |
| Evidence cited (deploy, panel) | none | vague | specific |
| Clarity for a reader who was not there | unclear | ok | clear in two lines |
Peer review: each person scores a neighbour's note against the rubric, then discusses. For a problem-solving and communication workshop, add rows for "states the next action" and "flags what is still unknown".
Feedback so the next run is better
- During: facilitator notes on where people got stuck and how long each lab really took.
- End: a 4-question form (one thing useful, one confusing, pace, confidence 1-5).
- Two weeks later: "Have you used this? What blocked you?", and follow-up materials (a checklist, the lab solutions, a starter template) for building a first piece alone.
Pitfalls
- Too much talking, too few labs.
- Labs with no expected output, so participants cannot tell if they are right.
- No timebox slack. If time runs short, shorten Lab 1 or limit the share-back to one presenter. Do not cut Lab 2: it is the only exercise that covers objectives 2 and 3 (linking a spike to a deployment and writing the status note), and cutting it would drop two of the three objectives.
