5 ms·

I think you have a pretty bad view of managers. There are plenty of management positions that are a) necessary, b) challenging, and c) very technical. "Moving

by mason55 13y ago

I think you have a pretty bad view of managers. There are plenty of management positions that are a) necessary, b) challenging, and c) very technical. "Moving to management" doesn't mean you suddenly just create Powerpoints all day. If you're a good technical manager you can suddenly use your skills to multiply your contributions far beyond what you'd be able to do as a single person. Let's start with the common premise that a good programmer is 10x better than a bad one. A good first level manager, who has 10 reports, could effect a difference of 100x. And a good senior manager, who has 10 midlevel reports, could effect a multiplier of 1000x.

fancyketchup 13y ago
It's not the view of managers, it's a view of the numbers. If approximately half the workforce is between 40 and 60 and half is between 20 and 40, then half your staff are managers. That would work if only two people report to each manager (branching factor of 2), but it seems very inefficient to have so many levels of management: log_2(#staff). On the other hand, with a branching factor of 10 only 1/9th of your workforce are managers, so management positions only support those between 55 and 60. The point of the original comment was that you can't have "move into management" as the default career track for people in their 40's. There just aren't enough management positions.
- mason55 13y ago
  > The point of the original comment was that you can't have "move into management" as the default career track for people in their 40's. There just aren't enough management positions. Totally agree. The thing is that that applies not only management but to senior development positions as well. Most firms have no need for a workforce that's 100%, 80% or 60% senior devs. There is a LOT of grunt development that needs to be done and the older you are the more money you're going to want. We can call them managers, senior devs, whatever, but the truth is that there's not enough room for everyone to constantly be moving up and making more money. Engineers have created a very egalitarian workforce and in most cases it's great but this is one of those cases where it doesn't work. Industries that have been around longer have already figured this out (law, banking, etc) where you have the "up or out" mentality. There's been a lot of work and research done showing how and why this works and how to create the proper balance depending what sort of work you're doing. The more cutting edge work you're doing the more senior devs you need but the lower percentage payout the partners get. It's not a matter of moving people to management or not but a simple fact of we can't all be at the top of a firm and if you're not moving up it's better to replace you with someone younger and cheaper who can do the same thing. Check out the book Managing the Professional Services Firm for more, it's a great read and really applies to software.
rbanffy 13y ago
I don't do Powerpoint (not at work, at least), but that doesn't mean I have the luxury of writing lots of code. Most of the time I spend coordinating the efforts of my own team with the other various teams and discuss the aggressive schedules my commercial and product teams want. What I cherish the most, however, are the moments when I can help them solve some tough, deeply technical problem, or help one of them build some really elegant piece of code. Engineering is an art.

by mason55 13y ago

fancyketchup 13y ago

It's not the view of managers, it's a view of the numbers. If approximately half the workforce is between 40 and 60 and half is between 20 and 40, then half your staff are managers. That would work if only two people report to each manager (branching factor of 2), but it seems very inefficient to have so many levels of management: log_2(#staff). On the other hand, with a branching factor of 10 only 1/9th of your workforce are managers, so management positions only support those between 55 and 60. The point of the original comment was that you can't have "move into management" as the default career track for people in their 40's. There just aren't enough management positions.

mason55 13y ago
> The point of the original comment was that you can't have "move into management" as the default career track for people in their 40's. There just aren't enough management positions. Totally agree. The thing is that that applies not only management but to senior development positions as well. Most firms have no need for a workforce that's 100%, 80% or 60% senior devs. There is a LOT of grunt development that needs to be done and the older you are the more money you're going to want. We can call them managers, senior devs, whatever, but the truth is that there's not enough room for everyone to constantly be moving up and making more money. Engineers have created a very egalitarian workforce and in most cases it's great but this is one of those cases where it doesn't work. Industries that have been around longer have already figured this out (law, banking, etc) where you have the "up or out" mentality. There's been a lot of work and research done showing how and why this works and how to create the proper balance depending what sort of work you're doing. The more cutting edge work you're doing the more senior devs you need but the lower percentage payout the partners get. It's not a matter of moving people to management or not but a simple fact of we can't all be at the top of a firm and if you're not moving up it's better to replace you with someone younger and cheaper who can do the same thing. Check out the book Managing the Professional Services Firm for more, it's a great read and really applies to software.

rbanffy 13y ago

I don't do Powerpoint (not at work, at least), but that doesn't mean I have the luxury of writing lots of code. Most of the time I spend coordinating the efforts of my own team with the other various teams and discuss the aggressive schedules my commercial and product teams want. What I cherish the most, however, are the moments when I can help them solve some tough, deeply technical problem, or help one of them build some really elegant piece of code. Engineering is an art.