I Don't Want the Details

An engineering incident prompted a senior leader to interrupt an explanation and say they didn't need the granular story; they already assumed people acted reasonably and wanted to move straight to preventative action. The piece argues that pursuing detailed why-questions after failures often produces neat explanations that reduce urgency to change. When everyone concludes the outcome was reasonable, organizations drift back into the same failure patterns. Postmortems that catalogue human errors or call for vague improvements like "communicate better" or "be more careful" create folklore rather than lasting fixes.

The recommended shift is to ask what concrete system or process will make the same class of failure less likely next time. Practical examples include clarifying ownership when key people are absent, defining how to handle requirements changes inside a launch window, and reducing alert noise so on-call engineers can act. Good corrective actions force decisions, survive staff turnover, and ideally prevent the class of mistake rather than relying on memory or goodwill. Accepting some failures is acceptable if done deliberately and with clear trade-offs. The leadership role is to trust people’s competence but insist on tangible changes that change outcomes.