Skip to main content

Post Mortem as a Service

warning

Work in progress - coming soon. Have a project you would rather not repeat? Write to sandor@aerelontech.hu.

The project overran. The release hurt. The incident is closed but nothing about it feels resolved. Everyone in the room knows something — and nobody is going to say it to the person who signs off their promotion.

That is the structural problem with an internal post mortem: the people best placed to explain what happened are the people with the most to lose by explaining it. So the write-up lands on "communication could have been better", and the same thing happens again next quarter.

What this engagement is​

An outsider runs the post mortem instead. Someone with no stake in your performance review, no history with your vendors, and fifteen years of watching the same handful of failure modes across 20+ projects in 8+ countries.

Aviation has done this for decades, and it is a large part of why flying is safe: the investigation is separated from the chain of command, and the finding belongs to the system, not to a person. That is the model here — the same thinking behind the Crew Resource Management course.

What you get out of it​

  • A factual timeline. What happened, when, and what was known at each point — reconstructed from artefacts, not from memory and reputation.
  • Findings that name systems, not people. Every finding points at a decision process, an incentive, a missing feedback loop or a structural constraint.
  • The things nobody would say to you. Interviews are confidential, and findings are aggregated so they cannot be traced back to a source. This is the part you cannot buy from inside.
  • A short list of changes worth making. Ordered by how much of the failure each one actually removes, not by how easy it is to agree to.
  • A read-out for leadership. One session for the team, one for the executives, deliberately with different framing and the same facts.

What this is not​

Not an audit. Not evidence for a dismissal. Not a document that assigns fault to a named individual — if that is what you need, this is the wrong engagement and we will say so at intake.

Who this is for​

  • Leaders who inherited a mess and need to know what they inherited.
  • Teams who just survived something and want the lesson to outlive the people who learned it.
  • Boards and investors after a delivery failure, before deciding what to change.

How it runs​

  1. Intake — scope, what happened at a high level, and who may be interviewed.
  2. Artefacts — tickets, commits, incident logs, decision records, chat history where you are willing to share it.
  3. Interviews — confidential, individually, across levels. The engineer and the sponsor both get a full hour.
  4. Synthesis — timeline, findings, and the change list.
  5. Read-outs — team session and leadership session, plus a written report you own outright.