Turning learnings into follow-ups that get done

Ask any seasoned engineer about post-incident learning and, sooner or later, you will hear some version of the same painful story: a serious outage, a thorough post-mortem, a thoughtful list of things to fix — and then, eight months later, the nearly identical outage, recurring because not one of those fixes ever shipped. The follow-ups were written. Everyone agreed they were important. And they died anyway, in the slow, quiet way that good intentions die in every backlog. This is the single most expensive failure mode in the entire discipline, because it means you paid the full price of an incident — the downtime, the stress, the customer trust — and bought none of the protection it was supposed to fund.

A follow-up is the mechanism by which a learning becomes a change in the system. Everything upstream of it — the blameless investigation, the well-written document — is preparation. The follow-up is where the team actually spends effort to make the next failure less likely or less severe. So the question that should haunt anyone who cares about reliability is not "did we learn something?" but "did the learning survive contact with our roadmap?" Most of the time, it doesn't, and the reasons are depressingly consistent and entirely fixable.

A follow-up is not a wish; it is a committed change with an owner

The first reason follow-ups die is that they were never really follow-ups — they were wishes. "Improve our deploy safety," "make alerting better," "be more careful with config changes": these are sentiments, not units of work. Nobody can pick one up, nobody can finish one, and nobody can tell whether it is done. A real follow-up is specific enough that a stranger could complete it and you could verify it: "add a canary stage to the deploy pipeline that holds at 5% of traffic for ten minutes before proceeding," "add an alert that pages when config validation rejects a change in production." If you cannot imagine the pull request that closes it, it is still a wish.

Every follow-up needs three things or it is not real: a single owner, a due date, and a clear definition of done. The owner is one person, not a team — "the platform team will handle it" is how work becomes nobody's job. The due date forces a conversation about priority now, while the incident is still fresh and the cost of inaction is still vivid, rather than in six months when it has to fight a feature for attention with no emotional weight behind it. And the definition of done keeps "improve alerting" from being declared complete by someone who tweaked one threshold. None of this is bureaucracy; it is the minimum structure that distinguishes a commitment from a hope.

Not every follow-up is equal — and pretending they are kills the important ones

A post-mortem often generates a dozen ideas, and treating them as a flat list is a quiet way to lose the few that matter. Some follow-ups are urgent and load-bearing — the missing guardrail that, absent it, guarantees this exact incident recurs. Others are genuine improvements but not existential — a nicer dashboard, a clearer runbook section. Mixing them together means the urgent ones get the same nonexistent priority as the nice-to-haves, and the whole list sinks together.

Separate them deliberately. A small number of follow-ups should be treated as incident-blocking: they are not done when the incident is "closed," they are the condition for considering this class of risk genuinely addressed, and they get roadmap priority accordingly. The rest can flow into normal planning, prioritized honestly against everything else, with the full understanding that some will lose and that is acceptable. What is not acceptable is letting a critical guardrail compete on equal footing with cosmetic polish and then being surprised when neither ships. Be explicit, in the post-mortem itself, about which follow-ups are which — the few that must happen and the many that should.

Track them where work actually happens, and close the loop out loud

Follow-ups die in isolation. A list living only inside a post-mortem document is a list nobody will look at again, because nobody's daily workflow runs through old incident write-ups. The fix is to put follow-ups where the team already does its work — in the same issue tracker, the same sprint planning, the same backlog the team grooms every week — while keeping them linked back to the incident that justified them. That link is what preserves the why: six weeks later, when someone is deciding whether this ticket is worth doing, the answer is one click away in the form of a real outage with real impact. A follow-up you can trace to a customer-facing incident is far harder to silently deprioritize than an anonymous ticket of unknown origin.

Then close the loop, visibly. Review open incident follow-ups on a regular cadence — in a reliability review, a team sync, wherever decisions get made — and ask the uncomfortable question out loud: are the important ones moving, or are they aging quietly? An aging critical follow-up is itself a signal, often a more honest one than the incident that spawned it: it says the organization agreed something mattered and then declined to fund it. Surfacing that gap is not nagging; it is the only thing that keeps the whole post-incident process from becoming theater. The measure of a learning culture is not how good its post-mortems read. It is the percentage of follow-ups that actually ship before the next incident makes the case for them all over again — and the teams that win at reliability are, almost without exception, the ones who treat that number as something worth watching.