Most engineering postmortems begin with the same question:
> What caused the outage?
It's an important question.
I just don't think it's the most important one.
There's another question that often determines whether an engineering organization actually improves:
> Given what we knew at the time, was our reasoning sound?
Those are not the same thing.
Imagine two production deployments.
In the first, the engineering team carefully reviews the change.
They identify assumptions.
They evaluate alternatives.
They create a rollback plan.
They monitor the deployment.
Despite all of that, an unexpected interaction with a third-party service causes an outage.
Now imagine a second deployment.
No review.
No rollback plan.
No discussion.
One engineer pushes directly to production on a Friday afternoon.
Nothing breaks.
If we judge engineering solely by outcomes, the second team appears more successful.
That should make us uncomfortable.
Psychologists call this outcome bias.
We evaluate the quality of a decision based on what happened rather than on the quality of the decision-making process itself.
In engineering, this creates dangerous incentives.
Successful shortcuts become accepted practice.
Careful decisions that encounter bad luck become viewed as failures.
Over time, organizations optimize for luck instead of discipline.
Every consequential engineering decision is made with incomplete information.
No team knows every dependency.
No architect predicts every edge case.
No incident commander sees the entire system.
The goal isn't perfect prediction.
The goal is making the best decision possible with the information available.
That means a postmortem should ask:
Notice that only one of those questions is about the outcome.
The rest are about the reasoning.
The most valuable postmortems I've participated in weren't memorable because of the outage itself.
They were memorable because they permanently changed how engineers approached future decisions.
Afterward, teams started asking questions they had never considered before.
They improved runbooks.
They added observability.
They documented assumptions.
They redesigned deployment procedures.
The incident became valuable because it improved judgment, not because it identified a single bug.
As AI generates larger portions of implementation, engineering organizations will face an uncomfortable reality.
AI can propose many plausible solutions.
Some will work.
Some won't.
If we evaluate AI-generated changes solely by whether they happened to succeed, we'll teach AI—and ourselves—the wrong lessons.
Instead, we should evaluate:
Those questions remain valuable regardless of whether the change ultimately succeeds.
Imagine replacing sections like:
Root Cause
with something broader:
Reasoning Review
Now the postmortem becomes more than an incident report.
It becomes an investment in organizational judgment.
This is the counterintuitive part.
Organizations that optimize reasoning won't necessarily make fewer mistakes immediately.
They'll make better mistakes.
Mistakes that produce new understanding.
Mistakes that improve future decisions.
Mistakes that don't need to be repeated.
That's how engineering organizations become more capable over time.
Not by avoiding every failure.
But by continuously improving the quality of the thinking that precedes every consequential decision.
In the long run, that's the only advantage that compounds.