Postmortems without ceremony
Take a familiar incident. A deploy takes down a checkout for forty minutes. A migration that looked safe in staging locks the orders table in production because the staging dataset was 400 rows and production was two million. By the time anyone notices, customers have sent screenshots of failed payments.
You fix it, restore the old build, and send a note to whoever was affected. Then the whole team sits down for thirty minutes the next morning. That is the postmortem.
When a team is small, the standard postmortem format gets in the way. We do not need a document with sections for timeline, contributing factors, action items, and lessons learned. Everyone was on the call. Everyone watched the monitoring dashboard go red. The timeline is not in dispute. What we need is to agree on what actually happened, decide what we are changing, and get back to work.
The meeting has three parts, and we keep them strict.
First, one person explains what they think went wrong, start to finish. Not what the process was supposed to be — what they actually did, in the order they did it. The others listen and correct. This takes about ten minutes because there is no ambiguity about who did what. On a small team, whoever ran the migration explains it.
Second, we ask one question: what would have caught this before it reached production. Not five questions. Not a root cause analysis with a five-whys exercise. One question, and we hold ourselves to honest answers. In the migration example the answer is straightforward: it was tested against a dataset that did not represent production scale. There is a staging database, but it gets seeded from a small sample. The size difference is the gap.
Third, we pick one or two changes and assign them to a person with a date. Not a backlog of improvements. One or two. If we cannot narrow it to two, we have not understood the problem.
For the migration example, two changes are enough. One person writes a script that copies a production-sized snapshot into staging weekly. Another adds a check to the deploy script that warns when a migration includes an `ALTER TABLE` on a table over 100,000 rows. Both fit comfortably inside the same week.
The thing about a small team is that the postmortem is not really about learning. We know what happened. We were there. It is about deciding what is worth changing and actually changing it. A template does not help with that. A conversation does.
We keep a single page in our internal wiki with a list of incidents and the one or two changes that came out of each. It is not a report. It is a record of decisions we made, so that six months later when someone asks why staging has a full production snapshot, we can point to the entry. That is the only artifact.
Whoever was affected does not see the postmortem. They see the fix and the note. If a change we make affects them — a new staging process, a deploy script that now pauses on large migrations — we mention it in the next status update. But the postmortem itself is internal, because it is for us, and the ceremony of a formal document would be for someone else.
Thirty minutes is cheap. The test of whether it was worth it is whether the changes catch the next one. A deploy script that pauses on an `ALTER TABLE` against a large table will, sooner or later, stop someone from adding a column to the payments table without checking the row count first. When it does, that is the postmortem paying for itself, and the wiki entry is where you find out why the check exists.