I suspect the author still misunderstands the SVP. If I were the SVP of engineering saying this to someone, especially someone who is in a non-core engineering role like product, I probably recognize that they have a tendency to verbally spew and I want them to focus on the risk mitigation and response plan. I’ve already talked to my engineering leader because they informed me immediately, and I’ve already read the incident details.

But also the post reads like it comes from an inexperienced/immature service org, so maybe they’re just sorting their operational response process out.

"Okay, then I'm going to rewomble the dinglehop, which should un-galvatrate the percapitator." Why is the SVP in the meeting at all? If they don't want the details, they can't contribute to the change, or even evaluate whether the change makes sense at all. The SVP could be completely removed from this situation and the outcome would be exactly the same. Which shouldn't be surprising, since that's almost always true of all executives anywhere.

> Everyone nods their head, says "that makes sense", and we all move on with our day.

Why? Why do you need to be intimidated into actually making effective change? Why is everyone walking around with their hands tied, unable or afraid to enact change? Probably because of the terrible leadership at this company.

>> "We missed it because Alice was on holiday and Bob thought the Widgets team owned it".

> Okay. How do we make ownership unambiguous when someone is unavailable?

You cannot take this step without details. That Bob-Alice story is the details. You do actually need to know that story before you can take the step of knowing that "unambiguous ownership" would be a worthwhile change to make. What exactly is this SVP doing again?

This entire post could be summarized as "executives are useless" and "do the 5-whys", both of which everyone already knows.

This article may be more appropriate for LinkedIn.

The post-mortem process can cover all of these things:

  - what happened
  - impact
  - root causes
  - what will be changed (commitments)

You can't really talk about what to change w/o talking about root causes, and you can't talk about that without talking about what happened. You also can't consider the costs of commitments to be made w/o discussing actual and potential impact because resources are limited and the cost of opportunity is real.

It's fine for executives to get only a summary of impact + commitments. But the whole post-mortem process has to be followed, and some people have to be aware of all the details.

I can't help but notice that a climate of fear around being deemed non-essential or otherwise getting on an authority figure's bad side tends to create significant mismatches in priorities and breakdowns of trust that could be upstream of significant organizational inefficiency in a variety of situations. Perhaps solutions to meta-problems of this nature might be high-leverage, as the thought leaders like to say

The executive did not display empathy.

People need to tell their stories. They need to be heard and have their work and its difficulty respected.

That's what went wrong. Everything else is an abuse victim rationalizing their abuse.

Every post-mortem I've done had:

1. timeline of events

2. impact

3. 5 whys — the details of how and why things happend

4. actionable items

I've never seen a post-mortem without actionable items.

Some of the best life advice I learned during conscription as a squad leader: do not explain if an explanation is not asked for. If you (or, importantly, your subordinates!) mess something up and are confronted by a superior, the only correct reply is "Yes sir I screwed up sir I’m sorry sir it won’t happen again".

I think the problem is when the execs aren’t looking at change-for-the-better. Instead they’re looking to appoint blame. Moving to a position of assumed competency in your staff and taking the perspective of how-to-improve-next-time is a real step forward in maturity. My guess is it’s rare and blame is easier: most management doesn’t reach this level, instead it’s immature.

I think that's a problem domain in itself. Identify when failures that occur even when skilled people doing their jobs properly, adjust the environment so that they no longer happen.

It is understandably a completely different task compared to what those skilled people are specialised to do. You probably need a dedicated role to do it.

Perhaps you could call them a manager. Their job is to see the multiple parts of the system. They should ask for the Details of what happened so they can determine why the problem occurred.

Consider one of the problems listed in the article

>"The alert fired, but the on-call engineer had already dealt with twenty low-value alerts that evening".

The engineer can say they were busy, they didn't see the alert, that they are swamped with things they think are low-value. Someone else can say the alert fired. Each person involved may have their own perspective, with different ideas as to what the problem actually is.

It's easy when you see problem described in terms of what the solution is. Someone needs to figure that out, to do that they need the details.