LEARN. PRACTICE. GROW.Measure the right unit
Fifty fictional deployments produce 150 events: start, technical completion, and validation for each execution. Dashboard row count is not deployment frequency. Relate events by execution identity before counting. Inspected DORA documentation presents five measures and distinguishes unplanned rework caused by incidents from deployments requiring immediate intervention. In this example, five deployments belong to the first group and two to the second: 10% rework and 4% failure, with the same denominator of fifty. Do not add the groups to invent a new rate; they may overlap and have different meanings. Present period, service, definition, and collection limits. Use trends to investigate improvement within the service context. Comparing frequency between a daily application and an annual process is insufficient to rank teams. Confirm that a reporting change has not altered the measured population before attributing improvement to a process change.
Keep difficult outcomes visible
Waits of 2, 2, 3, 3, and 40 hours have a three-hour median. This does not establish that nobody waits long: the forty-hour case remains relevant. The previous lesson's code shows the set's center and maximum without inferring causes. After an incident, a latency increase near a change merits investigation; if load also doubled, temporal sequence does not establish sole causation. Separate facts, hypotheses, and needed information. Review should produce observable actions with owners and dates. For a handover-access gap, “take more care” does not specify how to verify improvement; an authorized demonstration with the receiving team can do so. Keep deferred tests pending until outcomes or an explicit treatment decision exist. If the owner left, resolve assignment and current exposure. Record which evidence would establish that the action achieved its intended effect.
Include removal and dependencies in decisions
Old middleware without interactive traffic for twenty days may still serve a monthly process. Removal needs understanding of consumers, data or state to preserve, recovery capability, job references, and support responsibilities. An unexpected attempt during reversible disablement should prompt dependency investigation before permanent deletion. Inspected Microsoft guidance recommends considering usage and references during removal; this exercise's conditions and timings are original. Do not declare full savings merely because a machine is switched off: residual costs and obligations may remain. In the decision, distinguish expected benefit, cost of completing removal, and risk from dependencies still needing confirmation. If the reference is truly stale, gather evidence with its owner. If still needed, plan migration or another alternative before removal. Keep the state of each dependency visible so that incomplete work does not disappear when the infrastructure ticket closes.
Session guide and decision observation
This guide is prepared but has not been executed by human participants. Use Change Manager, service owner, operations, development, and observer roles; in an individual session, record combined roles as a limitation. At minute zero, present a changed export and acceptance limited to position queries. At minute five, provide a decision conditional on partner confirmation, showing only proof of sending. At minute ten, reveal the window until 04:15 and coverage until 03:30. At minute fifteen, use the 03:20 recovery timings and request an English note. At minute twenty, introduce the monthly consumer during removal. At minute twenty-five, present the dashboard with 150 events. Reserve fifteen minutes for discussion: the observer records decisions, evidence, assumptions, owners, and pending work. Repeat one phase after feedback, comparing observed behavior without awarding professional certification. The arithmetic model supports checking numbers but does not assess the participant's authority, communication, or actual recovery capability.
Phase | Decision | Evidence | Assumption | Owner | Next checkpoint
0: impact by consumer
5: conditional confirmation
10: coverage and handover
15: recovery and English note
20: monthly dependency
25: measurement unit
30–45: feedback and repetitionThe observer may record: “identified the 03:34 boundary but did not ask whether the recipient applied effects.” Repeat the phase requesting that evidence.
Common pitfalls
Events treated as deployments; median as maximum; association as cause; brief inactivity as no consumer; a written guide as completed practice.
Related topics: Delivery metrics · Decommissioning · Learning and exercises
Measure with clear definitions and use review to turn specific gaps into actions whose results can be observed.
Reference: Postmortem Culture: Learning from Failure · NIST SP 800-128 updated October 2019; DORA five-metric model and change approval guidance; vendor documentation inspected 2026-10-01