There's a reason 5 Why's Analysis is a thing. If you just say "here's a bunch of stuff we're changing," but you haven't said enough about the root cause, then no one will understand whether we're doing enough (or too much; or the wrong things). I like the framing of being empathetic - everyone is smart, doing the best they can with their knowledge and experience at the time - but sometimes we didn't do all the right things, and getting feedback from more senior engineers helps drive that improvement.

So in summary, instead of details propose how to change the system so that instead of hearing perfectly reasonable details about why the current system failed, go straight for changing the systems to prevent the chance of failure again.

I like this plan of action, it removes focus from what happened in the past to how can we prevent it from happening in the future.

What if you work at an organisation that doesn't ask "How do we prevent this from happening again?"

I've never seen an incident report or postmortem that didn't include action items to cover the core issue noted in this writing: "can we / how do we prevent this failure mode from recurring?"

I'm not saying these moments of discovery / epiphany aren't valuable, they are and this retelling is enjoyably written.

I am saying that action items borne of incidents should be de rigueur.

Interesting. At our org we always do both. Root cause, what are we changing. I assumed that was standard practice.

If you just explain what happened and why, that's fine but...how are you going to make sure it doesn't happen again?

The problem I found more vexing as a manager was: how can you prevent this KIND of problem from occurring?

I'd have someone on my team make a technical error and xyz wouldn't work. Wed talk thru it, and they wouldn't make that exact mistake again. But there's literally 10k things that can go wrong in our system, so then a related mistake would happen later.

What they needed was improved pattern recognition vs if this / then that which comes from post mortems.

This reads like a LinkedIn post. I know kagi translate[1] supports "LinkedIn" language - could someone with an account there copy that article and translate from "LinkedIn" to "English"? I wonder if we'd uncover some simpler meaning this way.

Edit: I was wrong. It still reads like LinkedIn to me but “translating” doesn’t help. Thanks in any case.

[1]: https://translate.kagi.com/

This is similar to the approach in healthcare, at least my experience in pharmacy.

When an error occurs we find the root cause but in 99% of cases a change to the environment/process is required to avoid it in the future.

Humans are all imperfect, their competence will change hour to hour let alone day to day. But you can control a system and put checks in place (admittedly a human can still do the process wrong, but then you need to think how the process can be clearer).

No-blame culture is very effective at providing an open environment to share mistakes, learn, but most importantly avoid reoccurance.

SVP sounds like a dingle to me. Author is justifying it with some magical thinking, "Oh he's not being rude, he's being smart"

If I recall correctly, in The Pragmatic Engineer, this was described simply as "provide options, not excuses" and is a critical way of building credibility.

What can be done, when writing an article, to not stumble during reading when an unknown abbreviation such as SVP occurs?