Resolving post-mortem disagreement with data

WHAT THIS TESTS Whether you facilitate with objective data and can hold space for multiple contributing causes rather than letting opinion or rank decide.

A GOOD ANSWER COVERS Reframe the disagreement as an empirical question and anchor it in a precise timeline. Pull the data that ties cause to effect: deploy and config-change logs with timestamps, distributed traces showing where latency or errors originated, error-rate and latency metrics, and resource saturation like connections, CPU, or memory. The decisive test is correlation with onset: which candidate event's timestamp matches the exact moment symptoms began. If engineer A blames a deploy and B blames traffic, the deploy marker versus the traffic curve at the onset instant usually settles it. Crucially, real incidents often have several contributing factors, so the facilitator should quantify each rather than force a single winner, and capture both in action items.

COMMON WRONG ANSWERS Letting the senior or louder engineer win. Forcing one root cause when the data shows two. Debating from memory instead of pulling logs.

LIKELY FOLLOW-UPS What if the data is ambiguous or missing? How do you handle ego in the room? How do you decide which factor to fix first?

ONE CONCRETE EXAMPLE Two engineers disagree: one says a new deploy caused the latency, the other says a traffic spike. You overlay the deploy marker, the request-rate metric, and p99 latency on one timeline. Latency rose at 14:00 exactly when the deploy landed, while traffic only climbed at 14:20, after the problem started. The deploy is clearly the trigger, but the data also shows traffic worsened it, so both become contributing factors with separate, prioritized fixes, resolving the debate on evidence rather than rank.