It's likely just a wording thing, but what is talked as a retrospective here, we call a blameless postmortem at my current company. And we have an ever evolving template we use to share the timeline, root cause, learnings & action items.
The one thing I would add to the article is spend time to calculate the business impact of the incident and start the retrospective with this. This is something that might not be that straightforward for engineers to know and might need help from other people within the company to understand. How many customers were impacted and in what way? E.g. if you had an outage on your web site where people could not check out, how many orders did you lose and what was the total value? The answer will depend if people completed their order after the outage was over, if they could use e.g. the mobile app that time and so on. Pinpointing the business impact can help understand just how severe that specific outage was (and how that part of the system is connected with everything else).
Author here: We explicitly moved away from postmortem at Heroku and follow the same at Citus Data because postmortem has references essentially to something having died. The blameless part of a postmortem helps, but blaming something is separate from the idea of examining something that has been killed. There is a ton of value in emphasizing the blameless part though, so very noted.
The business impact is something that is important, and we often do measure. I often aimed to separate two somewhat as leading with that can create some unintended consequence of aiming to point blame/etc.
That is a very literal interpretation of post"mortem" to which I don't subscribe in this context. The Oxford Shorter English dictionary I have on this iPad also includes this definition: "An analysis or discussion conducted after the conclusion of a game, examination, or other event." (I won't get involved in a discussion of what a dictionary is or what its purpose is, sorry.)
I also like and use the term postmortem to mean what this author calls retrospectives, and use the term retrospective to mean a more general look back without being event-based.
The one thing I would add to the article is spend time to calculate the business impact of the incident and start the retrospective with this. This is something that might not be that straightforward for engineers to know and might need help from other people within the company to understand. How many customers were impacted and in what way? E.g. if you had an outage on your web site where people could not check out, how many orders did you lose and what was the total value? The answer will depend if people completed their order after the outage was over, if they could use e.g. the mobile app that time and so on. Pinpointing the business impact can help understand just how severe that specific outage was (and how that part of the system is connected with everything else).