Hacker News Reader

Comment by groby_b | Hacker News Reader

It's an issue of scaling.

Can I ask 5 people what their perspective is? Sure. 15? It's getting tough, but maybe. 50? Not really.

And so you delegate. Which means you get filtered information. Detecting which filters work well and which don't is tricky. It's not that managers "don't care", it's that they genuinely don't know and haven't figured out they don't know yet.

You can short-circuit that by telling them. Sure, getting the info is their job, but pushing it their way might get them the info faster. Just saying "but it's their job" is not helpful.

View on HN

> "Can I ask 5 people what their perspective is? Sure. 15? It's getting tough, but maybe. 50? Not really."

Don't make one person in charge of 50 people then (at least, not their direct line manager).

Management where your only option is delegation is not very effective, in my experience. You have to be able to choose when to delegate and when to step in. The only way that works is when the teams are small enough that a single individual knows enough about what's going on to know when to change their leadership approach.

Furthermore, of all the managers I've worked under, the most effective ones all have one thing in common... they're protective of their team. This protection only seems to work when a manager understands what their team is going through. Consider a scenario where a management meeting is taking place and a manager from another department is complaining about how long your team is taking to complete a task. If your manager doesn't understand what your team is going through, what's the best answer your manager can give? That they'll "look into it". That may sound reasonable, but it puts your team on the back foot from the start.

Effective team protection brings a few key benefits... it builds loyalty, it reduces stress on team members, it focuses energy on key tasks rather than trying to do everything all at once. Managers who don't protect their teams may as well not turn up. If they're just another voice adding to the cacophony of demands, then they could be doing more harm than good.

> Don't make one person in charge of 50 people then (at least, not their direct line manager).

Which is, literally, delegation. Yes, front-line managers should have some understanding of what their people go through, and have direct lines with all of them. But the article didn't refer to frontline managers only. In fact, the opening example was about a VP. (I'd argue that it's mostly not about frontline managers - the title is badly chosen)

But even when you're a frontline manager, "step in" is not really a good option. Unless your team is tiny, inserting yourself into actual execution means you just created a huge schedule hazard for your team.

For better or worse, as a manager, you work through others. Your direct impact is very limited - your main job is allowing others to have maximum impact. (Protecting your team falls under that rubric - shield people from administrative noise, so they can do their actual job)

And in the end it really is "their job." It may not be helpful but it's reality. It's why your job is hard and it's something you need to accept and deal with in a way that doesn't demean, marginalize and slow down the people you serve.

It is, if you look on externally.

If you are the employee wondering "why don't they act on this", that's still not a helpful take. Neither for you - nothing will change - nor for the manager, who might miss out on critical info.

Which is why good managers usually make sure that people are aware what the escalation paths are, and how to use them.

And why they keep hammering on the point that "not my job" is not helpful - because they (should) know that they operate on necessarily incomplete information, and that they make mistakes they're not aware of that are immediately obvious to people on the front lines.

The conundrum of management. It's your job, but you can't do it all by yourself.

> "Which is, literally, delegation."

Not quite. In the example given by GP, the idea was that understanding what 50 people were going through was not possible. However, it is possible for upper management to build an understanding of what people are going through if line managers are doing their job.

Imagine a company structure where you have 10 teams with direct line managers, where each of the line managers has 9 people in their team. Next, imagine that there are 3 senior managers who the 10 line managers report into. Lastly, there is one CEO that the 3 senior managers report into. In total, excluding the CEO, there are 103 employees. How does the CEO get to understand the operational challenges involving 103 employees? It's simple, the line managers summarise the challenges in their team, the senior managers prioritise which of the challenges to discuss with the CEO. Even if the CEO is hands off in the whole process, it's still possible to understand the difficulties being faced by 103 employees, as not all of those 103 employees will face difficulties that senior management need to get involved in, and when they do each of the managers involved in the communication between the team members and the CEO has an understanding of the details, so can answer questions that the CEO has. Therefore, a manager in charge of 50 or more people can understand the operational challenges faced by those people. From the article...

"For two years I worked on a project, and when it finally shipped, I can remember our VP talking about the launch. I had never had much exposure to him (I was new, a grad straight out of school), but I remember his speech about the launch clearly. He talked about some of the key features and mentioned a few of the people involved.

At the time, I had the impression he was out of touch; the people he recognized weren't the ones who had contributed the most code, and the features he called out were important but not the ones that had been the major engineering challenges. I can remember thinking, "How can he not know what is going on in his team?"."

Would you agree that it's possible for a VP to have better information (assuming the people reporting into him are doing their job properly)? Would you agree that they're likely to be a more effective VP if they did?

> "Unless your team is tiny, inserting yourself into actual execution means you just created a huge schedule hazard for your team."

How so?

> Would you agree that it's possible for a VP to have better information (assuming the people reporting into him are doing their job properly)? Would you agree that they're likely to be a more effective VP if they did?

Is it possible? Sure.

Let me posit an alternate scenario: Is it possible that the key features aren't necessarily the ones with the major engineering challenges, and the key contributors aren't the ones churning out code? Is it possible they value things differently than engineers?

As for how you become a schedule hazard: As the number of people reporting to you increases, you are spending more and more time on management tasks instead of technical tasks. And, to add insult to injury, you'll have more unplanned demands on your time. Your available time becomes less, and it become unpredictable. Putting yourself on the critical path means creating risk.

<4 reports -> you're still able to significantly contribute engineering wise

<8 reports -> your output is diminished, but you can usually at least guarantee a fixed quantum of time (50%, 20%, however much you can set aside)

8-12 reports -> things become dicey in terms of scheduling. If you take on responsibilities on the critical path, be prepared that you might need to put in long hours if anything unexpected pops on your radar. You also impact your ability to work on strategy.

>12 reports -> You can scratch out the occasional fix for completely noncritical issues. And half of the time, you'll need to hand off the fix anyways.

>15 reports -> Congrats. You need to start thinking about building managers to take on some of the load of running the team. Building actual artifacts is something you dream of, but don't get to do.

Obviously, not hard numbers - YMMV. But based on what I've experienced, they work relatively well as rough guidelines. It changes based on the complexity of what you tackle, how mature the product is, and how much time you actually want to invest in managing people.

I think it's perfectly acceptable for managers who are managing many people to utilize the tools that are typically used for aggregating people's opinions in other contexts. They can ask them to fill out a survey, ask them to vote on an issue, or have representatives responsible for representing the opinion of subgroups that they manage.

> or have representatives responsible for representing the opinion of subgroups that they manage.

Yes. And so the opinion becomes filtered. See above.

I guess I didn't mean to criticize managers who are continuously soliciting feedback through a middleman, just ones who aren't soliciting feedback at all.

The right answer for any leader at Director or above is to simply schedule 1:1s with random people from all levels of those you manage directly or indirectly, at least once--if not more--per week.

It's a rather efficient bullshit detector when you have two or more layers down in the organic chart.

This, plus :

>>> When things aren't going right, these senior leaders have a limited number of options to make a change.

Means to me that, well, randomness is a big part of the job.

So WTF are they paid so much ?

Senior leaders have plenty of options to make changes. McDonald's leadership (including Ray Kroc and the McDonald brothers) did lots that wasn't in those categories.

Reply on news.ycombinator.com