Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. What is the incident commander's main job during a major incident?

   1. AFixing the problem personally
   2. BCoordinating: setting priorities, assigning roles, keeping communication flowing and making decisions, while others investigate and fix
   3. CWriting the postmortem
   4. DCalling the vendor
   Show answer

   B. When the commander dives into debugging, nobody is steering; coordination is a full-time job in a big incident.

   From lesson 08 · Leading a major incident and the review after it

2. Q2. Why do blameless reviews lead to better fixes?

   1. AThey're shorter
   2. BPeople share what really happened, including mistakes, so the review finds the system conditions that made the mistake easy and fixes those
   3. CThey avoid writing anything down
   4. DNobody is responsible for actions
   Show answer

   B. Blame makes people hide information; without it, reviews find the real contributing factors. Blameless still means accountable for actions.

   From lesson 08 · Leading a major incident and the review after it

3. Q3. How should a lead delegate a design they could do faster themselves?

   1. ANot at all
   2. BGive the goal, constraints and a check-in plan; let the engineer own the design; review early and coach rather than rewrite
   3. CGive it away and never check
   4. DDelegate only the boring parts
   Show answer

   B. Ownership with support is how engineers grow; rewriting their work teaches them that it was never really theirs.

   From lesson 09 · Mentoring and growing engineers

4. Q4. What makes feedback useful?

   1. ABeing vague to stay polite
   2. BBeing specific about the situation and behaviour, its impact, and timely, with a suggestion or a question
   3. CSaving it for the annual review
   4. DOnly giving positive feedback
   Show answer

   B. Specific, timely feedback (situation, behaviour, impact) is actionable; vague or late feedback isn't.

   From lesson 09 · Mentoring and growing engineers

5. Q5. Which four DORA metrics describe software delivery performance?

   1. ALines of code, commits, tickets, meetings
   2. BDeployment frequency, lead time for changes, change failure rate, and time to restore service
   3. CCPU, memory, disk, network
   4. DUptime, latency, errors, saturation
   Show answer

   B. Two measure speed and two measure stability; good platforms improve both together.

   From lesson 10 · Measuring platform success

6. Q6. What is the main risk of using platform metrics to compare or rank teams?

   1. AMetrics get too accurate
   2. BPeople optimise the number instead of the outcome, and stop reporting honestly
   3. CTeams become faster
   4. DDashboards get slower
   Show answer

   B. Once a measure becomes a target it stops being a good measure; use metrics to find problems and track improvement, not to judge people.

   From lesson 10 · Measuring platform success