> 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.

Getting that to happen more automatically is one way out of this situation, but that tends to cause problems of its own, with blurry lines of responsibility and authority. So it works best with relatively flat organization structures, which aren’t used much in large organizations.

You will have to trust someone will figure out the details and come up with a reasonable solution. Sometimes you need to know that solution, sometimes in detail, sometimes just enough to know that they solved it. Sometimes you are the person who needs to figure out the details and make the solution. Knowing which you are is important.

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.

Quoting myself here: Amazon is heterogeneous. So much so, that positive anecdotes and negative anecdotes are near worthless without specifying the org. I don't want to name bad orgs but what org are you talking about?

As I've gotten older, I've grown to appreciate people who are willing to be a little rude in order to avoid wasting people's time or giving them false impressions.

For example, when recruiters reach out to me on LinkedIn now, I almost always say something like "I don't want to waste your time or mine: what is the salary range?" It might be considered a bit "rude" to immediately jump to money, but I figure that that's less rude than wasting 30-90 minutes of time for a job that I have no chance of accepting.

I also try and be a little upfront if I don't like food someone has prepared. I try not to be too much of a dick, but if someone prepared something that I don't like and they ask my opinion, I will say that I wasn't a huge fan. Again, maybe a bit rude, but I also don't want to mislead people.

It kind of goes against my gut; I, like most people, don't really want to make people feel bad and I certainly am not immune to people-pleasing, but I've tried to fight that for the greater cause of being more-honest and upfront with how I speak.

If you want to reduce incidents, you need to lean into the problems instead of dismissing them or delegating even more all over again. Doubling down on trying to keep your hands clean is shit leadership.

The basis of this blog post is delusional. The language from the SVP is the desire to fast-forward past the thought process that comes with listening to "the story". This could only lead to more problems. They're basically admitting they weren't going to listen in the first place. "The story" doesn't always lead to blame game, and sometimes the changes needed are the context in which rational and trustworthy people are working in. That is not a change to the system, but to the organization.

It’s like when cloudflare does a blog post saying they were out for three days and it was because they let someone slopcode the DNS. How has that achieved anything? It will go down again the following week. The customers want to know how you will prevent it happening again, they don’t really care how entertaining your blog is.

Otherwise, what will be the discussion when it's time to question it later?

This should not be exclusive.

Maybe if the changes you're doing are small and cheap, sure. But if they are invasive and costly...

Because the author wanted to write another "thought leadership" article with a clickbait headline that would make it to the HN frontpage (and maybe even featured in the TLDR Newsletter). It worked.