3 ms·
> 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
by groby_b 9y ago
> 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.