How to Own a Work Mistake and Lead a Useful Postmortem

When a project fails, saying "that was my fault" is a start. A useful postmortem also explains what happened, what part you owned, and what should change.

Six months into my time at Amazon, I led a vendor project to automate a manual data process. It cost $20,000. The system failed in testing, and a fix would cost more. I had not asked enough questions about whether the requirements would work, and I had not set a checkpoint to test that assumption.

Write before the meeting

That night, I wrote a six-page account of what happened, the cause I thought I had found, the cost of a fix, and what I would change. The next morning, I read it with my manager, his manager, and a peer.

Writing first forced me to be specific. The document gave other people something to question. You do not need Amazon's format. Before a postmortem, write a short narrative that covers what happened, the impact, the decisions or assumptions that contributed, and what you would change. Use complete sentences.

Look for your part in the system

The vendor made a poor choice by continuing to build something they believed would not work. I addressed that separately. My mistake was assuming they would challenge my requirements and failing to create a checkpoint where we tested the design.

A root cause should not become a hunt for one person to blame. Ask what decisions, incentives, or missing checks allowed the failure to continue. Then be direct about the choices you controlled. That does not mean taking responsibility for everything others did.

Make the follow-up real

Name the change, who owns it, and when you will check whether it worked. In my case, I needed to test assumptions earlier and add a review point before more money went into the build.

My manager's manager told me I had taken responsibility, identified the issue, and brought a plan. What stayed with me was that an honest diagnosis gave us something to fix.

When your next project goes wrong, write down what happened before you enter the room. Be specific about your decisions, invite people to question your explanation, and leave with one change the team can verify.