"Human error" describes what happened, not why it was possible. If a review ends there, the only action left is to remind people to be careful, which does not change anything. Keep asking why the action made sense at the time and what the system did to allow it.
The problem with the label
Someone clicked a link, pasted a secret into the wrong place, or approved a change without noticing a flaw. All true. But the same person will not be the last to do it. A fix that depends on perfect attention has a short life.
Google's postmortem chapter says you cannot fix people, but you can improve the systems and processes that support their decisions. That is the whole argument in one line.
Questions that go deeper
Try these in place of "who made the mistake".
- What information did the person have at that moment?
- What did the tools show or hide?
- Was the safe path harder than the risky one?
- Did anything warn them, and could they tell the warning from noise?
- Was this person trained and authorised for the task?
- How many others could have done the same?
Examples of reframing
- Stated cause: Engineer committed a key; Better question: Why could a key be committed?; Possible fix: Pre-commit and server-side secret checks
- Stated cause: Analyst closed a real alert; Better question: Why did it look like the other hundred?; Possible fix: Fix alert quality and context
- Stated cause: Admin approved a risky change; Better question: What did the approval screen show?; Possible fix: Show the diff and the blast radius
How deep is deep enough
The chapter asks for a root cause analysis that is sufficiently deep. A practical test: if your action items could be summarised as "be more careful" or "train people again", go further.
Keep the human in the story
None of this removes the person from the timeline. It puts them in context. Interview them early, treat their account as data, and thank them for it. The person closest to the error often knows exactly which part of the system set them up.
A short case sketch
Imagine an engineer approves a pull request that adds an overly broad access rule. The first draft of the review says the reviewer missed it. Asking the better questions turns up that the review screen showed only a few changed lines, the policy was in a file with hundreds of similar rules, and there was no test for rule breadth.
The fix is then a test and a clearer diff view. Next quarter a different reviewer, on a busy day, benefits from it too. That is the practical gain of looking past the person.
Quick check
Is training ever a valid action item?
Sometimes, if there is a real knowledge gap. Pair it with a system change, so the next person does not depend on remembering the lesson.
Sources
Last reviewed: 19 October 2026.
