Nine Students, One Error, Forty Minutes Left
You are delivering a four-hour live online workshop to 22 attendees on a shared lab platform. Module 3 is a 45-minute hands-on exercise in which each attendee deploys a VM from a template and reconfigures its virtual hardware. At minute 20 of the module: six attendees have finished and are idle; nine are blocked by the same error, a task that fails at 91% with a datastore-space message; four have not started because the remote console would not launch in their browser; three have posted nothing at all. Chat is scrolling fast enough that the original instructions are already off-screen. You have a producer who can post links and run a poll but has no platform administrator rights, and an escalation engineer on standby. Two more modules remain on the agenda.
1. How do you spend the next ten minutes? Justify the order of operations.
Read the worked answer
Sequence by blast radius, not by who is loudest.
- Stop the bleeding (1 min). Broadcast one pinned message: "If you are stuck, do not retry - post your pod number." Every retry consumes more of the datastore that is already full, converting a recoverable problem into a dead lab.
- Confirm scope with the producer (2 min). A single poll gives you an accurate count in 30 seconds. Nine people with an identical 91% datastore error is one infrastructure fault, not nine learner faults.
- Escalate the single ticket (2 min). Give the escalation engineer the exact timestamp, the error text, and the affected pod numbers. You do not need admin rights; you need a precise report.
- Handle the console failures separately (2 min). That is client-side, and the producer can post the browser and plugin workaround without occupying you.
- Message the three silent attendees privately (1 min). Silence is the highest-risk signal; a direct message costs little and surfaces problems the room cannot see.
Do not debug one student on the main line. Address the whole class once, at minute 30, with a single consolidated update.
2. How would you use the six attendees who finished early without creating a two-tier class?
Read the worked answer
Give them work that extends the same objective rather than opening a new one, and make the output visible so the whole class benefits.
- Capture and share. Ask each of the six for a two-line note: which virtual hardware setting they changed, and the exact UI path or command that verified it. Pin the best three. This converts idle time into peer instruction, which is more credible than instructor repetition.
- Recruit two as helpers, but only for the mechanical task of walking the console-failure group through a published workaround. Do not make them substitute teachers; it embarrasses the stuck group and puts support quality out of your control.
- Offer a low-support stretch task: clone the VM and predict what happens to UUID and MAC handling before testing it. Same environment, no extra capacity, genuinely interesting.
What to avoid: more labs. Extra modules compete for the same trainer attention, widen the gap, and are precisely what makes the second half of the day unteachable. Extension work must be cheap to support and shareable with the room.
3. What structural changes would you make before delivering this workshop again?
Read the worked answer
Design the failure modes out, rather than planning to be faster at firefighting.
- Checkpoints instead of deadlines. Break the 45-minute exercise into four stages with a visible verification at each, so a student who is stuck is stuck for five minutes, not twenty. Checkpoints also surface infrastructure faults before the whole cohort hits them simultaneously.
- A pre-flight barrier. Ten minutes before the room opens, confirm the datastore has headroom, one pod can deploy successfully, and the console works on the current browser build. This exercise should never have reached 91% on a full datastore.
- Agenda headroom. Four hours of content with zero slack has no absorption capacity; build in a 10-minute buffer per half-day and nominate which exercise is cuttable in advance.
- Producer briefing. Give them pre-written pinned messages for the three most likely failures, and agree that all non-technical questions go to them.
- Protect the objective. The module objective is that every attendee sees a VM deploy and understands what changed. It does not require that each person deploys their own successful VM - a couplet arrangement achieves the objective in half the time.