Diagnose the true cause of a problem — not just its symptoms — using structured techniques like 5 Whys, Fishbone diagrams, and contributing factor analysis.

Root Cause Analysis

Use this skill when you need to understand why something failed — not just what went wrong, but the underlying cause you can act on.

What it does

Root Cause Analysis (RCA) turns incident symptoms into a clear diagnosis using structured techniques:

5 Whys — keep asking “why” until you reach a fixable origin.
Fishbone diagram — map causes across six categories: People, Process, Technology, Data, Environment, Management.

The skill distinguishes between a root cause (the fundamental origin) and contributing factors (things that made the problem worse). That distinction changes what you fix and whether the problem stays fixed.

When to use it

An incident, defect, or outage happened and you need to know why.
You are preparing a post-mortem or incident review.
A process keeps failing in the same place and surface fixes are not working.
You want to separate “what happened” from “what actually caused it.”

What you get

A clear root cause statement.
The evidence chain behind it.
A list of contributing factors.
Recommended actions, ordered by whether they address the root cause or only contributing factors.

What you need

A clear symptom or failure to investigate.
Access to the person or system that observed the problem.
Any available logs, timelines, or context that show what happened.

Tips

Start with a precise problem statement. “The service went down” is a symptom; “the payment API returned 503 for 12 minutes during the 9 AM traffic spike” is a problem statement.
Keep asking “why” at least three levels before proposing causes.
Contributing factors are still useful to document — they reduce recurrence even if they are not the root cause.