> 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.
> 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?
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.
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.
FartyMcFarter · · focus · HN ↗
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.
0manrho · · focus · HN ↗
> 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.
saghm · · focus · HN ↗
But doesn't that same logic apply to whether they need to know the details?
tomnipotent · · focus · HN ↗
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.
saghm · · focus · HN ↗
NhanH · · focus · HN ↗
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.
mpyne · · focus · HN ↗
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.
waynesonfire · · focus · HN ↗
saghm · · focus · HN ↗
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.
[deleted] · · focus · HN ↗
[deleted]