This mid-level course takes technical trainers from designing a lesson to running a training program. You will facilitate activities with a structured debrief, teach technical skills with live demos and guided practice, and run virtual sessions that keep people involved; run a training needs analysis that separates training problems from tool and process problems, design a 30-day onboarding plan, and set up a course in a learning management system; and evaluate training with Kirkpatrick's four levels, analyze completion and score data with a short SQL query, and compare trainer credentials such as ATD's APTD and CPTD and vendor trainer programs. One running example, onboarding new support engineers onto an incident-response tool, connects the lessons. Activities are practical tasks you can run with friends, colleagues or a free LMS sandbox. It builds on Instructional Design & How People Learn.

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.

Delivering Training

Write the request as it was given (for example, 'new volunteers need training on the booking system').

Write the business or organizational goal behind it and how you would measure it.

Gather data from at least three sources: existing records, a short interview with someone who does the task well, and one person who struggles (or a short survey).

Write the gap as desired versus current performance, with a number if you can.

Apply the test 'could they do it if their life depended on it?' and classify each cause: information, tools, incentives, knowledge, capacity or motives.

For each cause, propose a solution. Mark which ones are training and which are not.

Prioritize the gaps by impact, frequency and feasibility.

Write a one-page summary: goal, data, gaps, causes, recommendations, and how success will be measured.

## Why it matters

Training is often requested as a solution before anyone has defined the problem: "Our support engineers keep mis-rating incidents. Can you run a training?" Sometimes training is the answer. Often the real cause is a confusing tool, a missing process, unclear expectations or incentives that reward the wrong behavior, and training will not fix those. A **training needs analysis** (TNA) finds the real gap and the right solution before you spend weeks building a course.

## Three levels of analysis

William McGehee and Paul Thayer (1961) described three levels that are still the standard frame:

- **Organizational analysis:** what are the business goals and where is performance falling short? Is there support (time, budget, managers) for training?
- **Task analysis:** what does the job require? Which tasks, in what steps, to what standard?
- **Person analysis:** who needs training, and what can they do now?

For the incident-response example:

- *Organization:* the goal is to resolve customer-impacting incidents faster; mean time to resolve has risen 30% over two quarters.
- *Task:* correct severity within five minutes, escalation to the right team, a summary within 24 hours.
- *Person:* new engineers mis-rate about a quarter of incidents; experienced engineers rarely do.

## Is it a training problem?

Robert Mager and Peter Pipe's *Analyzing Performance Problems* offers a famous test: **could they do it if their life depended on it?** If yes, they already have the skill, and training will not help. Look instead at obstacles, consequences and feedback.

Thomas Gilbert's **Behavior Engineering Model** (1978) lists six factors behind performance. Three are about the environment (information and feedback; tools and resources; incentives) and three about the person (knowledge and skills; capacity; motives). Gilbert argued that environmental factors are usually the cheapest and most powerful place to start.

| Finding | Likely cause | Better solution |
|---|---|---|
| Engineers cannot find the severity matrix during an incident | Information/tools | Link the matrix inside the tool's severity field |
| SEV1s page managers at 3 a.m., so people avoid choosing SEV1 | Incentives/consequences | Change the paging policy |
| New hires don't know what "customer-facing" means for internal services | Knowledge | Training plus a job aid |
| No one tells engineers when they mis-rate | Feedback | Weekly review of a sample of incidents |

A TNA often recommends a **mix**: a short training, a job aid, and one process change.

## Gathering data

Use several sources so you are not relying on one opinion:

- **Existing data:** incident records, quality reviews, support ticket tags, LMS records, help-desk questions.
- **Interviews:** managers, top performers and new hires. Ask top performers what they do differently.
- **Observation:** shadow someone handling a real incident (with permission).
- **Surveys:** good for breadth, weak on depth; keep them short and specific ("How confident are you choosing between SEV2 and SEV3?").
- **Skills checks:** a short practical scenario reveals actual skill rather than self-rating.

## Writing the gap

State gaps as observable differences between the desired and current performance, and quantify them where you can:

> Desired: new support engineers assign the correct severity to 95% of incidents within five minutes. Current: 74% correct in the first 60 days (sample of 200 incidents, Q2). Main confusion: SEV2 versus SEV3 for internal-only impact.

This gap statement becomes the basis for objectives and for evaluation later, so it pays to measure it now.

## Prioritizing

You will find more gaps than you can address. Prioritize by **impact** (cost of the gap to customers or the business), **frequency** (how often the task happens) and **feasibility** (can training actually change it?). A simple impact versus effort grid works for a stakeholder meeting.

## The TNA report

Keep it short:

1. Business goal and the problem as reported.
2. Data gathered (sources, sample size).
3. Gaps, stated as desired versus current.
4. Root causes for each gap.
5. Recommendations: training and non-training.
6. How success will be measured.

Cathy Moore's **action mapping** gives a quick version of the same logic: start with the business goal, list what people need to *do* to reach it, ask why they are not doing it, and design practice only for the behaviors where knowledge or skill is the real barrier.

## Common mistakes

- Accepting "we need training" without analysis.
- Relying only on a self-assessment survey.
- Interviewing managers but not the people doing the work.
- Describing gaps as topics ("needs incident training") instead of performance.
- Not recording a baseline, so you cannot show improvement later.

## Quick recap

- Analyze at organization, task and person levels.
- Ask whether it is really a skill gap ("if their life depended on it").
- Use several data sources and quantify the gap.
- Recommend non-training fixes where they are the real answer.

## Try it

On the Do tab, run a small needs analysis on a real or realistic performance problem.


Find the real performance gap and decide whether training, a job aid or a process change will fix it.

Training needs analysis

How to Conduct a Needs Analysis

What is a Training Needs Analysis?

Write the role and what 'fully up to speed' looks like at day 30, as two or three observable milestones.

List what must be ready before day 1 (equipment, accounts, welcome message, buddy).

Make a table with rows for week 1 to week 4 and columns for goals, activities and a milestone check.

Fill week 1 with what the person needs to do first, not general company history.

Add at least one item for each of the four Cs: compliance, clarification, culture and connection.

Add spaced touchpoints: buddy check-ins, a short practice task in week 2, and a 30-day check-in.

List the job aids the new hire will need and who owns each.

Choose two measures to track for every new hire (for example, time to the day-30 milestone and a short survey).

Ask someone who joined recently to review the plan and tell you what they wish they had had.

## Why it matters

New employees decide quickly whether a job is right for them, and they reach full productivity much faster when onboarding is planned instead of improvised. For technical roles, onboarding is often the largest training program a trainer owns: every new hire goes through it, and every gap shows up as slow ramp-up, repeated questions to busy colleagues and early mistakes in production.

## What research says onboarding should do

Talya Bauer and colleagues' research on newcomer adjustment (including a 2007 meta-analysis) found that new hires do better when they gain **role clarity**, **self-efficacy** (confidence they can do the job) and **social acceptance**. In a 2010 SHRM Foundation report, Bauer described four levels of onboarding, the **four Cs**:

| C | Meaning | Incident-response example |
|---|---|---|
| Compliance | Rules, policies, legal and security basics | Access request, security training, data-handling policy |
| Clarification | Understanding the job and expectations | What "good" looks like on a support shift; severity standards; who to escalate to |
| Culture | Norms and values, formal and informal | How the team runs blameless post-incident reviews |
| Connection | Relationships and networks | A buddy, introductions to the on-call leads, team lunch |

Most organizations do compliance well and the other three poorly. Clarification and connection have the biggest effect on adjustment.

## Principles for technical onboarding

- **Sequence by need, not by org chart.** Teach what the person will do in week one first; the history of the company can wait.
- **Space it out.** A two-day orientation followed by silence ignores the spacing effect. Spread learning across the first month with short, scheduled touchpoints.
- **Real work early, safely.** Shadowing, then reverse shadowing (the new hire leads with the buddy watching), then low-risk tasks on their own.
- **A buddy who is not the manager.** Someone to ask "silly" questions. Give buddies a short guide and time to do it.
- **Clear milestones.** The new hire, manager and buddy should all know what is expected by day 5, 15 and 30.
- **Feedback both ways.** Check in, and ask new hires what is confusing, which improves the program for the next person.

## A 30-day onboarding plan: example

For a new support engineer joining the incident-response rotation:

| Week | Goals | Activities | Milestone check |
|---|---|---|---|
| Before day 1 | Ready to start | Laptop and accounts ready; welcome email with first-week schedule and buddy's name | Can log in on day 1 |
| Week 1 | Know the tools and the team | Compliance modules; incident tool workshop (sandbox); meet buddy daily; shadow two shifts | Opens and escalates a practice SEV2 correctly in the sandbox |
| Week 2 | Handle low-severity work | Handles SEV4 tickets with buddy review; severity calibration exercise; meet the escalation teams | 90% correct severity on 20 practice tickets |
| Week 3 | Contribute to live incidents | Reverse shadow on live incidents; writes first post-incident summary (reviewed) | Summary meets the rubric |
| Week 4 | Join the rotation | First shift on the rotation with a named backup; 30-day check-in with manager | Manager and buddy sign off; new hire's feedback collected |

Notice that each week has a performance milestone, not just activities, which connects back to backward design.

## Supporting materials

- A **checklist** for the new hire, the manager and the buddy (each sees their own tasks).
- **Job aids:** the severity matrix, an escalation contact list, a post-incident summary template.
- A **"first-week FAQ"** built from questions previous hires asked.
- Short **videos** for tasks people need to look up later.

## Measuring onboarding

Pick a few indicators and track them for every cohort:

- **Time to proficiency:** days until the new hire meets the 30-day milestone.
- **Quality:** severity accuracy in the first 60 days.
- **Experience:** a short survey at day 30 (role clarity, confidence, feeling welcomed).
- **Retention:** whether new hires are still there at 6 and 12 months (interpret with care; many factors affect it).

## Remote and hybrid onboarding

Connection is the hardest C remotely. Schedule it on purpose: daily buddy calls in week one, virtual coffees with three colleagues, cameras-optional team rituals, and a clear channel for questions. Ship equipment early and test access before day one.

## Common mistakes

- Information overload in the first two days, then nothing.
- No buddy, or a buddy with no time.
- Activities without milestones.
- Treating onboarding as finished after week one.
- Never asking new hires what would have helped.

## Quick recap

- Aim for role clarity, self-efficacy and social acceptance.
- Cover compliance, clarification, culture and connection.
- Spread onboarding over at least 30 days with weekly milestones.
- Use buddies, job aids and early, safe real work; measure every cohort.

## Try it

On the Do tab, design a 30-day onboarding plan for a role you know.


Design a 30-day onboarding plan with milestones that builds clarity, confidence and connection.

Onboarding programs

How to Design The Perfect Onboarding Process

Sketch the course on paper first: three sections, each with one resource and one activity, tied to an objective.

Create the course and add a 'Start here' section with a welcome page stating the goals and schedule.

Add the three sections with their resources (a page, a file or a video link) and activities (a quiz and an assignment).

Build a practice quiz with at least three questions and feedback on every option; allow multiple attempts.

Set completion rules so each activity counts as complete only when submitted or passed, not just viewed.

Add a release condition so section 2 opens only after section 1 is complete (or on a date).

Preview the course as a student (switch role or use a test account) on a computer and on a phone.

Fix anything confusing, then note which reports the LMS offers for completion and quiz results.

## Why it matters

Once you train more than a handful of people, you need a system to enroll them, deliver materials, track who completed what, and report to managers and auditors. That system is usually a **learning management system (LMS)**. Technical trainers are expected to build and maintain courses in one, and to know what the data it collects can and cannot tell them.

## What an LMS does

Core functions:

- **Users and enrollment:** who can see which course, often synced from the HR system or single sign-on; manual, self, or rule-based enrollment ("all new support engineers").
- **Content delivery:** pages, files, videos, quizzes, assignments, and imported e-learning packages.
- **Tracking:** completion, scores, time, attempts.
- **Assessment and grading:** quizzes, assignments with rubrics, a gradebook.
- **Communication:** announcements, forums, reminders.
- **Reporting:** completion rates, overdue training, compliance status.
- **Certificates and recertification:** for compliance training that must be repeated.

Common platforms include **Moodle** (open source, widely used in education and business), **Canvas** (Instructure, common in universities), **Google Classroom** (schools) and many corporate systems. A related category, the **learning experience platform (LXP)**, focuses on recommending and curating content; many products now mix both.

## Standards that connect content and systems

- **SCORM** packages let an LMS launch e-learning and record completion and score.
- **xAPI** and **cmi5** record richer learning activity, including outside the LMS.
- **LTI** (Learning Tools Interoperability, from 1EdTech) lets an LMS launch external tools, such as a coding sandbox, with the learner already signed in.

## Building a course: structure first

Before clicking anything, sketch the structure from your design (objectives, assessments, activities). In most LMSs a course has **sections** (weeks or topics) containing **resources** (things to read or watch) and **activities** (things to do: quizzes, assignments, forums).

For the incident-response onboarding course:

| Section | Resources | Activities |
|---|---|---|
| Start here | Welcome page with goals and schedule; severity matrix (PDF job aid) | Pre-check quiz (5 questions, ungraded) |
| Week 1: Tools | 3-minute videos: open, escalate, close | Sandbox task with a submission (screenshot of the escalated incident) |
| Week 2: Severity | Worked examples | Severity quiz (10 scenarios, feedback on every option); forum: "the ticket that confused me" |
| Week 3: Summaries | Summary template and model example | Assignment graded with the rubric |
| Finish | Checklist | Feedback survey; completion certificate |

## Settings that matter

- **Completion tracking:** define what counts as complete (viewed, submitted, passed with at least 80%). The default "viewed" usually means very little.
- **Restrict access / prerequisites:** release Week 2 only after Week 1 is complete, or after a date, to support pacing and spacing.
- **Quiz settings:** multiple attempts with feedback for practice; question shuffling; feedback shown after each attempt.
- **Groups:** separate cohorts so forums and reports stay manageable.
- **Notifications:** reminders before due dates, not daily spam.

## Accessibility and usability

- Use the LMS's headings and page tools rather than uploading everything as PDFs.
- Caption videos; give files descriptive names ("Severity matrix v3 (PDF, 1 page)").
- Keep navigation consistent from section to section.
- Test the course on a phone and with a keyboard, and view it with a student or test-learner account. Most LMSs have a "switch role to student" or preview mode.

## Data and privacy

LMS data is personal data. Collect what you need, restrict reports to people who need them (often the learner, their manager and the training team), follow your organization's data retention rules and privacy law (such as GDPR in Europe or FERPA for US student records), and do not export learner data to personal spreadsheets or unapproved tools.

## Where to practise for free

- **Moodle** runs public demo sites (sandbox sites that reset regularly) at moodle.org/demo, and is free to install yourself. MoodleCloud offers hosted plans and trials.
- **Canvas** has offered a free-for-teacher account.
- **Google Classroom** works with a personal Google account.

Offers change, so check the current options and avoid entering payment details for practice. Checked on 2026-10-23.

## Common mistakes

- Uploading a slide deck and calling it a course.
- Leaving completion as "viewed".
- Opening everything on day one, so people binge or never start.
- Not previewing as a learner.
- Treating the LMS report as proof of learning (completion is not competence).

## Quick recap

- An LMS handles enrollment, delivery, tracking, assessment and reporting.
- SCORM, xAPI/cmi5 and LTI connect content and tools.
- Design the structure first; set meaningful completion rules and release conditions.
- Preview as a learner, check accessibility and protect learner data.

## Try it

On the Do tab, set up a short course in a free LMS sandbox.


Structure a course in an LMS with meaningful completion rules, release conditions and learner-friendly settings.

Learning management systems

How to Use a Learning Management System (LMS)

What is a course?

Find the real performance gap, design onboarding that ramps people up, and run courses in a learning management system.

Training Programs

## Why it matters

"Did the training work?" is the question every sponsor eventually asks. Most training is evaluated only with an end-of-session satisfaction form, which tells you whether people liked it, not whether it changed anything. Evaluation models give you a structure for gathering better evidence, and planning evaluation before delivery (backward design again) makes it far easier.

## Kirkpatrick's four levels

Donald Kirkpatrick introduced four levels of training evaluation in a series of articles in 1959. They remain the most widely used framework.

| Level | Question | Typical measures | Incident-response example |
|---|---|---|---|
| 1. Reaction | Did they find it engaging and relevant? | End-of-session survey | "How useful will this be on your next shift?" (1 to 5) |
| 2. Learning | Did they gain the knowledge, skills and confidence? | Tests, practical tasks, pre/post | Severity scenario test before and after; sandbox escalation task |
| 3. Behavior | Do they apply it on the job? | Observation, work samples, manager check-ins, system data | Severity accuracy on real incidents in the first 60 days |
| 4. Results | Did the targeted business outcomes improve? | Business metrics | Mean time to resolve customer-impacting incidents |

### The New World Kirkpatrick Model

James and Wendy Kirkpatrick updated the model (*Kirkpatrick's Four Levels of Training Evaluation*, 2016). Key changes:

- **Start planning at Level 4** and work backwards: what result does the business need, what behaviors drive it, what must people learn, and how should training feel?
- **Required drivers** at Level 3: processes and systems that reinforce, monitor and reward the new behavior on the job (manager coaching, job aids, follow-up). Without them, learning rarely turns into behavior.
- **Leading indicators** at Level 4: short-term signs that results are on track (for example, escalations reaching the right team first time).
- Level 1 adds **engagement** and **relevance**, and Level 2 adds **confidence** and **commitment**.

## Phillips ROI: a fifth level

Jack Phillips added **Level 5: Return on investment**, comparing monetary benefits with program costs:

```text
ROI (%) = (net program benefits / program costs) x 100
net program benefits = monetary benefits - program costs
```

Example: the onboarding program costs 40,000 (design time, trainer time, learners' time). Faster incident resolution is estimated to save 70,000 in the first year. Net benefits = 30,000, so ROI = 30,000 / 40,000 x 100 = 75%. The hard part is **isolating the effect of training** from everything else that changed (a new tool, a quieter quarter). Phillips recommends methods such as control groups, trend-line analysis and conservative estimates, and being explicit about assumptions.

## Criticisms and alternatives

- **The levels are not a chain.** George Alliger and colleagues' 1997 meta-analysis found that reaction measures were only weakly related to learning and transfer. People can enjoy training and learn little, or dislike challenging training that works. Do not use Level 1 as a proxy for Level 2 or 3.
- **Most effort stays at Level 1.** Surveys are easy; behavior and results take planning and stakeholder support.
- **Will Thalheimer's LTEM** (Learning-Transfer Evaluation Model, 2018) offers eight tiers, separating attendance and activity from knowledge recall, decision-making competence, task competence, transfer and effects of transfer, to discourage treating weak measures as strong evidence.
- **Robert Brinkerhoff's Success Case Method** studies the most and least successful participants in depth to find out what helped or blocked transfer, which is often more persuasive to stakeholders than averages.

## Planning a four-level evaluation

For the incident-response onboarding:

1. **Level 4 (start here):** target is to reduce mean time to resolve SEV2 incidents handled by new engineers; leading indicator: correct first escalation rate.
2. **Level 3:** severity accuracy on a weekly sample of real incidents for 60 days; required drivers: buddy reviews, matrix linked in the tool, manager check-in at day 30.
3. **Level 2:** pre/post scenario test and the sandbox escalation task; confidence rating.
4. **Level 1:** three-question survey (relevance, confidence, one improvement) at the end of week 1.
5. **Timing and owners:** who collects what, when, and where the data lives.
6. **Baseline:** collect the same measures for the previous cohort, or before launch.

Agree this plan with the sponsor *before* the program starts, including which results would count as success.

## Common mistakes

- Only surveying satisfaction.
- Measuring behavior with no baseline.
- Claiming all improvement was caused by training.
- Ignoring the work environment that supports or blocks new behavior.
- Choosing measures after the program, based on what looks good.

## Quick recap

- Kirkpatrick: reaction, learning, behavior, results.
- Plan from Level 4 backwards; build required drivers for Level 3.
- Phillips adds ROI; isolate the training's effect and state assumptions.
- Reaction does not predict learning; consider LTEM and success cases too.

## Try it

Answer the quiz on the Do tab, then draft the Level 4 and Level 3 measures for a training you know.


Plan an evaluation across reaction, learning, behavior and results, starting from the business outcome.

Kirkpatrick evaluation

The Kirkpatrick Model of Training Evaluation

The Kirkpatrick Evaluation Model in a Nutshell

## Why it matters

Training teams sit on a lot of data: enrollments, completions, quiz scores, survey answers, time spent. Stakeholders ask for it constantly ("What percentage of the support team has finished?"). Being able to pull and summarize that data yourself, and to explain what it does and does not show, makes you far more effective than waiting for a report someone else builds. You do not need to be a programmer: a few lines of SQL go a long way.

## Common training metrics

| Metric | What it tells you | Watch out for |
|---|---|---|
| Enrollments | Reach | Says nothing about learning |
| Completion rate | Share of enrolled learners who finished | Easy to game with "viewed" completion rules |
| Assessment score | Performance on the test at the end | Depends on test quality |
| Pre/post gain | Change from before to after | Needs the same or equivalent tests |
| Time to proficiency | How fast people reach the standard | Needs a clear standard |
| On-the-job measures | Behavior and results (Kirkpatrick 3 and 4) | Many other causes |

## Reading training data with SQL

Many LMSs let you export reports or query a reporting database. A typical export has one row per learner per course. Here is a small table called `enrollments`:

| learner | team | course | completed | pre_score | post_score |
|---|---|---|---|---|---|
| Ana | Support | Incident basics | 1 | 55 | 85 |
| Ben | Support | Incident basics | 0 | 60 | (empty) |

`completed` is 1 for finished and 0 for not finished. `post_score` is empty (NULL) for people who have not finished.

Four SQL ideas cover most training reports:

```sql
SELECT course,                                  -- 1. choose columns
       COUNT(*) AS enrolled,                    -- 2. count rows in each group
       ROUND(100.0 * SUM(completed) / COUNT(*), 1) AS completion_pct
FROM enrollments
GROUP BY course                                 -- 3. one row per course
ORDER BY completion_pct DESC;                   -- 4. sort the result
```

- `COUNT(*)` counts learners in each course.
- `SUM(completed)` adds up the 1s, which is the number who finished. Multiplying by `100.0` (not `100`) makes the division a decimal rather than a whole number.
- `AVG(...)` gives an average and **ignores empty (NULL) values**. That means `AVG(post_score - pre_score)` is the average gain of the people who finished, because the others have no post score.
- `WHERE team = 'Support'` would filter to one team before grouping.

## Interpreting the numbers

Suppose the query shows:

| course | enrolled | completion_pct | avg_gain |
|---|---|---|---|
| Escalation paths | 5 | 80.0 | 22.5 |
| Incident basics | 6 | 66.7 | 26.3 |
| Writing summaries | 5 | 40.0 | 7.5 |

Questions a good trainer asks:

- **Why is "Writing summaries" completion so low?** Is it at a busy time, too long, or broken? Look at where people stop.
- **Is the small gain a problem with the course or the test?** A pre-test that is already high leaves little room to improve (a ceiling effect).
- **Survivorship:** average gain covers only completers. If the people who struggled dropped out, the gain looks better than it really is.
- **Small numbers:** with five learners, one person changes the completion rate by 20 points. Report the counts alongside the percentages.
- **Completion is not competence.** A high completion rate with a weak test tells you little; connect to Level 3 and 4 measures where you can.

## Reporting to stakeholders

- Lead with the question the stakeholder cares about ("Are new engineers ready for the rotation?"), not with every metric.
- Show counts and percentages together.
- Compare with a baseline or target.
- Say what the data cannot show, and what you will do next.
- Use simple charts: a bar chart of completion by course beats a pie chart or a dense table.

## Privacy and ethics

Learning data is personal data. Share individual results only with people who need them, aggregate where possible, follow your organization's privacy rules (and laws such as GDPR), and be careful about using training scores in performance reviews without telling learners in advance. People answer practice quizzes honestly only when it is safe to be wrong.

## Common mistakes

- Reporting completion as if it were learning.
- Dividing whole numbers and getting 0 instead of 66.7.
- Ignoring that averages skip empty values.
- Percentages from tiny groups with no counts.
- Sharing named results widely.

## Quick recap

- Know what each metric shows and its trap.
- `COUNT`, `SUM`, `AVG`, `GROUP BY` and `ORDER BY` answer most training questions.
- `AVG` ignores NULL, which affects who is included.
- Report counts with percentages, compare with a baseline, protect learner data.

## Try it

On the Do tab, finish a query that reports completion and average score gain per course.


Analyze completion and score data with a short SQL query and report it honestly.

Training data and reporting

Training evaluation | How to measure learning impact [Tutorial isEazy]

Measuring Learning Return on Investment (ROI)

## Why it matters

Technical trainers are hired mainly for two things: real expertise in what they teach and evidence that they can teach it. Credentials can help with the second, but the landscape is confusing: association certifications, vendor trainer programs, degrees, and certificates of attendance all look similar on a CV. This lesson helps you decide what is worth your time. Requirements and fees change often, so always check the official pages linked here. Checked on 2026-10-23.

## What employers actually look for

For most technical trainer roles (O*NET groups them with training and development specialists, 13-1151.00), employers ask for:

1. **Subject expertise**, often shown by working experience and by the technical certifications learners themselves are taking (a cloud trainer usually holds the cloud certifications).
2. **Evidence of teaching ability**: a portfolio, a recorded teach-back, references, and sample materials.
3. A bachelor's degree is common but not universal; a master's in instructional design, learning sciences or adult education helps for design-heavy and leadership roles.
4. Credentials, as a tiebreaker or requirement for some partner programs.

A **portfolio** is often more persuasive than any certificate: a short recorded lesson, a needs analysis summary, an objectives-and-assessment plan, a rubric and an evaluation report. Several activities in this course and the Instructional Design course produce exactly these.

## Association credentials: ATD

The **Association for Talent Development (ATD)** runs a certification body, the ATD Certification Institute, with two credentials:

- **APTD (Associate Professional in Talent Development):** for earlier-career practitioners. ATD has listed eligibility as about three years of professional work experience plus 28 hours of talent development professional development in the last three years.
- **CPTD (Certified Professional in Talent Development):** for experienced practitioners. ATD has listed about five years of experience plus 60 hours of professional development in the last five years, with alternative routes for APTD holders and ATD Master Series graduates.

Both are exam-based, cover a broad talent development capability model (instructional design, training delivery, evaluation, and more), and require recertification. They signal breadth across the L&D field rather than expertise in one technology. Check the current handbook at [td.org/certification](https://www.td.org/certification).

ATD also offers shorter **certificate programs** (for example, training and facilitation certificates). These are certificates of course completion, which are different from certifications with an independent exam.

## Vendor trainer programs

Technology vendors certify instructors who deliver their official courses through training partners. Typical requirements are a current technical certification in the product, proof of instructional skills, and an annual renewal.

- **Microsoft Certified Trainer (MCT):** Microsoft's enrollment page lists agreeing to the program agreement, holding a current qualifying Microsoft role-based (Associate or Expert) certification, and providing verified proof of instructional skills; membership is renewed annually. See [learn.microsoft.com/credentials/certifications/mct-enrollment](https://learn.microsoft.com/credentials/certifications/mct-enrollment).
- **AWS, Google Cloud, Cisco, Salesforce** and other vendors run their own authorized instructor programs, usually tied to working for or with an authorized training partner. Check each vendor's training site.

These matter most if you want to teach official vendor courses, or if your employer is a training partner.

## A retired credential: CompTIA CTT+

You will still see **CompTIA CTT+** (Certified Technical Trainer) in job ads and older advice. CompTIA retired it in 2023 and stopped selling exam vouchers that year. People who earned it remain certified for life, but it is no longer available to new candidates, and vendor programs that once accepted it as proof of teaching skills have moved to other options. Check [CompTIA's list of retired certifications](https://help.comptia.org/hc/en-us/articles/10830728209300-Which-CompTIA-Certifications-Have-Been-Retired) if you see it required.

## Comparing options

| Option | Best for | Signals | Typical cost in time |
|---|---|---|---|
| Portfolio | Everyone | Actual teaching and design skill | Ongoing; build as you go |
| Technical certifications in your subject | Everyone teaching a technology | Subject credibility | Weeks to months each |
| Vendor trainer program (e.g. MCT) | Teaching official vendor courses | Authorized to deliver vendor content | Requires the technical cert first, plus a skills check |
| ATD APTD | Early-career L&D generalists | Breadth of talent development knowledge | Months of study |
| ATD CPTD | Experienced L&D professionals moving into senior roles | Breadth and experience | Months of study; experience required |
| Master's degree | Instructional design, L&D leadership, academic roles | Deep theory and research | One to two years |

## Building a plan

1. Decide your direction: product or technology trainer, L&D generalist, or instructional designer.
2. Keep your technical certifications current; they are your credibility with learners.
3. Build a portfolio from real work, with confidential details removed.
4. Add one teaching credential that matches your direction: a vendor program if you teach that vendor's courses, ATD if you are moving towards L&D roles.
5. Keep learning in public: present at a meetup, write up an evaluation you ran.

## Common mistakes

- Collecting certificates instead of building a portfolio.
- Treating a certificate of attendance as an industry certification.
- Pursuing a retired credential because an old job ad mentioned it.
- Copying fees and requirements from blogs instead of the official handbook.

## Quick recap

- Subject expertise and a teaching portfolio come first.
- ATD's APTD and CPTD are broad talent development certifications with experience requirements.
- Vendor programs such as MCT require current technical certification plus proof of teaching skills.
- CompTIA CTT+ was retired in 2023; check official pages, as requirements change.

## Try it

Answer the quiz on the Do tab, then list the three pieces of evidence you would put in your trainer portfolio first.


Compare ATD's APTD and CPTD, vendor trainer programs and portfolios, and pick what fits your direction.

Trainer credentials

Keys to ATD CI’s Certification Eligibility

How to Become A Microsoft Certified Trainer (MCT)

Plan four-level evaluation, analyze completion and score data, and choose the trainer credentials worth your time.

Training Delivery & Evaluation

About this course

Course content

Delivering Training

Training Programs

Evaluation

Where this course leads

Careers that use it