You answered your own question.
> 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 first assuming that lack of trust would be the only reason he needs to know what happens next, then go on to outline another reason he and the larger organization would both benefit from knowing more.
It's not just about trust. 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's what good management does, it's just rare to see in low-trust organizations that treat everyone like a cog to be micromanaged because no one trusts anyone to get shit done of their own accord for whatever reason.
> These two statements are at odds. You first assuming that lack of trust would be the only reason he needs to know what happens next, then go on to outline another reason he and the larger organization would both benefit from knowing more.
But doesn't that same logic apply to whether they need to know the details?
> 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 :)
> I believe you. I don’t need the details. Tell me what we're changing.
Yeah, for me in these situations it’s often about messaging to stakeholders, and so management in general feels like the problem has been addressed. I do think there’s one important thing missing from the final statement of the post, that he sort of covered briefly when talking about too much process, and that is what is the tradeoff/cost of implementing the change we’re making. Engineering is fundamentally about tradeoffs, and any significant proposed change requires some tradeoff and all too often I see management not asking about this explicitly. I’ve had enough once in a blue moon errors have retros, where the team decided it made no sense to make changes, and others, where the cost was high enough it was worth increasing workflow headaches. I think these tradeoffs being explicit are important at the director and above level, since there are potential real impacts to the team, and that is the level to deal with morale or headcount pressures due to changes to processes.
The meeting was about the SVP teaching the team that incidents happen, what's important is to prevent the same issue from occuring again.
The fact the author had never been in a call with the SVP implies incidents that happened before were explained in details, without much process change.
We are arguing because there is an IT maturity line that goes from chaos to corporate and the more like a startup the more it will be like chaos (by design because maturity is too restrictive). So horses for courses. But as the team grows the same lessons get learned everywhere you bring in ex-bigco to implement changes to be more mature. That will include incident management process that will make this situaton routine and not worth blogging about. Probably in a mature process leaders already read the summary and or postmortem if they felt they needed to.