I recently read a post from Lorin Hochstein(@norootcause) that got me thinking a bit about my own stance on naming names in learning review. I currently leverage learning reviews, or as other may know them incident writeups, and some case post mortems (don’t use this), as a time for someone or a group to reflect on a timeline and then make observations about an event (positive or negative). This is similar to the reference that Lorin points to from Alex Hidalgo(@ahidalgosre):

While Lorin prefers to name names in a writeup I would respectfully disagree. While I would love to normalize the fact that incidents are just aspects of a system, especially a complex one, I do not feel that most folks have the luxury of a mature enough organization that they can follow this path just yet. I applaud Lorin for pushing this agenda and hope that as an industry we all arrive at that place I think we are not there just yet. I also believe that even if names are more anonymous you would still get the folks that would read this over and say something like “This could have been me!”.

In my opinion learning reviews/incident writeups are paramount to learning and growing the organization, specifically the engineering side. When we conduct them we stress as much as we can that there is no blaming or shaming but there is accountability. So while we don’t need to say Ramon from systems typo’ed the branch he was pushing to, we would identify that changes from the system team were mistakenly pushed out, or something to that effect. While it is not incorrect to include Ramon’s name, I just don’t see the value in it, at least from my experience.

Even though I don’t subscribe to this particular school of thought (at least not at the moment I am writing this) I do hope that we will all eventually end up in a state where there is no concern with regard to naming names and the second victim phenomenon. Finally, remember to plan for failure rather than avoid it :).