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.

Asking what the OP was going to change is not an automatic nod of approval for his approach. I’ve been part of some large interventions spanning multiple quarters, that started from a simple conversation with an exec just like this. There are downstream effects to these decisions that affect many stakeholders and departments - so they cannot be made in a vacuum or delegated completely (I trust you, go ahead and fix whatever). Depends on the severity and scope of the issue of course. A simple deployment gone wrong is different from a fundamental issue with the architecture that is straining progress.

As an example, a major rehaul of a core system could push back product (new feature dev) timelines, that can affect customers and their releases, bottomline of the company, reputation, tax repercussions, if it’s an American public company then it’ll affect SOX compliance & audits, could lead to spicy investor/analyst conference calls, and so on.

I think that's overthinking it.

First of all, he didn't say the executive "trusted them completely". Those are your words.

He said "The executive assumed that we were competent, and was saying "I already believe you. Now let's talk about what happens next".".

That can be true even if they don't trust them completely. Let's say he trusted them 80% and not 100%. Isn't that pretty much quite trusting anyway?

Besides, the executive can trust them even 100%, but still want them to give him the general picture. Among other things, it's his job to know and be able to report when asked.

A lot of times, people just need a gentle nudge, or an official blessing from an authority figure, to go ahead and make the change that is necessary. You can tell people to manage up, to fully own their work and their process, etc. But a lot of humans don’t want to step on others’ toes or be perceived as acting out of line. A worker on the assembly line might know the best way to make the line run more smoothly but it’s easy to think that’s “not my job” or “above my pay grade”. Sometimes all that’s needed is to tell them, “Yeah, go ahead and do it.”

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.

The best leaders know what they need to pay attention to. You cannot know everything. You can know any one thing (or perhaps several), but there are more things to know than you will have time to learn in your lifetime. The question is what is important for you to know, and what you leave to somebody else.

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.

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.

“Trust” is usually bounded. I trust my elementary aged son to get dressed for school without supervision. That doesn’t mean I trust him to start a campfire without supervision. A chef might trust that their new employee is a hard worker and well intentioned. That doesn’t mean they also trust them to create and serve original dishes.

Here you are recasting “I trust that, despite the bad outcome, everyone’s actions here were reasonable” as “I trust that you are going to solve this fully without my guidance”. The fact that the word “trust” appears in both of these statements does not make them equivalent. Trusting that people are capable and well intentioned does not mean trusting that they will accomplish the same thing without you.

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

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.

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

You might need to know timescales so that you can inform upwards/outwards/other. You might need to make sure other resources that might be necessary are available. The planned "what next" and the proposed timescales might have impacts elsewhere that they haven't realised (and maybe even until now had no reason to be aware of). If they tell you the what next and there are no such complications, then they can carry on, otherwise there might need to be some changes to the plan or changes to other plans to allow time/resources to be available for this plan or just to stop potential near future conflicts.

Trust, but verify. And perhaps even assist.

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.

One reason is prioritization. It’s enough to know what the effects of the failure were, the likely cost of what needs to change, and what areas and processes the changes will affect, to decide if and when this should happen.

Leadership still needs to understand these aspects on a conceptual, topical, and cost level to decide on the resource allocation (including time and schedule). They don’t need to understand the technical details, unless they are a technical leader with higher relevant technical competence than their reports.

Trust them completely != "assumed that we were competent"

I've worked with plenty of competent people. Only a few were so good I trusted them completely.

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.

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

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 devs job is to impliment and advise how to attain the owners goals and priorities, not to set goals or priorities except at layers below, and in the service of, the c suite's directives.

I'm not saying c suite are unquestionable gods, I'm saying that there is no such trust-or-not dichotomy. It's 2 different things.

No matter how ignorant I am in some domain and no matter how knowlegeable some expert is I hire to do something for me in that domain, they can only tell me how to get what I want, or what's the closest that is humanly possible, or the costs of various conflicting priorities and compromises. They can't tell me what to want.

Maybe I DO actually want to burn my whole budget and 5 years of time on some facet that they and most people would say is not important and not worth it to the point of being irrational. Their job is to inform me not to decide for me. I can trust them to inform me honestly and with good judgment and deep knowledge, and then to impliment what I decide also honestly and with competent skill. And yet I still need to be the one who is informed, and then makes a decision and issues a directive.

It's 2 different things.

It's like Steve Jobs being totally unreasonable about tiny details of fit & finish in the hardware products. It makes no sense (to most people) to have custom ethernet jacks manufactured (back when it wasn't so effortless and flexible) just to get them a certain color or material feel, when off the shelf jacks already exist from multiple sources that work just fine for a 10th or 100th the cost, while already meeting a stack of compatibility standards and even safety regulations. No trustworthy engineer would do that. They would actually see it as violating that trust.

It gives LinkedIn post vibes

That's all context management to all the way up

The SVP has to explain what they’re doing to prevent reoccurance again to investors, customers, ceo who don’t care about the widget on x k8s

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

I work in a competent team and leadership is required.

Yup, several things are wrong with it even though it may be a good idea as a good shortcut on the part of the SVP

But it should be used and phrased better.

Used better:trust and only sometimes ask for the detials, like cutting the just-shuffled deck in a card game, sometimes the player to the dealer's right will just tap the deck instead of cutting it, in effect saying "I trust that shuffle". Sometimes, certainly enough to both keep the SVP well-grounded in the details, and to keep the team knowing the SVP is both watching and cares about the details, the SVP MUST ask for the details. Trust and verify.

In terms of phrasing, "I don't want the details" is all about the SVP sending the message s/he doesn't want to be bothered. The phrasing should be: "I trust you on the details on this one; let's go straight to what do we do to manage the next one of these?".

Notice leading with "I trust you on this", not "don't waste my time".

I would agree with you, this just sets up a scenario where the SVP positions themselves as a leader, without having to understand something technical, and without making the decisions on how to change things. It isnt about trust, it is about performing accountability so the SVP can say they did their job.

I think the author of the article is going out of their way to be charitable to the SVP for no reason. That meeting was a reassertion of power, not a wise move made by a sage.