Complete the incident timeline before writing any causal…
When drafting incident postmortems or failure analyses, complete the timeline of observable events (with timestamps and measurements) before writing any causal analysis, because mixing observation and explanation during collection produces defensive filtering.
When This Fires
- Drafting incident postmortems after production outages
- Writing failure analyses for project delays or missed objectives
- Conducting any blameless retrospective where facts need to be separated from narratives
- Investigating any situation where multiple people have different accounts of "what happened"
Common Failure Mode
Starting the postmortem with "what went wrong" or "root cause" sections. These frames invite causal analysis before the timeline is established. People jump to explaining before the group has agreed on what actually happened. Disagreements about causes get confused with disagreements about facts. The resulting document is a negotiated narrative, not an investigation.
The Protocol
(1) First pass — timeline only: gather every observable event with timestamps, measurements, and log evidence. No "because" statements. No explanations. Just: "14:23 — deploy initiated. 14:31 — error rate exceeded 5% threshold. 14:38 — first alert fired. 14:52 — engineer acknowledged." (2) Review the timeline as a team. Fill gaps, correct timestamps, add missing events. (3) Only after the timeline is complete and agreed-upon, begin causal analysis. The question shifts from "what happened?" (settled) to "why did this sequence of events occur?" (open for investigation).