Hacker News Reader

Comment by tomnipotent | Hacker News Reader

> whether they need to know the details

No. Leaderships job in this context is to set expectations of what happens next and to drive the team towards a solution that meets those expectations. No amount of trust magically makes that expectation materialize or for it to be met.

Leadership doesn't need to know what happened to set this expectation and then trust their team - who already know the details - to figure out how to meet what's expected.

Perhaps my favorite quote ever about leadership is that it's about holding a vision long enough for others to realize it for themselves, but you can't do that if you dictate and micromanage.

View on HN

So if I'm understanding you correctly, you're saying there's literally no reason for a leader to need to know the details ever unless they don't trust the people implementing the plan. I don't agree with that at all.

Leaders should not need to know every single detail (ie how this incident happens, or all the tiny process changes that are happening toward their visions). That is different than knowing nothing in detailed.

The baseline expectation in the original post also applies to the SVP: he knew enough to know that things aren't unreasonable to start with, this expectation might not apply to all companies.

An analogy that might make more sense is horizontal scalability vs. vertical scalability. A leader's ability to understand all the details of the proposal brought to them by the team inherently caps the organization's ability to scale up.

Offloading the detail onto the team allows the org to scale higher by allowing the leader to bring more teams/problems into the mix. But it also introduces the complexity of keeping those teams in close enough alignment that the overall effect is still positive.

This is by no means guaranteed to be positive, and there's a lot of details to get right for leadership in making this work. But they are different details than what each individual team was bringing to leadership.

Abstractions are helpful, in business management as much as in systems architecture.

You, and this entire thread is missing the point. Nobody is wrong but, the point being missed is that "leaders" isn't one thing.. there are leaders at every height of the organizations hierarchy and even to the sides. As a basic example, do you mean the immediate manager? their manager? their manager? The CTO? Each operates at ever more abstract level of detail.

The top-level comment that started this discussion was mentioning that a "leader" said "I don't need to know the details" but that they wanted to know what comes next. The comment I responded to claimed that there are valid reasons to need to know what comes next that don't stem from a lack of trust. I asked whether the same logic should apply to wanting to know the details (since to me it seems pretty reasonable that it should). The response said "no".

It seems like you're trying to rebut my argument by presenting my argument as being against a less strong version of the original claim rather than understanding it as being literally just a counterargument to the specific version of the claim I thought was too strong.

That is not at all what was said.

Leaders have the option of trusting subordinates, then operating at a higher level. However part of the job of a leader is to decide who to trust, with what. And why.

Sometimes that means, "Trust, but verify." The leader will spot check randomly to see that the whole is good.

Often, as here, that means, "Trust in some things, but not others." The leader in this case trusted the technical person to produce an accurate description of what happened. But didn't trust that same person to arrive at a solution that met the business of having a similar disaster not happen the next time.

But rather than undermine the tech person with, "I don't trust you to meet the business need," the leader communicated it with, "I trust you on the technical details, but here is the expectation for what you need to produce."

The statement I initially responded to was "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". I pointed out that the same logic seems like it would apply to the idea that there might be other reasons why a leader might need to know the details. They said "no", and then a bunch of other stuff that you seem to think that I'm not reading. I'm reading it, and I'm reading what you said to add onto their comment, I just don't understand how you can claim their answer of "no" to my question doesn't mean "no" to the restatement of my question.

Now that's a textbook strawman

It's literally the question I presented in the comment they responded to with the answer "no".

What do you think knowing the details will do for the person in the leadership position? It doesn't change what needs to be done, it doesn't change what has been done, all it usually does it put a monkey on the leaders back that's best kept with the team that created it.

Worse it invites bike shedding most of the time, where folks sit in a room nitpicking pointless details that's cathartic for the people in charge, but once again, doesn't actually do anything productive.

Reply on news.ycombinator.com