Beyond 'Root Cause': Proximate vs. Contributing Factors

Why it exists

Failures in complex systems are rarely caused by one single thing. We need a vocabulary to distinguish between the immediate trigger of an event and the deeper, systemic issues that allowed the trigger to have an effect. This prevents us from simply fixing the last mistake and instead encourages us to fix the system that produced the mistake.

The mental model

Think of a building collapsing in an earthquake. The earthquake is the proximate cause—the direct, immediate event that led to the collapse. The contributing factors are the non-compliant building codes, the use of substandard materials, and the failure to perform required inspections. Fixing only the 'proximate cause' is impossible (you can't stop earthquakes), but addressing the contributing factors can prevent future collapses.

How it works

In a post-mortem, you first identify the proximate cause: the specific action or event that directly preceded the incident, like a bad deploy. Then, you ask 'why' repeatedly, not to find a single 'root cause,' but to uncover the network of contributing factors. Why was the bad code not caught in CI? Why could a developer merge without review? Why did monitoring not alert immediately? Each answer is a contributing factor. The goal is to map these factors, not to find one ultimate source.

When to use it

Use this framework in any incident review for a complex system. It's the foundation of blameless post-mortems, as it shifts focus from individual actions (often the proximate cause) to systemic vulnerabilities (the contributing factors). This is central to how Site Reliability Engineering (SRE) learns from failure.

When not to use it

The distinction is less useful for simple, non-systemic failures where the cause-and-effect chain is truly linear. If a single hard drive fails due to a manufacturing defect and is replaced, a deep dive into contributing factors may be overkill, unless it reveals a systemic issue like untested backups.

One canonical example

A junior engineer pushes a code change that brings down production. The proximate cause is the engineer's commit. A shallow analysis stops there and blames the engineer. A proper analysis identifies the contributing factors: a confusing API that made the mistake easy to make, a CI/CD pipeline that lacked adequate tests for this failure mode, a lack of canary deployments, and monitoring that was too slow to alert. The contributing factors are where the real engineering fixes lie.