3 ms·

> I agree, a big part of the problem is that few tech organisations have alternate progression paths for technical staff, so promoting to management is seen as

by wolfgke 10y ago

> I agree, a big part of the problem is that few tech organisations have alternate progression paths for technical staff, so promoting to management is seen as the only way of rewarding long term tech staff. An idea to solve this problem that I have seen, I think, on HN: Why are the managers the people who decide what the subordinate programmers have to do? Why not instead hire management people who assist the programming team to do the things that the typical programmers don't like (in opposite of "management types")? To give examples: Instead of some management boss forces some deadlines on the programming team, now instead the "management assistant" is here to communicate the deadline to the customer so that the programmers are shielded from grumpy customers who want more tight deadlines. Or they are mediators if there are conflicts in the programming team. Or they serve as the bogeyman who explains to the customer why their idea for new "necessary" program features cannot be implemented this way. Or they help (instead of force) the programming team to arrange some roadmap for shipping the product (something unluckily few programmers like). Or they help the programming team to understand what the customer really wants so that less time is wasted implementing stuff that the customer meant differently. ... TLDR: Why not reverse the hierarchy: The management guys assist the programming team.

slgeorge 10y ago
Because of the incentives - what's the incentive for someone to become a "management assistant"? According to your description it involves handling all the sh*t work that you don't want to do, but with absolutely no upside in terms of scope, power or authority. Presumably, you're willing to pay someone well to do this, but that only handles extrinsic motivation not intrinsic motivation. If you wouldn't want to get up in the morning to do it, you should doubt that anyone else would want to either. Just look at your list: + Or they are mediators if there are conflicts in the programming team. A job you don't want to do that involves smoothing the feathers of various angry people and their messy emotions. All mediation is terrible because you always land-up being disliked by 50% of the parties, and if you're truly blessed 100% of the parties. Your use of the word mediate is interesting because I think you mean "can't tell them what to do" - so that way you get to be disliked by all the parties and don't even get to solve the actual problem! + Or they serve as the bogeyman who explains to the customer why their idea for new "necessary" program features cannot be implemented this way. A job that involves handling angry customers who actually pay for everyone's salaries. I don't know how many calls you've had to do with customers telling they can't have things, but members of the public can generally be quite unpleasant - particularly when they feel they've paid for something and they're not getting it. And, it likely puts that individual at risk of being fired if the customer says that they're not going to work with your company any more! + Or they help (instead of force) the programming team to arrange some roadmap for shipping the product (something unluckily few programmers like). Sounds fairly tedious trying to get a bunch of people to agree by consensus some stuff that they just don't want to. And when "help" becomes that the developers believe the roadmap can't be done in the time-line the customer wants, what are you expecting to happen? Oh and the effort estimates the developers have for each step on the roadmap are probably 100% correct right, so we can be certain it can't be done. Because it's well known in the technology industry that technical effort estimation is 100% correct! + Or they help the programming team to understand what the customer really wants so that less time is wasted implementing stuff that the customer meant differently. Seriously, the problem here is that why would someone else be any better at understanding the users requirements than the programmers - if you have an interface it automatically loses something in translation - developers should spend time with customers or be customers. Bottom line neither managers or developers are psychic! Again this is someone doing messy work that you don't want to do - you're definitely going to have to motivate me to do all of this! Of course, these are often all part of management - but let me point out the first skill - being able to successfully frame something in a manner that makes an individual intrinsically motivated to do it .. your list would have a reasonable chance if you can understand these strange creatures called 'managers' :-)
- Myrmornis 10y ago
  Just get nice kids out of college with humanities degrees to handle the liaising and fluff work etc.
charleslmunger 10y ago
I've had three managers at Google, and all of them fit this model. My managers have: * Handled comp planning and negotiating with upper management for headcount * Escalated technical disagreements my team had with other teams * Provided career advice and coaching to me and their other reports * Made me actually take time at the start and end of the quarter to grade performance towards quarterly goals, and set goals for the new quarter. Importantly, it was the engineers setting and grading the goals. Not all managers at Google follow this model - some are active software engineers that act as manager for a small team of junior engineers, some are tech lead + manager but not writing much code, and I'm sure some are bad, because Google is a big place and humans aren't uniform. But all eng managers that I've heard of have a strong software engineering background - there are no pointy haired bosses. These are not necessarily the views of my employer, I'm not speaking for them.

by wolfgke 10y ago

slgeorge 10y ago

Because of the incentives - what's the incentive for someone to become a "management assistant"? According to your description it involves handling all the sh*t work that you don't want to do, but with absolutely no upside in terms of scope, power or authority. Presumably, you're willing to pay someone well to do this, but that only handles extrinsic motivation not intrinsic motivation. If you wouldn't want to get up in the morning to do it, you should doubt that anyone else would want to either. Just look at your list: + Or they are mediators if there are conflicts in the programming team. A job you don't want to do that involves smoothing the feathers of various angry people and their messy emotions. All mediation is terrible because you always land-up being disliked by 50% of the parties, and if you're truly blessed 100% of the parties. Your use of the word mediate is interesting because I think you mean "can't tell them what to do" - so that way you get to be disliked by all the parties and don't even get to solve the actual problem! + Or they serve as the bogeyman who explains to the customer why their idea for new "necessary" program features cannot be implemented this way. A job that involves handling angry customers who actually pay for everyone's salaries. I don't know how many calls you've had to do with customers telling they can't have things, but members of the public can generally be quite unpleasant - particularly when they feel they've paid for something and they're not getting it. And, it likely puts that individual at risk of being fired if the customer says that they're not going to work with your company any more! + Or they help (instead of force) the programming team to arrange some roadmap for shipping the product (something unluckily few programmers like). Sounds fairly tedious trying to get a bunch of people to agree by consensus some stuff that they just don't want to. And when "help" becomes that the developers believe the roadmap can't be done in the time-line the customer wants, what are you expecting to happen? Oh and the effort estimates the developers have for each step on the roadmap are probably 100% correct right, so we can be certain it can't be done. Because it's well known in the technology industry that technical effort estimation is 100% correct! + Or they help the programming team to understand what the customer really wants so that less time is wasted implementing stuff that the customer meant differently. Seriously, the problem here is that why would someone else be any better at understanding the users requirements than the programmers - if you have an interface it automatically loses something in translation - developers should spend time with customers or be customers. Bottom line neither managers or developers are psychic! Again this is someone doing messy work that you don't want to do - you're definitely going to have to motivate me to do all of this! Of course, these are often all part of management - but let me point out the first skill - being able to successfully frame something in a manner that makes an individual intrinsically motivated to do it .. your list would have a reasonable chance if you can understand these strange creatures called 'managers' :-)

Myrmornis 10y ago
Just get nice kids out of college with humanities degrees to handle the liaising and fluff work etc.

charleslmunger 10y ago

I've had three managers at Google, and all of them fit this model. My managers have: * Handled comp planning and negotiating with upper management for headcount * Escalated technical disagreements my team had with other teams * Provided career advice and coaching to me and their other reports * Made me actually take time at the start and end of the quarter to grade performance towards quarterly goals, and set goals for the new quarter. Importantly, it was the engineers setting and grading the goals. Not all managers at Google follow this model - some are active software engineers that act as manager for a small team of junior engineers, some are tech lead + manager but not writing much code, and I'm sure some are bad, because Google is a big place and humans aren't uniform. But all eng managers that I've heard of have a strong software engineering background - there are no pointy haired bosses. These are not necessarily the views of my employer, I'm not speaking for them.