Live technical training runbook: 1-2 hours in front of senior engineers

Senior engineers read your terminal faster than you talk, and they test your claims by asking the question you hoped to skip. This runbook is the operational plan for a 60-120 minute live session on a tool like Claude Code, Kubernetes, or n8n: timeline, demo safeguards, and what to say when someone pushes back.

Session structure

Four things happen regardless of length: earn attention, set context, show it working, let the audience touch it. Keep context short – a senior audience tunes out by the fourth slide of background.

60-minute session

120-minute session

Keep the cold open under five minutes even at two hours. The extra time belongs to hands-on, not a longer intro.

Demo engineering

A live demo is a system with failure modes – engineer it like one.

Pre-baked repo, tagged checkpoints. Build the repo in advance with one tag per demo step. If step 3 breaks mid-session, recover with one command instead of re-typing fifteen minutes of setup:

# reset the working tree to the step-2 checkpoint
git checkout step-2 -- .

Name tags after the step, not the date (step-2, not oct-27), so the repo is reusable.

Fallback recording. Record the full demo once on the actual presenting hardware. Keep it loaded, muted, paused at the start. If a live fix will take over 60 seconds, switch to the recording and narrate over it.

Terminal setup. 18pt minimum font, high-contrast theme, short prompt so commands don’t wrap. Clear scrollback before you start so earlier mistakes aren’t visible when you scroll up.

Safe modes for anything that executes. Decide the guardrail before you’re in front of people. --permission-mode plan on Claude Code previews edits without applying them (full flag list in the Claude Code cheat sheet). If the agent must actually write files, keep Ctrl+C plus git checkout to the last tag as the two moves you know cold. Hooks that log or block commands are worth enabling for an audience that will ask what happened under the hood.

Disposable infrastructure. For Kubernetes, run against a local cluster you can nuke and rebuild in under two minutes – kind delete cluster --name demo then kind create cluster --name demo (trade-offs between kind, minikube, and k3d are in the cluster comparison). For n8n, start from a known-good docker compose state (the first n8n workflow lab) with a second instance holding the finished workflow as backup.

Interaction design

Senior engineers participate when the format asks something specific of them, not “any questions?” into silence.

• Cold-open question. Ask something tied to the room’s work (“who has hit a flaky deploy this month?”) instead of stating your bio. Call on someone if hands don’t go up in five seconds.
• Polls. One poll per 30 minutes, phrased as a prediction (“what will this command print?”), answered by running the command rather than a slide.
• Pairing. For the harder hands-on block, pair people instead of leaving them solo – pairing surfaces disagreements out loud, which is where you learn what the room believes.
• “Break it” exercise. Hand over the working demo and ask the room to break it in three minutes. It produces better edge cases than you’ll find alone, and reframes failure as expected rather than embarrassing.

Handling sharp questions

Senior engineers ask questions to find the edge of your knowledge. Use the same four moves every time:

1. Acknowledge. “Good question” is fine if true; don’t say it reflexively.
2. Restate. One sentence, your words – confirms you understood and buys time to think.
3. Answer or park. Answer in under a minute, or write it on a visible parking lot with the asker’s name.
4. Follow up in writing. Close every parked item within 24 hours, even if the answer is “no.”

When you don’t know: say so in one sentence, park it, move on. Improvising an unsure answer is the fastest way to lose a senior room – they check it later and remember the guess.

When a participant is wrong: don’t argue the point abstractly. Run the command or open the doc that settles it; “let’s check,” said out loud and then done, resolves more than a verbal correction and keeps it impersonal.

When someone challenges the tool’s value: don’t defend it on principle. Ask what they’d compare it against and what bar it needs to clear. Write that bar on the parking lot and test it live if you can in two minutes. If you can’t, say the gap is real and move on.

Failure drills

Rehearse these beforehand.

Demo breaks mid-step. State what broke in one sentence, switch to the fallback recording or jump to the next git tag, keep narrating. Don’t apologize more than once.

Network dies. This is why infrastructure is local: a kind cluster or a Dockerized n8n instance keeps running without internet. If a demo genuinely needs a remote API, have an offline substitute ready (recorded response, local mock) and say you’re switching to it.

Agent goes off-script. An AI agent editing files you didn’t expect needs an immediate stop, not a wait-and-see. Hit the kill switch – interrupt the process, git checkout back to the last known-good tag – and say what happened. Framed as a live example of why guardrails matter (see the AI governance checklist), a mistake becomes content instead of a wasted slot.

Pre-flight checklist

Post-session checklist

Reusable template

Paste this and fill the brackets before every session.

# Session plan: [topic]

Audience: [role / seniority]
Length: [60 | 120] minutes
Repo: [url], tags step-1 .. step-N
Fallback recording: [path/link]
Kill switch: [key combo or command]

## Timeline
- 0:00 Cold open: [question or broken thing]
- 0:05 Context: [scope]
- 0:xx Demo 1: [workflow]
- 0:xx Hands-on: [task, starting repo state]
- 0:xx Demo 2 / break it: [edge case or open floor]
- 0:xx Q&A
- end Wrap: [links, next steps]

## Parking lot
| Question | Asked by | Status | Answered |
| --- | --- | --- | --- |

## Pre-flight
- [ ] Repo pinned and tagged
- [ ] Fallback recording ready
- [ ] Infra pre-pulled and local
- [ ] Kill switch tested

Pitfalls

Too many slides. A deck over ten slides for a technical audience signals you’re filling time instead of showing the tool work. Cut the slide, show the terminal.

Live-generating everything. Typing every line from scratch is slower than the room’s patience and multiplies the chance of a typo derailing the flow. Pre-bake the boring parts; reserve live typing for the one or two lines that are the point.

Ignoring the one silent expert. Every senior room has someone who says nothing for 40 minutes, then asks the question that reveals a gap in your demo. Watch for who stopped taking notes or started checking something on their own screen, and call on them directly during Q&A.

FAQ

How long should a live technical training session for senior engineers run?

60 minutes for one demo and one hands-on block. 120 minutes for two demos, a break, and a pairing exercise. Senior audiences disengage past two hours regardless of content, so split anything longer into two sessions.

What’s the safest way to run a live demo that might fail?

Pin the repo to git tags per step so you can jump to any checkpoint with one command, and keep a pre-recorded fallback of the full demo ready to play. The audience forgives a failure; they don’t forgive five minutes of silent debugging.

How do I answer a sharp question I can’t answer live?

Acknowledge it took thought, restate it in one sentence, then answer in under 60 seconds or park it on a visible list with the asker’s name. Send the real answer in writing within 24 hours. Guessing out loud costs more credibility than parking the question.

What if a senior engineer says the tool isn’t worth it?

Don’t defend it. Ask what they’d compare it against and what it would need to do to earn a slot. Write that bar on the parking lot and test it live if you can in under two minutes. If you can’t, admit the gap and move on.

What’s a kill switch for an AI coding agent during a live demo?

A single move that stops the agent from making further changes without explaining why: Ctrl+C in the terminal, then git checkout back to the last tagged commit. Decide this before the session, not while the agent is mid-edit.