Writing the Contributing Factors Section of a Post-Mortem
Blameless systemic analysis, 5 Whys, and documenting interacting causes in incident reports
Contributing factors writing principles
- Blameless: describe systemic conditions, not individual failures — "the process did not…", not "the engineer failed to…"
- Specific: include the exact threshold, setting, or gap — vague factors are not actionable
- 5 Whys: ask "why" at least 4 times to reach the systemic root cause
- Multiple factors: list each one separately and note interactions between them
- Measurable impact: quantify where possible — "delayed detection by 12 minutes"
Question 0 of 5
What is the key principle that distinguishes a "contributing factors" section from assigning blame in a post-mortem?
Option B is correct. The blameless post-mortem principle, established by Google's SRE culture, focuses on systemic conditions rather than individual failures. Contributing factors describe the environment, processes, and systems that created the conditions for the incident — not the people who triggered it. Example: instead of "Engineer X deployed without reviewing the change", write "The deployment process did not enforce mandatory peer review for production changes." The systemic framing enables actionable fixes (improve the process) rather than punitive ones (discipline the person). This also encourages honest post-mortem participation.
Which entry is the most effective way to document a contributing factor?
Option B is correct. A strong contributing factor entry includes: (1) the specific condition (alert threshold at 95%), (2) what happened as a result (pool reached 98% before alert fired), and (3) the measurable impact on the incident (detection delayed by 12 minutes). This level of specificity makes the factor actionable — the fix is clear: lower the threshold. Option A is factually true but too vague to be actionable. Option C diagnoses a category problem without the specifics needed for a fix. Option D is blame-adjacent (implies the team should have done something) rather than systemic. Good contributing factors are specific, measurable, and system-focused.
A post-mortem lists "the engineer was not trained on the new deployment tool" as a contributing factor. How should this be reframed systemically?
Option B reframes an individual knowledge gap as a systemic process failure: the onboarding checklist was not updated when the tool was adopted. This is the correct blameless transformation — from "the person didn't know" to "the system didn't ensure they would know." The fix is systemic (update the onboarding checklist) and prevents the same gap for all future engineers, not just this one. Option A restates the individual framing. Option C is a process proposal, not a contributing factor description. Option D is explicitly blame-assignment. Every "the person did X wrong" can usually be reframed as "the system allowed X to be done wrong without detection or prevention."
Which sentence correctly uses the "5 Whys" technique to surface a deep contributing factor?
Option B demonstrates the 5 Whys chain correctly. Each "why" peels back one layer to reveal a deeper systemic cause: the visible symptom (crash) → immediate cause (too many connections) → technical cause (pooling disabled) → configuration cause (script bug) → process cause (not tested against real config). The deepest cause ("not tested against production-representative config") is the most actionable systemic fix. Option A stops at the first why. Option C stops at the third. Option D is already at the corrective action stage, skipping the analysis. In contributing factors sections, use 5 Whys to move from symptoms to systemic causes, then document each layer.
How should a post-mortem contributing factors section handle a situation where MULTIPLE factors combined to cause the incident?
Option C is correct. Most real incidents are caused by a combination of factors — the "Swiss cheese model" of accident causation: multiple layers of defence each have holes, and the incident occurs when the holes align. A good contributing factors section: (1) lists each factor as a separate, numbered or bulleted entry, (2) where relevant, notes how factors interacted ("Factor 2 amplified the impact of Factor 1 because…"), and (3) avoids ranking them by blame. Example structure: "CF1: Deployment occurred during peak traffic window. CF2: Feature flag rollout was 100% rather than incremental. CF3: No circuit breaker was in place for the affected downstream service. CF2 and CF3 combined to make CF1's impact total rather than partial."