The trouble with post-mortems is always the things that you can't say.
Are we going to talk about how someone wanted analytics everywhere even though it's expensive and they don't use it, that they chose the vendor and didn't provide time to evaluate it, that they wanted it added now-now-now to production even though it hadn't gone through dev, even though it was unplanned work in a busy sprint with other risky work, and that they wanted it on the critical path despite specific objections from some in engineering?
Not saying any of this was the case here, but this kind of thing happens frequently. While engineering is saying "let's use blameless post-mortems to highlight problems in the system" a lot of other people are thinking "now we get to see who could or couldn't fix a problem we caused, focus on that, and downplay our own role in causing trouble". Devs talking about CDNs and HTTP-POST and engineering processes are super helpful for steering the conversation away from broken business processes.
Easily 80% of PMs I've been involved in probably come down to "we had rules for moving tested code through dev/qa/prod, but we were forced to ignore the process we had agreed to because $PERSON / $DEPARTMENT said so". No one can actually talk about the elephant in the room though, because it's career suicide after you're branded as not a team-player. For all the kids out there.. it's really important to learn to be able to recognize the difference between a PM that's going to be an earnest effort to understand things, vs a PM that is going to be an unhelpful but necessary ritual of humiliation.
Good post-mortems should provide ammo and action items to review existing business processes. If you don't have an advocate in your engineering organization who is working across departments to improve these processes, that may be a sign of organizational immaturity or dysfunction. No organizational function happens in a vacuum, and in the right company, collaboration can help influence the things that engineering doesn't directly control.
Let’s not pretend it’s just PMs. I’ve worked with PMs who fought against shipping fast but ultimately an engineering manager or engineer comes in and forces a fast ship.
It includes:
* Blaming the tools (and the author)
* Not focusing on facts in the timeline
* Not considering improvements
But that doesn't make for engaging content, right?
> * At $TIME we observed HTTP POST calls failing
> * At $TIME customers reported inability to make changes to ticket prices and promo codes
> * $PERSON took the following steps to debug...
> * Root cause: an update to a vendor library resulted in cascading failures to the site
> * 5 whys (which might include lack of defensive programming, the use of a CDN without a fixed version, etc. etc.)
> * Next steps: pin the CDN version or pull the dependency into the build, etc.
Actually, that still looks like a pretty good story to me without any of the associated mania.