The cost of silence: why your engineering team stopped writing postmortems

The first thing I look at when assessing an engineering team is not their architecture diagram, their CI/CD pipeline, or their on-call schedule. It is their postmortem archive. If they have one.

Most teams do not have one. They have incidents, plenty of those, but the written record of what happened, why it happened, and what they learned is either missing, shallow, or performative. The postmortem has become a ritual that teams know they should do but quietly skip, the engineering equivalent of flossing.

The three postmortem pathologies

Pathology one: the postmortem that never gets written

The incident happens. The team fights fires, restores service, and breathes. Someone says “we should do a postmortem for this.” A Slack channel is created. A document is started. Two weeks later, the document has a title and the first sentence: “On [date], we experienced an elevated error rate.”

That is it. The document never gets finished. The Slack channel goes quiet. The incident fades from memory until the same thing happens again three months later, and nobody connects the two because the first one was never documented.

This is the most common pathology. The team has the intention but not the discipline. Postmortems are treated as optional, and optional work does not get done in engineering teams that are already stretched thin.

Pathology two: the blameless postmortem that blames

The document gets written, but it is not actually blameless. It uses passive voice to hide blame: “a misconfiguration was introduced,” “a deployment was made without proper review,” “a developer did not follow the runbook.”

Read between the lines and the blame is obvious. Everyone knows who “a developer” is. The postmortem says blameless but the culture says the opposite. The engineer who caused the incident reads the document, feels the implicit accusation, and becomes more cautious. Next time, they will not take the risky deploy. They will wait for someone else to do it. The team gets slower, not safer.

Pathology three: the postmortem as theatre

The document is thorough. It has a timeline, root cause, contributing factors, action items with owners and deadlines. It is filed in the postmortem archive. It looks great.

But the action items are never completed. The root cause analysis stops at the technical layer: “the database connection pool was exhausted.” It never asks why: why was the pool sized for 50 connections when traffic had grown 10x? Why did nobody notice? Why was there no alerting on connection pool saturation? Why did the autoscaler not scale the database?

The postmortem describes what happened but not why it was allowed to happen. It treats the symptom, not the system. Three months later, the same class of incident recurs with a different symptom, and the team writes another postmortem that also stops at the technical layer.

What a good postmortem actually looks like

I have read hundreds of postmortems. The good ones share four characteristics:

They are written within 48 hours

Memory degrades fast. The engineer who was on call can reconstruct the timeline accurately for about 48 hours. After that, details blur, sequences get confused, and the postmortem becomes a reconstruction rather than a record. Write it while it is fresh. If you cannot write it within 48 hours, at least have the on-call engineer write the timeline while it is fresh. The analysis can wait. The timeline cannot.

They ask “why” five times

A Japanese manufacturing technique, the five whys, is the simplest and most effective root cause analysis tool I know. You ask “why” five times, drilling down from the symptom to the systemic cause.

• The API returned 500s for 12 minutes. Why?
• The database connection pool was exhausted. Why?
• A deployment opened 200 new connections instead of the expected 20. Why?
• The migration script did not close connections properly. Why?
• The migration script was not tested in staging. Why?
• Staging does not have a dataset large enough to trigger connection pool exhaustion. Why?
• Staging is provisioned at 10% of production capacity and nobody reviewed whether the migration script needed a larger test environment.

Now you have something. The fix is not “fix the migration script.” The fix is “review staging provisioning for workloads that are sensitive to scale, and add a checklist item for migrations that require scale testing.”

They produce action items that prevent the class, not the instance

A bad action item: “Add a connection pool size alert.” This prevents this specific incident from recurring unnoticed. It does not prevent the next connection exhaustion caused by a different path.

A good action item: “All database migrations must include a connection lifecycle test in CI, and staging must be provisioned at production scale for the migration window.” This prevents the class of incident, not just the instance.

They are read, not just written

A postmortem that nobody reads is a diary. A postmortem that is read, discussed, and referenced in future incidents is institutional memory. The practice that makes this happen is the postmortem review meeting, a 30-minute slot where the team walks through the postmortem, asks questions, and confirms action item ownership. Not every postmortem needs a meeting. But every postmortem needs at least one person other than the author who reads it and says: “I understand what happened and I know what we are doing about it.”

The cultural precondition

You cannot fix postmortem culture with a template. I have seen teams adopt the most beautiful postmortem template in the industry and still produce shallow, blameful, abandoned documents. The template is not the problem. The culture is.

The cultural precondition for honest postmortems is simple: it must be safe to have made a mistake. If the engineer who caused the incident fears consequences, they will not be honest about what they did. If the team lead looks for someone to blame, the postmortem will be a defense document, not a learning document.

This is not a process problem. It is a leadership problem. The CTO or VP of Engineering sets the tone. If they treat incidents as learning opportunities, the team will be honest. If they treat incidents as failures that need a culprit, the team will obfuscate.

I have watched a single sentence from a CTO change postmortem culture overnight: “I do not care who caused it. I care that we understand it and fix it so it does not happen again.” That sentence, repeated and enforced, is worth more than any template, tool, or process.

The cost of silence

When postmortems stop happening, the cost is invisible but compounding. The team repeats mistakes. Institutional knowledge stays in the heads of the engineers who were present, and when they leave, it leaves with them. New engineers onboard without the context of what has broken and why. The same incident patterns recur with increasing frequency, and each recurrence erodes trust between engineering and the rest of the company.

The cost of silence is not the incident. The cost is the second incident, the one that would have been prevented if the first one had been honestly documented, understood, and fixed.