most places I worked had folks who cared and wanted to improve things

Where are these places? It feels like they are hard to come by, and their hiring requirements can be highly competitive

Organizations don’t choose whether or not to ask questions. People do. The behavior of an organization is the sum of the actions of the people in it. If you are a member of an organization, and you ask ‘how do we prevent this from happening again?’ Guess what? The organization just learned how to ask that question.

Now it just needs to learn how to answer it, and act on the answer.. but step one seems solvable.

If the person who is charged with resolving the issue is capable, there's no point in a senior manager knowing the details outside of professional curiosity.

The quote box at the start of the article is the essence of it, the rest is AI-speak dressing it up.

TLDR:

Some outage causes a meeting with an SVP. SVP preempts the discussion with the following:

“I know that if we get into the details, the reasons will be perfectly reasonable. You'll explain what happened, I'll understand why everyone made the decisions they made, and I'll empathise with you.

Then it'll happen again.

So I don't want the details. I want to know what we're changing.”

Leadership still holds engineers accountable. And for that, they need to know the plan. Leaders are also held accountable, so again, they need to know the plan.

Not wanting to know the details is a red flag. Sometimes the process of expressing the details can reveal things that were unknown by one or both parties, leading to improved processes. The only acceptable exception would be "Let me explain. No, there is too much. Let me sum up."

Of course it's possible that this story is just told badly and the SVP already knew the technical details, in which case the blog post is a bit misleading.

I don't think it's necessarily misleading; it's just reminding folks that senior leaders have a different perspective than those below them and tailoring your message to the audience is important.

In this case of this, it was a reminder that while it's easy to believe the SVP is being dismissive, that's not the case at all. Instead, they want systems-oriented decisioning, not detail-oriented.

If anything, this was the SVP helping to grow the leaders under him by forcing them to think at the levels required to interact w/the rest of the organization.

How can you know if their "big change" is appropriate and good without knowing the details of the problem the change is addressing?

I'm a Senior Director leading three teams of engineering and science resources. I hired smart and capable people. Why should I, as a SrD be a technical bottleneck?

I think you have a distrust of your leaders and are taking this from a very different place the author of the article was.

I don't read the article this way. It's pretty sane for an exec to draw a line where the team's autonomy meets leadership's responsibility for structure and incentives around which said team needs to organize.

"You did the right things and met the goals we set, but we hit a problem and we all agree it shouldn't happen again. Let's talk about what needs to change to address this."

What I got from parent comment, and I agree, is:

If I trust you know what happened, and trust you to know what to do so it doesn’t happen again, why do I need to know? And how will I know (and endorse) your decision if I don’t know what happened?

It seems weird.

Also, not every IC or EM has the same skills and experience. There may be certain categories of work that you can be 100% hands-off and trust them to just do it, and others where you really need to understand bottom-up. Part of being an eng leader is to know when to insert yourself and when to "trust the process".

The SVP doesn’t plan on making any decisions here.

It's about knowing what your team is up to so you can provide them the resources necessary while also working to remove any obstacles in their way so they can get shit done.

That makes sense - I don't know if that's what the blog post was implying though. Ironically, this blog post could probably benefit from a few more details about what the meeting was supposed to achieve :)

In a large enough organization it is simply impossible for executives to be on the ground floor with everyone else. And not only is it impossible, it is essentially a waste of their time. They could maybe be maximally involved in only a few projects at a time.

I think its entirely contextual as to what the size of the org is and the scope of the projects. At a startup an "executive" or VP would legitimately be able to be working side by side with everyone else, or hearing about the ground level operations, but just by nature of the role being SVP I imagine this is a large enough company that this is no longer the case. At a certain point that becomes somebody else's job that is much closer to the team at hand.

The role entirely morphs and their job becomes to enable teams, get blockers out of the way, fast track or assist things like permissions/processes, shoot down ideas that legitimately don't add business value or are not worth wasting existing engineering effort on.

And I imagine in this scenario the point wasn't for the executive to literally hear what happens next, it was to ensure the proper steps are being taken and make sure "somebody" is handling the what happens next part of things, and so they can report up through the chain or delegate tasks for exactly that "what happens next" task.

They trust your ability to do a root cause analysis. They don’t trust that you feel empowered to do anything about it, so they are verifying that you actually do.

Haha ouch.

Give AI vibes, so agree.

Good article write-up, I didn't need to read more than one paragraph to get all the information from the whole page.

Do the actionable items usually get implemented?

I agree. Finding the time to update docs, processes and code based on a post-mortem is, from my experience, the hardest part. Critical, but difficult.

The team can present the options but the executive may need to make a judgement call, and he can't do that responsibly if turns his brain off. Maybe he needs to change the process, or re-allocate resources; things outside the ICs' purview.

Engineers are like smart, mischievous cats. We aren’t self-organizing like a lot of us seem to fancy ourselves as being.

My father who was also involved in IT tells a similar story where the executive cut him off and said "I asked you for the baby, not the labor pains."

Thats funny. When I try to only give the conclusion, I'm often asked for the details.

We call this incident postmortem, part of a company process. After serious problems and firefighting, when the patches and hacks and people working 24 hour and it admins wake on a Sunday morning to do work, we sit down and try to figure out how this will _never_ happen again.

Learned this doing incident reviews. If the exec asks for details it usually means they don't believe you yet, so "skip to what changes" is actually the good outcome.

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.

Love this idea; won't go over well at all with the other accountants I work with. MY CFO doesn't like graphs because they "hide too many details' and insists on everything presented to her being in a table. MY VP pulls out a calculator and re-does the math on tables in decks by hand to help him 'understand'.

A lot of leaders like to hide in the details because the bigger picture is a harder problem.

If you don’t know what happened how would you be able to tell if the changes are addressing the problem? If you don’t care about the problem being addressed why jump in a call in the first place?

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.

...I'll empathise with you. Then it'll happen again.

I'm not so sure this means "I trust you."

This is a really really smart SVP. The answer to “how do we prevent this in the future” is to identify decisions that reduce that problem from happening again. This doesn’t have to be perfect. You can say “we are going to do X next time” and also say “but we don’t know how far X will work”. When the failure happens again, you can retire process X and move on to Y. The aim is to make a series of decisions that eventually get to the heart of the issue.

Everything else is a conversation that takes up space on a post-mortem or runbook.

An SVP of engineering should care about the details, this is the essence of leadership. When you don’t care about the details you are just a manager and worthless i.e. you should be replaced with a leader.

One thing that's often left out that tends to grind organizations to a halt is that continuous improvement processes tend to be additive.

You always add rules, and alerts, and so on. You need to revisit existing processes to and see what can be removed or replaced.

My other nit with these is a term that's abused a lot "Root Cause", most complex issues have many contributing factors, not a single root cause, and if you force the teams to find one, they will.

I dislike RCA (Root Cause Analysis) it puts you in the wrong mindset, CFA would be better (Contributing Factor Analysis).

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.

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.