GROUND TRUTH · ENGINEERING CAREERS
Root-Cause Analysis Starts With Questions Nobody Expected
A part failed, or a system crashed. The first useful question is rarely "what broke."
The obvious question rarely finds the real cause. The useful one is often unexpected.
When something fails, a mechanical part cracks, a server crashes, a batch of product comes back with the wrong tolerance, the natural first question is "what broke, and can we fix it." That question is not wrong, but it usually produces a fix for the symptom rather than the cause, and the same failure tends to come back later in a slightly different form. Engineers who are good at root-cause analysis tend to ask a different, less obvious first question, one that does not sound like it is about the failure at all: what changed. Not what is broken, but what is different now compared to when this worked correctly.
"What changed" is a more powerful question than "what broke"
A system that fails after working correctly for months almost never fails for no reason. Something is usually different: a new batch of raw material with slightly different properties, a software dependency that was updated, a process step that started running at a different temperature, a configuration value that someone adjusted for an unrelated reason. Asking "what changed" forces an investigation to look outward, across the whole system and its recent history, rather than immediately narrowing in on the component that happens to have visibly failed. This matters because the component that failed is often the victim of the real cause, not the cause itself: a bearing that seized might be the visible failure, but the actual cause could be a lubrication schedule that was quietly changed weeks earlier, and replacing the bearing without asking what changed will very likely just produce the same failure again on schedule.
The instinctive question vs the useful one
| What people think | What it actually is |
|---|---|
| "What is broken?" is the natural starting point | "What changed?" usually leads to the actual cause faster, because failures are often triggered by a change, not an inherent flaw. |
| The component that visibly failed is the cause of the failure | The failed component is often the victim of an upstream cause: a changed input, a changed condition, a changed assumption. |
| Replacing or fixing the broken part solves the problem | It solves the symptom. Without finding what changed, the same failure frequently recurs. |
Good investigations ask about the normal case, not just the failure
A second question that experienced engineers tend to ask early, and that beginners often skip, is: what does normal look like here. It sounds almost too basic to be useful, but a huge amount of root-cause work depends on being able to compare a failure against a well-understood baseline: normal operating temperature, normal response time, normal vibration signature, normal error rate. Without that baseline, it is easy to fixate on a number that looks alarming but is unremarkable for this particular system, or to miss a number that looks unremarkable but is well outside this system's normal range. An engineer investigating a server that "suddenly got slow" needs to know what response time was normal for that server specifically before a slower number means anything at all: five seconds might be alarming for one service and completely ordinary for another.
Asking who else is affected narrows the search dramatically
Another question that seems tangential but is often decisive is: is this happening everywhere, or only in specific circumstances. If a defect shows up in parts from one specific machine, one specific shift, or one specific supplier, but not others running the same process, that pattern itself is powerful evidence pointing toward the cause. Something about that particular machine, shift or supplier is different from the rest. If a software bug only occurs for users in one geographic region, on one browser, or during one time window, that pattern is not incidental detail; it is often most of the answer, because it eliminates every explanation that would apply equally everywhere. Engineers who ask "where does this happen and where does it not happen" early in an investigation frequently reach the real cause faster than engineers who focus entirely on a single failed instance in isolation.
Two different first questions, two different investigations
| Starting with "what broke" | Starting with "what changed / what's different" |
|---|---|
| Focuses immediately on the failed component | Looks across the system for a recent change or an inconsistency |
| Can produce a fix that addresses the symptom only | More often surfaces the upstream cause |
| Risks the same failure recurring later | Reduces recurrence because the actual trigger is addressed |
| Treats the failure as isolated | Treats the failure as one data point in a comparison |
The uncomfortable question is often the useful one
Root-cause investigations frequently hit a point where the honest next question is uncomfortable, did we skip a test step to save time, did someone approve a change without the usual review, was a known issue previously flagged and left unresolved. These questions are less pleasant to ask than "which part number failed," and there can be real organizational pressure to avoid them, especially if the answer implicates a process decision rather than a component defect. But avoiding them does not make the underlying cause go away. It just delays the next occurrence of the same failure. Engineers who are trusted with root-cause work earn that trust partly by being willing to ask the question that might have an uncomfortable answer, rather than stopping the investigation once a plausible-sounding technical explanation has been found.
The five-whys technique is useful and also easy to do badly
A common structured technique for root-cause work is repeatedly asking "why": the part failed, why; because a bearing seized, why; because lubrication was insufficient, why; because the lubrication schedule had changed, why; because a new maintenance vendor was using a different schedule template, until the chain of questions reaches something an organization can act on. Done well, this technique is effective at pushing past the first, most visible explanation. Done poorly, it produces a single, tidy linear chain that ignores the reality that most real failures have more than one contributing cause branching off at different points, and forcing every investigation into one straight-line chain of five whys can quietly discard a second contributing factor that the investigator happened not to think to ask about. Experienced practitioners tend to treat five-whys as a way to generate candidate branches to investigate, not as a rigid script that produces exactly one correct chain ending in exactly one correct cause.
Timeline reconstruction is unglamorous and usually decisive
One of the least exciting parts of a root-cause investigation is also one of the most reliably useful: building an actual, detailed timeline of events leading up to the failure, with real timestamps, rather than working from memory or general impression. Two events that "felt like" they happened around the same time can turn out, once the actual logs or records are checked, to have been hours apart, which can completely change whether one is a plausible cause of the other. A maintenance action logged at 2:14 PM and a failure detected at 2:16 PM is a very different relationship than the same two events eight hours apart, even though a rough verbal account of "maintenance happened, then it failed" sounds identical either way. Engineers who build the habit of reconstructing an exact, evidence-based timeline before forming a theory tend to rule out plausible-sounding but wrong explanations faster than engineers who reason from a looser, memory-based sense of what happened when.
A confirmed cause still needs a mechanism, not just a correlation
Finding a factor that correlates with a failure, a specific supplier, a specific software version, a specific shift, is progress, but it is not the same as understanding the cause, and treating a correlation as the finished answer can lead to a fix that addresses the wrong thing. If failures cluster around one supplier's batches, the investigation is not done until someone can explain what is physically or procedurally different about that supplier's material that would produce this specific failure: a dimensional difference, a material property variance, a different handling process. Without that mechanism, a team might switch suppliers and fix the problem by accident, or might switch suppliers and have the same failure recur later because the real cause was something else that happened to correlate with that supplier during the investigation window. A root cause is not fully established until there is a believable story for exactly how the suspected factor produces the observed failure.
Questions worth asking before the obvious one
- What changed recently, in materials, configuration, process, code, or environment, before this started happening?
- What does the normal, working case look like, in specific numbers, not just impression?
- Is this happening everywhere, or only under specific conditions, and what is different about those conditions?
- Is the failed component the actual cause, or could it be the first visible victim of something upstream?
- Is there an uncomfortable possibility, a skipped step, a known issue, a shortcut, that the investigation should not avoid just because it is uncomfortable?
References and further reading
Background reading on the topic of this article. HireSetu is not affiliated with these organisations.