Facilitate live and virtual sessions, build onboarding programs and an LMS course, and prove what your training changed.

Training Delivery & Evaluation

Write one objective for the activity and prepare four to six realistic example cards or tickets.

Write the setup on a card or slide: purpose, task, output, groups, time.

Plan three debrief questions: one What?, one So what?, one Now what?

Run the setup and ask one person to repeat the task back before starting the clock.

While they work, circulate, listen and note one disagreement or surprise to raise in the debrief. Do not take over.

Run the debrief with your three questions. After each question, wait at least five seconds before saying anything.

Close by connecting the group's insights to your objective and writing them where everyone can see.

Ask each participant for one thing that helped and one thing to change.

## Why it matters

A well-designed lesson can still fall flat in the room. Facilitation is the skill of running the session so that learners do the thinking: setting up activities clearly, managing time and energy, asking questions that make people reason, and, above all, **debriefing** so an activity turns into learning instead of just an experience.

Throughout this course we follow one example: **a technical trainer at a software company onboarding new support engineers onto the company's incident-response tool** (opening incidents, setting severity, escalating, and writing the post-incident summary).

## Trainer, presenter, facilitator

A presenter transmits information. A facilitator designs and guides an experience where learners work things out, then helps them make sense of it. Good technical trainers switch between both: a short explanation, then an activity, then a debrief. A useful rule of thumb from instructional practice (and consistent with Barak Rosenshine's *Principles of Instruction*, 2012) is to present new material in small steps and check understanding often, rather than lecturing for long stretches.

## Setting up an activity

Most failed activities fail in the first minute because instructions were unclear. A reliable setup:

1. **Purpose:** "This will help you decide severity under time pressure."
2. **Task:** what to do, in one or two sentences.
3. **Output:** what they will have at the end ("one severity choice per ticket, with a one-line reason").
4. **Groups and roles:** who works with whom; who records.
5. **Time:** "You have eight minutes."
6. **Check:** ask one person to repeat the task back before you start the clock.

Put the instructions on a slide or card so people can refer back to them.

Example activity for our support engineers: each pair gets five realistic incident tickets and must assign severity (SEV1 to SEV4) using the company's severity matrix.

## During the activity

- Circulate and listen; do not hover or take over.
- Note interesting disagreements to use in the debrief ("Pair 3 rated ticket C as SEV2, pair 5 as SEV4").
- Give time warnings ("two minutes left").
- If most groups are stuck on the same thing, pause everyone for a 30-second clarification instead of repeating it to each group.

## The debrief

David Kolb's **experiential learning cycle** (1984) describes learning from experience as a loop: concrete experience, reflective observation, abstract conceptualization (drawing general lessons), and active experimentation (trying them out). An activity gives the experience; the debrief does the rest.

A simple, widely used structure is **What? So what? Now what?** (associated with Terry Borton's 1970 work and developed by Gary Rolfe and colleagues in 2001):

| Stage | Purpose | Example questions |
|---|---|---|
| What? | Describe what happened | "Which tickets did pairs disagree on?" "What information did you look for first?" |
| So what? | Make sense of it | "Why did ticket C split the room?" "What does the severity matrix assume that the ticket did not tell you?" |
| Now what? | Apply it | "What will you check first on your next live ticket?" "What would you ask the customer?" |

Close by connecting the insights to the objective, and capture them where learners can see them.

## Questioning techniques

- **Open questions** ("What made you choose SEV2?") beat closed ones ("Was it SEV2?").
- **Wait time:** Mary Budd Rowe's research found that when teachers waited about three seconds or more after a question, students gave longer, more thoughtful answers and more of them answered. Count silently to five before rescuing the silence.
- **No hands up, then cold call kindly:** give everyone think time, then invite specific people, or have pairs agree an answer first so no one is exposed alone.
- **Redirect:** answer a question with "What do others think?" when the group can work it out.

## Psychological safety

People learn less when they are afraid to look wrong. Amy Edmondson (1999) described **psychological safety** as a shared belief that a team is safe for interpersonal risk-taking. In training, you build it by treating wrong answers as useful data ("Great, that's exactly the trap the matrix has"), admitting your own mistakes, and keeping practice low stakes. Avoid putting individuals on the spot in front of their manager.

## Handling common situations

- **One person dominates:** "Thanks, let's hear from someone who hasn't spoken yet", or switch to pair or written responses.
- **Silence:** rephrase the question, give a minute to write first, or ask pairs to discuss.
- **An expert challenges you:** acknowledge it, ask them to share their experience, and if the point is valid, say so.
- **Running late:** cut content, not the debrief. The debrief is where learning is consolidated.

## Common mistakes

- Unclear instructions, then repeating them group by group.
- Skipping the debrief because time ran out.
- Asking "Any questions?" and moving on after one second.
- Answering your own questions.

## Quick recap

- Set up activities with purpose, task, output, groups, time and a check.
- Debrief every activity: What? So what? Now what?
- Use open questions and real wait time.
- Build psychological safety so people risk being wrong.

## Try it

On the Do tab, run a short activity with a debrief for a small group.


Set up an activity clearly, ask questions that make people think, and debrief with What? So what? Now what?

Facilitation skills

Facilitator Skills: How To Run An Effective Debrief - Facilitator Tips Episode 32

Facilitator Skills: How To Ask Good Debriefing Questions - Facilitator Tips Episode 47

Write the task's goal and break it into four to seven steps. Note the decision you make at each step and why.

Prepare a clean practice setup you can reset, increase font size, and turn off notifications.

I do: demonstrate while thinking aloud, explaining your decisions. Ask at least two 'what do you predict happens next?' questions.

We do: do a similar example together, with the learner telling you each step before you do it.

You do: give a new, similar example for the learner to do while you watch without taking over. Prompt with questions, not answers.

Check: give one final example for them to do alone. Note whether they succeeded and where they hesitated.

If they struggled in 'we do' or 'you do', go back one stage with a smaller step and try again.

Write a one-page job aid with the steps and the decision rules they found hardest.

## Why it matters

Technical skills are learned by doing, but beginners cannot do much until they have seen how an expert approaches the task. A live demo can be the clearest part of a session or the most confusing: too fast, too small to read, full of shortcuts the trainer does not even notice. Combining a well-run demo with structured, gradually released practice is the core method of technical training.

## Make expert thinking visible

Experts work largely on autopilot. Allan Collins, John Seely Brown and Susan Newman (1989) proposed **cognitive apprenticeship** to address this: the expert **models** the task while **thinking aloud**, then **coaches** and **scaffolds** the learner's attempts, and gradually **fades** support. Learners **articulate** their reasoning and **reflect** on it.

The key move is the think-aloud: say *why*, not just *what*.

- Silent demo: opens incident, picks SEV2, assigns team.
- Think-aloud demo: "First I check if customers are affected. The alert says checkout errors at 8%, so yes. Is there a workaround? No. Our matrix says customer-facing with no workaround is SEV2 unless revenue is fully down, so SEV2. Now I page the on-call for payments, because that's the service in the alert."

## Gradual release: I do, we do, you do

P. David Pearson and Margaret Gallagher (1983) described the **gradual release of responsibility**, often summarized as:

1. **I do:** the trainer demonstrates with think-aloud.
2. **We do:** the group does a similar task together, the trainer guiding and asking learners to predict each step.
3. **You do together:** pairs do a new task while the trainer circulates.
4. **You do alone:** each learner does a task independently, ideally with a check at the end.

Rosenshine's *Principles of Instruction* (2012) adds a useful target for guided practice: aim for a high success rate (he suggests around 80%) before moving to independent work. If most people are failing in "we do", go back to "I do" with a smaller step.

## Running the live demo

**Prepare:**
- Use a clean practice environment (a training tenant, sandbox or test account), never production or real customer data.
- Increase font size and zoom; close notifications; use a high-contrast theme.
- Script the demo steps, and have a recorded or screenshot fallback in case the tool or network fails.
- Reset the environment so it starts the same every time.

**During:**
- Say what you are about to do before you do it, then do it slowly.
- Narrate where you are clicking ("the Severity dropdown, top right").
- Avoid keyboard shortcuts, or say them out loud.
- Pause after each step and ask a prediction question: "What do you think happens when I set SEV1?"
- If something goes wrong, use it: diagnose out loud. Learners will hit the same errors.

## Practice structures that help

**PRIMM.** For programming and scripting, Sue Sentance and colleagues developed **PRIMM**: *Predict* what code will do, *Run* it, *Investigate* it with questions, *Modify* it, and then *Make* something new. The same idea works for tools: predict what a configuration change will do, try it in the sandbox, investigate the result, change it, then build your own.

**Faded worked examples.** Give a fully worked incident write-up, then one with the timeline missing, then one with only the headings.

**Parsons problems.** For procedures and code, give learners the correct steps in a scrambled order to arrange. Dale Parsons and Patricia Haden (2006) introduced them for programming; they reduce load because learners focus on structure rather than recall.

## A 30-minute technical segment, end to end

| Minutes | Step |
|---|---|
| 0–3 | Goal and why it matters ("By the end, you'll open and escalate a SEV2 correctly") |
| 3–10 | I do: think-aloud demo with two prediction questions |
| 10–15 | We do: group opens a second incident, learners call out each step |
| 15–25 | You do together: pairs handle a third scenario in the sandbox |
| 25–30 | Quick independent check: each person opens one incident; trainer reviews them |

## Common mistakes

- Demoing too fast with tiny text.
- Showing the happy path only, so learners are lost at the first error.
- Long demo, then "now you try everything".
- Demoing in production or with real data.
- Moving to independent practice when most learners are still failing.

## Quick recap

- Model with a think-aloud so expert decisions are visible.
- I do, we do, you do together, you do alone.
- Prepare a clean, resettable environment and a fallback.
- Use predictions, PRIMM, faded examples and Parsons problems for practice.

## Try it

On the Do tab, run a live demo with guided practice for one or two learners.


Run a think-aloud live demo and move learners from guided to independent practice.

Teaching technical skills

HOW TO USE THE “I DO-WE DO-YOU DO” TEACHING MODEL/ GRADUAL RELEASE

Computing Pedagogy: PRIMM

Plan the session in five-minute blocks, with a learner interaction in every block (chat, poll, reaction, unmute or breakout).

Prepare one chat waterfall question, one poll and one small-group or pair task with written instructions you can paste into chat.

Send the agenda and any materials at least a day before.

Join ten minutes early, test audio and screen share, and turn on live captions if the tool has them.

Open with a tech check and a warm-up question in chat. Get the first real interaction within five minutes.

Run the session. Invite cameras but do not require them; call on people by name with warning.

Debrief the small-group task with everyone before closing.

End with a one-question poll or chat prompt: 'What will you try first?' Ask for one improvement for next time.

## Why it matters

Much technical training now happens on video calls: distributed teams, customers in other countries, people who cannot travel. A virtual session that is a lecture with cameras off loses people within minutes to email and chat. Good virtual training is designed for the medium: more frequent interaction, clearer structure, tools used on purpose, and a second person to handle the technology.

## Why virtual is harder

Jeremy Bailenson (2021) proposed four reasons video calls are tiring: intense close-up eye contact, constantly seeing yourself, reduced physical mobility, and the extra effort of sending and reading nonverbal cues. Add home distractions and unreliable connections, and attention becomes the scarce resource. You cannot read the room as easily either, so you need explicit ways to check understanding.

## Design for the medium

- **Shorter sessions:** two 90-minute sessions on different days usually work better than one three-hour block (and add spacing, which helps memory).
- **Interact often:** a common practitioner rule of thumb is to give learners something to do every few minutes: answer a poll, type in chat, annotate, unmute, or work in a breakout room.
- **Pre-work and post-work:** move reading and video to before the session, and keep live time for practice and discussion.
- **Clear agenda on screen:** people who drift off need to find their way back.

## Tools and how to use them

| Tool | Good for | Example in the incident-response training |
|---|---|---|
| Chat | Fast input from everyone | "Type the severity you would choose, but don't press Enter until I say go" (a *chat waterfall*, so people don't copy each other) |
| Polls | Quick checks, anonymous answers | "Which of these tickets is SEV1?" |
| Annotation or whiteboard | Visual input | Learners stamp where on the incident timeline they would escalate |
| Breakout rooms | Practice and discussion in small groups | Pairs triage five tickets, then report back |
| Reactions, raise hand | Pacing | "Give me a thumbs-up when you've opened the sandbox" |
| Shared document | Group output that persists | Each breakout room writes its severity decisions in its own section |

Use each tool for a reason and explain how to use it the first time.

## Breakout rooms that work

- Give instructions **before** opening rooms and paste them into chat, because people cannot see your slides once they are in a room.
- Assign a role in each room (facilitator, scribe, timekeeper).
- Make the output concrete and shared (a section of a document or a slide).
- Visit rooms briefly, announce time warnings, and keep the debrief afterwards.

## The producer role

In larger sessions, a second person, often called a **producer**, runs the technology: admitting people, launching polls, managing breakout rooms, monitoring chat for questions and technical problems, and taking over if the trainer's connection drops. This lets the facilitator focus on learners. If you have no producer, simplify: fewer tools, pre-built polls and pre-assigned rooms.

## Cameras, inclusion and accessibility

- Invite cameras but do not require them. Some people have bandwidth limits, privacy concerns, disabilities or caring responsibilities; requiring cameras excludes them and rarely improves learning. Offer other ways to show presence (chat, reactions).
- Turn on live captions and share slides in advance.
- Call on people by name kindly and with warning ("Next I'll ask Priya and Tom for their pair's answer").
- Watch time zones and schedule breaks every 45 to 60 minutes.

## Technical preparation

- Test your audio, lighting and connection; use a wired connection or sit near the router if possible.
- Prepare a backup: slides and materials as a shared link, a phone dial-in, and a co-host who can take over.
- Rehearse tool transitions (screen share to poll to breakout) so they are smooth.
- Open with a 3-minute tech check: can everyone hear, see your screen, use chat, and open the sandbox?

## An opening that sets the tone

1. Join early and greet people by name as they arrive.
2. Warm-up in chat: "Type the worst incident you've ever seen in one word."
3. Show the agenda and how people will participate today.
4. First real interaction within five minutes.

## Common mistakes

- Lecturing for 20 minutes with no interaction.
- Explaining breakout tasks only on a slide.
- Running polls, rooms and screen share alone in a large session.
- Requiring cameras.
- Ending on time but with no debrief of the breakout work.

## Quick recap

- Virtual sessions need more frequent, explicit interaction.
- Use chat, polls, annotation and breakouts for a purpose.
- Give breakout instructions in writing; use a producer for large groups.
- Make participation possible without a camera; caption and share materials.

## Try it

On the Do tab, run a short online session for a few people.


Design and run an online session with frequent interaction, purposeful tools and inclusive participation.

Virtual classrooms

Tips for Successful Virtual Facilitation

Facilitate activities with a structured debrief, teach technical skills with live demos and guided practice, and run engaging virtual sessions.