Starting a Tech Business: A Practical Guide for Anyone Creating or Designing Applications or Software

Post-Mortems

The objective of post-mortems is to avoid repeating the same mistakes and, more generally, consider how to do things better. Don't push too hard for perfection on these exercises. The most important thing is to do them and exit with specific recommendations for next time. The post-mortem should conclude with a basic write up that has at least the following elements:

a. Description of what's considered

b. What went well

a. Why?

c. What went badly

a. Why?

d. Specific recommendations

Table 8.4 is an example of such a recommendation.

Table 8.4

Over the course of the post-mortem, you will want to involve as many of the relevant parties as possible and dig as deeply as possible. The goal is to look as far inward as possible at the root causes of why things happened. For example, let's say someone tripped over a cable, unplugged a server, and caused an outage of the service. You're not looking to understand why someone was clumsy and tripped. You're looking to understand whether the server room is a mess and it's easy to trip on things, why there wasn't more redundancy in place, and how quickly the organization was able to detect and fix the issue.

Some organizations find that getting everyone together works well. Some find that smaller discussions work well. The important thing is to avoid having the exercise devolve into a blame game. Post-mortems should be ...