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.
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?