> 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.
> 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 :)
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.
> 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.
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.
FartyMcFarter · · focus · HN ↗
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 :)
hirako2000 · · focus · HN ↗
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.
milesvp · · focus · HN ↗
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.