Facilitator guide

Materials and facilitator prep

Most prep goes into building a case library; once built, it can be reused for every cohort.

• ☐ Collect 6–10 internal postmortems and turn them into step-by-step incident replays
• ☐ Build 8 PRs with planted flaws, each with an answer key and severity ranking
• ☐ Write 40 calibration scenarios with known outcomes (20 for week 1, 20 for week 8)
• ☐ Pick 2–3 past architecture decisions and line up their original owners for week 6
• ☐ Record 4–6 senior engineers thinking aloud through cases (15–20 minutes each)
• ☐ Prepare 3 no-AI katas with reference solutions
• ☐ Recruit capstone panelists and confirm managers support each learner’s capstone decision
• ☐ Set up a shared confidence-log template

Plan for about 60–80 hours of upfront prep, then 4–5 hours per week per facilitator while the course runs.

On this site, the shared confidence-log template is the My log page: learners’ logs live in their own browsers, and they export JSON when you need to see them.

Session run-sheet

Every live session uses the same 90-minute shape. Adjust the middle block per week.

Per week:

• Week 1: Run the 20 scenarios at about 2 minutes each. Learners commit on the case pages, then you reveal together. Don’t discuss until everyone has committed.
• Week 2: Learners review the PR silently for 15 minutes, then compare findings in pairs before the answer key.
• Week 3: No AI, no laptops for the first 20 minutes. Paper or whiteboard only.
• Week 4: Split into teams of 3–4. Each team gets 30 minutes to write a design, then 5 minutes to argue for it. Reveal the real system’s history last.
• Week 5: Incident replay (see below).
• Week 6: Learners predict the original reasoning before the decision-maker speaks. The guest answers questions; they don’t present.
• Week 7: Each learner gets 5 minutes to pitch and 5 minutes of feedback on framing only, not on the answer.
• Week 8: Panels (see below).

Running an incident replay

An incident replay works when learners feel the uncertainty the on-call engineer felt.

1. Prepare the stages. Split the postmortem’s timeline into 3–5 stages. Each stage gives only what the responders could see at that moment: alerts, a graph, a log line, what a teammate said.
2. Cut the hindsight. Remove every sentence that explains the cause. If the stage text tells learners what matters, the stage is too generous.
3. Ask the same question each stage: “What do you check next, and why?” Learners write a note before anyone speaks. The case page enforces this: the next stage stays locked until the note is saved.
4. Collect hypotheses out loud. Write them on a shared board with a rough likelihood. Ask what evidence would rule each one out.
5. Reveal the next stage and ask which hypotheses got stronger or weaker.
6. Reveal the outcome last, then play or read the senior commentary.
7. Debrief the process, not the answer. Who narrowed fastest, and what did they look at? Where did the room chase a symptom?

Keep it blameless. Talk about conditions and decisions, never about the people in the original incident.

Running capstone panels

The week 8 panel tests whether a learner can defend a decision under friendly but real scrutiny.

• Panel: 2–3 senior engineers who weren’t involved in the learner’s decision. Send them the proposal 3 days ahead.
• Format: 15 minutes per learner: 3 minutes of summary, 10 minutes of questions, 2 minutes for the panel to note scores.
• Questions to prepare: “What did you give up?”, “What’s the hardest part to undo?”, “What would make you change your mind?”, “How would this fail in six months?”
• Scoring: Each panelist scores the reasoning rubric independently, then they compare. Big gaps between panelists are worth a short conversation before the scores go back to the learner.
• Feedback: Written feedback within a week, one strength and one thing to practise next.

Panelists should push back on reasoning, not on taste. “I’d have picked X” isn’t feedback unless they can say what X buys.