Contributing Factors Analysis
Identifying the multiple conditions that combined to produce an incident, in place of searching for a single root cause.
Complex systems do not have root causes. An incident happens because several conditions were true at once: a latent bug, a configuration that made it reachable, monitoring that did not detect it, an alert routed to the wrong team, a runbook that was out of date, and a responder without the permission to act.
Removing any one of them might have prevented or shortened it. Naming one as the cause is a choice, and it is usually a choice that stops the analysis early — most often at the last human action, which is the least useful place to stop.
The practical consequence is better action items. "Fix the bug" addresses one condition. Contributing factors analysis also produces "add detection for this class of failure", "correct the alert routing", "grant the on-call rotation this permission" — improvements that generalise to incidents nobody has had yet.
Techniques that support it: asking why repeatedly along several branches rather than one; building the timeline first and asking at each step what information was available; and explicitly asking what made this worse than it needed to be, which separates the trigger from the amplifiers.
The distinction worth carrying: the trigger is what started it; the contributing factors are why it was possible, why it was not caught, and why it lasted as long as it did.