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.”
Then I realised that "I don't want the details" wasn't being dismissive. The executive assumed that we were competent, and was saying "I already believe you. Now let's talk about what happens next".
Something about this feels wrong:
- If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.
- If you don't trust them completely, how can you know if "what happens next" is appropriate without knowing the details?
Isn't this just reinforcing the idea that leadership doesn't need to have their feet on the ground?
The best leaders I've worked with were paying attention to things from the bottom-up as well as top-down.
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."
The best leaders I've worked with were paying attention to things from the bottom-up as well as top-down.
If I have a handle on things from bottom-up to top-down, I don't need them to rehash weed-level technical and specific details. I need them to tell me what we're going to change, and it needs to be a BIG systemic change, not minutiae, which is where many engineers thrive.
If I have a handle on things from bottom-up to top-down, I don't need them to rehash weed-level technical and specific details.
I should have been clearer.
When I said that good leaders pay attention to things from the bottom-up, that doesn't mean they always know everything needed for any discussion. It just means they are able and keen to understand the low-level details when they matter, because they routinely look at such details in the projects that they're involved in.
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 need them to tell me what we're going to change, and it needs to be a BIG systemic change, not minutiae, which is where many engineers thrive.
How can one know if the engineers' proposed "BIG systemic change" is appropriate and complete, without knowing the details of the problem it is addressing?
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 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."
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".
You can trust someone to know the details and reasons for why something happened, and still want to provide the specific direction of "what are you doing to make sure it doesn't happen again". The organizational default is often to explain a fault (or worse, focus on blame) without specifically working to find a process improvement to prevent it from happening again.
If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.
The best leaders I've worked with were paying attention to things from the bottom-up as well as top-down.
These two statements are at odds. You're assuming that lack of trust would be the only reason he needs to know what happens next, then go on to outline exactly why he and the larger organization would both benefit from knowing more.
The important part is the action items are assigned an owner and executed.
I’ve done plenty of postmortems and many meetings where we go through the motions but “leadership” does not assign and address follow-ups. Most organizations pay lip service to reliability.
I would not have said that. I would have asked for the details and tried to find gaps because, almost always, something could have been done. Then the question is how much risk reduction are you willing to pay for.
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.
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?
What if you work at an organisation that doesn't ask "How do we prevent this from happening again?"
That feels like a tough place to work. I would worry about burnout and churning employees if I didn't work at a place that tried to improve every day.
Maybe I'm a bit of a pollyana, but most places I worked had folks who cared and wanted to improve things.
A Senior Vice President of ENGINEERING doesn't want the technical details?
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.”
Something about this feels wrong:
- If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.
- If you don't trust them completely, how can you know if "what happens next" is appropriate without knowing the details?
Isn't this just reinforcing the idea that leadership doesn't need to have their feet on the ground?
The best leaders I've worked with were paying attention to things from the bottom-up as well as top-down.
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."
If I have a handle on things from bottom-up to top-down, I don't need them to rehash weed-level technical and specific details. I need them to tell me what we're going to change, and it needs to be a BIG systemic change, not minutiae, which is where many engineers thrive.
I should have been clearer.
When I said that good leaders pay attention to things from the bottom-up, that doesn't mean they always know everything needed for any discussion. It just means they are able and keen to understand the low-level details when they matter, because they routinely look at such details in the projects that they're involved in.
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.
How can one know if the engineers' proposed "BIG systemic change" is appropriate and complete, without knowing the details of the problem it is addressing?
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.
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 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."
He wants to direct/align on strategy, not tactics. I'd say that's a good division of responsibility so I'm not sure I see your objection.
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".
You can trust someone to know the details and reasons for why something happened, and still want to provide the specific direction of "what are you doing to make sure it doesn't happen again". The organizational default is often to explain a fault (or worse, focus on blame) without specifically working to find a process improvement to prevent it from happening again.
You answered your own question.
These two statements are at odds. You're assuming that lack of trust would be the only reason he needs to know what happens next, then go on to outline exactly why he and the larger organization would both benefit from knowing more.
This article may be more appropriate for LinkedIn.
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.
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.
Do the actionable items usually get implemented?
The important part is the action items are assigned an owner and executed.
I’ve done plenty of postmortems and many meetings where we go through the motions but “leadership” does not assign and address follow-ups. Most organizations pay lip service to reliability.
I would not have said that. I would have asked for the details and tried to find gaps because, almost always, something could have been done. Then the question is how much risk reduction are you willing to pay for.
Isn't that the same with just more steps? Seems the svp was focusing on what they will do differently next time
Why are these SVPs even needed anymore? They seem to do nothing of value.
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.
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.