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