Postmortems, Root Cause Analysis, and Blameless Culture Questions

Direct answer
Five Whys means repeatedly asking 'why did that happen' about the answer to the previous why, until you reach a condition that is actually fixable rather than just another symptom. It typically takes about five iterations, though the number is a rule of thumb, not a hard rule: you stop when you hit something you can change, not necessarily on the fifth why.

Structured elaboration
For the incident (a key API returned errors for 45 minutes after a deploy, affecting a fifth of users), a Five Whys chain might look like:

1. Why did the API return errors? Because the newly deployed version crashed on a specific request shape.
2. Why did it crash on that request shape? Because a null field that used to always be populated was left unhandled by new code.
3. Why was the field null? Because an upstream service started omitting it after its own recent change, and the API's input validation did not reject the malformed payload.
4. Why did input validation not catch it? Because the API's schema validation checks types but not presence of this particular field, and there is no contract test between the two services that would have caught the mismatch before deploy.
5. Why is there no contract test between these services? Because the team has no standard practice requiring consumer-driven contract tests for internal service dependencies, so this class of breaking change can slip through again.

Root cause at the fifth why: the absence of a contract-testing practice between dependent services, which let an upstream breaking change reach production undetected. Remediation: add a consumer-driven contract test between the two services that fails the upstream service's CI if it would omit a field the downstream API depends on, and, as an immediate mitigation, add explicit null-handling and a clear 400 response for the malformed field so a similar future gap fails safely instead of crashing.

Worked example
The chain above IS the worked example. The key discipline: each why answers the previous one specifically, not by restating a broader class of the same problem ('bugs happen') or jumping straight to a process indictment ('nobody tests enough'). Each step should be falsifiable, meaning someone could look at logs, code, or configuration and confirm or reject it.

Trade-offs and pitfalls
Five Whys works well for a single, mostly-linear causal chain, but it can mislead on incidents with multiple independent contributing factors, because it forces a single narrative thread and stops once any plausible chain reaches a stopping point, even if a second, unrelated factor also mattered. In this incident, if the on-call engineer's alert also fired 15 minutes late due to an unrelated threshold problem, a rigid Five Whys chain focused only on the crash would miss that second, independently-worth-fixing gap. When you suspect multiple contributing factors, pair Five Whys with a fishbone diagram or explicit causal-chain mapping so parallel factors don't get dropped.

Direct answer
Quantitative evidence (metrics, logs, traces) tells you what happened and when with precision but can miss context and intent; qualitative evidence (engineer interviews, notes, chat logs) fills in the why and the human decision-making, but is subject to memory bias and self-justification. Weigh them together, and when they conflict, treat the disagreement itself as a finding worth investigating rather than picking whichever is more convenient.

Structured elaboration

• Quantitative evidence is precise and timestamped, which makes it the backbone of any timeline, but it can be silent on intent and context: a metric shows latency spiked at 14:03, but not why an engineer chose to deploy at that specific moment or what they believed was true when they did.
• Qualitative evidence captures reasoning and context that logs can't ("I deployed because the dashboard looked fine and I didn't know about the downstream dependency"), but human memory reconstructs events after the fact, often unconsciously smoothing over uncertainty or minimizing one's own role, so it should never override hard timestamped data when the two genuinely conflict.
• Correlating them into one timeline: anchor the timeline on quantitative events (deploys, alerts, metric changes) first, since those are objective and timestamped, then layer qualitative context alongside each event (what the engineer believed, what they were looking at, why they made a given call) as annotation, not as competing facts.
• When they conflict: if an engineer recalls checking a dashboard that logs show wasn't accessed, that's not necessarily dishonesty, memory under stress is genuinely unreliable, but it IS worth investigating why the gap exists: was there a different dashboard, a misremembered timestamp, or a real gap in what was actually checked before the decision was made. The conflict itself, not just its resolution, is often informative about where the process broke down.

Worked example
An engineer recalls seeing a warning-level alert before deploying and deciding it looked minor enough to proceed. Logs show no alert fired until four minutes after the deploy. Rather than concluding the engineer is simply wrong or dismissing the recollection, the investigation digs further and finds the engineer was actually looking at a stale, cached view of the dashboard that hadn't refreshed in several minutes, itself a real and separately worth-fixing gap (a dashboard that can silently show stale data during exactly the moment it matters most). The quantitative record established what actually happened; the qualitative account, once reconciled rather than dismissed, revealed a genuine, previously-unknown contributing factor that the logs alone would never have surfaced.

Trade-offs and pitfalls
The most common mistake is treating quantitative data as always authoritative and qualitative accounts as merely decorative color, which misses genuine contributing factors that only surface through human context. The opposite mistake, treating a confident personal recollection as more reliable than the logs when they conflict, risks building the postmortem's conclusion on a memory distortion. The discipline is to anchor on timestamped data but take conflicting qualitative accounts seriously enough to investigate the gap, not dismiss either source reflexively.

Direct answer
Acceptance criteria for a corrective action should be a specific, measurable, time-boxed statement of what 'fixed' looks like, defined before the work starts, not after. A verification plan then confirms that criterion is actually met using real data, not just confidence that the fix was implemented correctly.

Structured elaboration

• Define the metric and target explicitly. Not 'reduce timeouts' but 'reduce the service's timeout rate from its current baseline to a specific target percentage, measured over a specific window.' A vague criterion can't be verified; a specific one can.
• Set a monitoring window long enough to be meaningful. Too short a window risks declaring success on noise; too long delays knowing whether the fix worked. The right window depends on the incident's natural frequency, for example enough days to capture a representative mix of peak and off-peak traffic.
• Separate short, medium, and long-term verification. Immediately after deploying the fix: a targeted test or synthetic check confirms the mechanism works as intended. Over the following weeks: real production monitoring against the target metric confirms it holds under real conditions, not just in a controlled test. Longer term: a periodic audit or scheduled re-check confirms the improvement is durable and hasn't quietly regressed.
• Define what "success" and "failure" mean numerically in advance, including what would trigger reopening the item if the target isn't met, so there's no ambiguity or motivated reasoning once the data comes in.
• Name who signs off, so verification isn't just a self-assessment by whoever implemented the fix.

Worked example
A corrective action targets reducing a service's timeout rate from 0.5% to 0.05% within 30 days. Acceptance criteria: timeout rate, measured as a 7-day rolling average, must be at or below 0.05% for two consecutive weeks within the 30-day window, using the same monitoring dashboard and definition of 'timeout' used to measure the original 0.5% baseline. Verification plan: short-term, a synthetic load test immediately after deploy confirms the fix reduces timeout rate under simulated peak load; medium-term, the real 7-day rolling average is checked weekly against the target for the full 30 days; long-term, the metric is re-checked at 90 days to confirm it hasn't quietly crept back up as traffic patterns shift. If the 30-day window ends with the metric at 0.15%, that's a defined failure, not an ambiguous 'mostly worked,' and it triggers a re-investigation of whether the fix addressed the actual root cause or only a symptom.

Trade-offs and pitfalls
The most common mistake is defining acceptance criteria loosely enough that almost any outcome can be called success, which defeats the purpose of having criteria at all. A second is skipping the longer-term recheck: many fixes look successful in the first two weeks and then quietly regress as conditions change, and without a scheduled longer-term verification, that regression goes unnoticed until the incident recurs.

Direct answer
A short executive postmortem summary should fit in roughly 150 to 200 words and cover exactly four things: impact, root cause in one sentence, key corrective actions, and the expected timeline for completing them. Everything else belongs in the linked full postmortem, not the summary.

Structured elaboration
The discipline here is compression without losing the load-bearing facts: an executive reading this in thirty seconds should know what happened, how bad it was, why, and what's being done, without needing to ask a single follow-up question about the basics.

Worked example
"On [date], an autoscaling policy misconfiguration caused the checkout service to under-provision during a traffic spike, resulting in a three-hour partial outage. Approximately 15% of checkout attempts failed or timed out during the peak of the incident, affecting an estimated 40,000 orders; no customer data was exposed. Root cause: a recent change to the autoscaling policy set a maximum instance count too low for current traffic levels, and no alert existed to catch an autoscaling ceiling being reached. Immediate mitigation: on-call manually scaled the service within 12 minutes of detection, and full service was restored within three hours as the traffic spike subsided. Corrective actions: (1) raise the autoscaling ceiling to match current capacity planning, completed same day; (2) add an alert that fires when autoscaling hits its configured ceiling, targeted for completion within one week; (3) add autoscaling ceiling review to the quarterly capacity-planning process, targeted for next quarter. We expect all three actions complete within 30 days and will confirm the new alert has been validated against a synthetic test before considering this closed."

That's roughly 180 words and answers all four required elements without technical jargon an executive would need explained.

Trade-offs and pitfalls
The most common mistake is trying to also explain the full technical mechanism (why the specific autoscaling algorithm behaved this way) inside the short summary, which blows past the word budget and buries the four things that actually matter to this audience. A second is omitting a concrete timeline and just saying 'we are addressing this,' which reads as less credible than named actions with dates, even when the actions themselves are modest.

Direct answer
This is a behavioral question best answered with a specific story showing you distinguished a genuine pattern from a one-off, kept the accountability conversation separate from the group postmortem, and led with coaching rather than punishment, while still being clear about the standard expected going forward.

Structured elaboration
A strong answer covers: the situation (what happened, why it warranted an accountability conversation rather than just the standard blameless process), how you determined it was a genuine pattern rather than bad luck, how you had the conversation itself (privately, focused on support and root cause rather than judgment), and the outcome, including how you protected the person's and the team's trust in future incident reporting.

Worked example
"An engineer on my team was involved in a second incident within two months, both traced to skipping the same pre-deploy verification step under time pressure. Before assuming it was negligence, I checked whether this was a genuine pattern: both incidents shared the same specific gap, so it was, rather than two unrelated issues that happened to involve the same person. I had a private conversation, not as part of the group postmortem, focused on understanding what was driving it. It turned out they'd been covering an unsustainable amount of on-call load for a teammate on leave and had started rushing to keep up. I addressed both sides: the workload issue got fixed by redistributing on-call coverage, which was the real systemic driver, and I paired them with a more experienced engineer on deploy discipline for a few weeks as direct support, framed clearly as investment in them, not punishment. Separately, the second incident's actual group postmortem stayed fully blameless and produced an automated pre-deploy gate that makes that specific step impossible to skip regardless of who's deploying, which is the fix that protects the whole team, not just this one person. Three months later there'd been no recurrence, and, just as important, the engineer's incident-reporting behavior stayed just as open as before, which told me the accountability conversation hadn't damaged their trust in the process."

Trade-offs and pitfalls
The most common weak answer either skips the distinction between pattern and coincidence (treating any second incident as automatic proof of a problem) or focuses entirely on the disciplinary angle without addressing what was actually driving the pattern, which misses the more senior insight that repeated mistakes are frequently a symptom of a systemic issue (workload, unclear process, inadequate training) rather than a character flaw.