A draft postmortem lists the root cause as "human error — the operator ran the wrong command." Why would an SRE reject that, and what should the document say instead?

## Why the finding is unusable A postmortem exists to change something. "The operator ran the wrong command" changes nothing: the only remediation it suggests is that the operator be more careful, and carefulness is not a control you can deploy, monitor or verify. Worse, the finding is almost always true and almost always irrelevant — a human did indeed act, and saying so tells the next team nothing they can use. The rule of thumb is blunt: **if the only lever your root cause offers is a person's future attentiveness, you have not finished the analysis.** ## Hindsight bias, and the second story After an outage you know which of fifteen signals mattered. The operator did not. Reading the incident backwards from the outcome makes every missed cue look obvious and every decision look negligent, which is why safety literature insists on reconstructing the *second story*: the situation as it appeared from inside, with only the information available at that moment. The first story is "they ran the wrong command." The second story is "the runbook's copy-paste block still referenced the old namespace, the prompt in both shells is green, and the command has no dry-run flag." A reliable tell that a draft is still stuck in the first story is **counterfactual language**: *should have*, *could have*, *failed to*, *didn't bother to*. Each of these describes a world that did not happen and implies a choice that was never consciously available. Replace them with what the person actually perceived and did: - Before: "The on-call engineer failed to check which cluster the shell was pointed at." - After: "The shell prompt does not display the target cluster; the engineer had switched context nine minutes earlier while handling a separate alert." The second version is more specific, not vaguer — blamelessness raises the precision bar rather than lowering it. ## The three questions that replace the finding **Reachable.** Was the destructive action available on the default path, without friction proportional to its blast radius? Dangerous operations should be harder to perform than safe ones: an explicit typed confirmation, a dry-run default, a required second approver, a scoped credential that simply cannot address production. **Plausible.** What made the wrong action look right at that moment? Production and staging that are visually indistinguishable. A runbook whose steps drifted from reality two releases ago. An alert whose text names the wrong service. Pressure — the outage was already active, and speed felt cheaper than verification. **Undetected.** Why did the system not catch it? Was there no guard on the action, no confirmation of scale before deletion, no alert on a sudden drop in row counts, no soft-delete window that would have made recovery cheap? These three questions convert a dead-end into a list of concrete, ownable changes. ## Prefer stronger controls than training Safety practice ranks controls roughly as: eliminate the hazard, substitute something safer, engineer a guardrail, then fall back on procedure and training. "More training" and "be careful" sit at the bottom because they decay, do not transfer to new hires, and fail exactly when the system is under stress. If a postmortem's remediation list is dominated by documentation and training items, that is a signal the analysis stopped one layer too early. ```bash #!/usr/bin/env bash set -euo pipefail # The action a postmortem would label "human error": # destructive, silent about its target, no confirmation. delete_data() { rm -rf "${DATA_DIR:?DATA_DIR must be set}"; } # The system fix: the dangerous action states its target and demands a typed match. delete_data_guarded() { local target="${DATA_DIR:?DATA_DIR must be set}" printf 'DELETE %s on host %s\n' "$target" "$(hostname)" read -r -p 'Type the directory path to confirm: ' confirm [[ "$confirm" == "$target" ]] || { echo 'aborted'; return 1; } rm -rf "$target" } ``` ## What about genuinely poor judgement? It happens, and pretending otherwise damages credibility. The response is still not to write "human error" in the document. If someone knowingly disregarded a substantial, understood risk, that is a management conversation with their manager, held privately and on its own evidence. The postmortem still records what the system permitted, because the next person to be pressed for time deserves the guardrail regardless of what the last person's intentions were. ## How to answer this in an interview Interviewers use this prompt to separate people who have read about blameless postmortems from people who have edited one. Show the edit: quote the bad line, name hindsight bias and counterfactual phrasing, then produce the replacement findings and the corresponding controls. Mentioning that you would *reject the draft in review* — that this is a normal editorial act, not an accusation against the author — lands particularly well.