Hacker News Reader

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. Often made worse by making it politically untenable to raise salary above certain levels without promotions.

Back when I worked at Yahoo, the existence of a separate path to promote tech specialists was one of the great redeeming parts of the organisation, as well as a willingness to be flexible about remuneration for top performing tech staff - e.g. one of my direct reports was a developer that I gave raises that pushed his salary up above my own due to a combination of much longer service than my own and stellar performance (Yahoo was a great employer overall - at least the London office - back when I worked there, up to and including providing proper training for managers as well; but it was already then suffering from multiple-personality disorder, trying to be both a tech company and a marketing / media company at the same time).

But the problems also manifests for people who could do very well as managers, and maybe eventually will do, but who doesn't get proper support.

> 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. Often made worse by making it politically untenable to raise salary above certain levels without promotions.

Short of finding a new job, I'm not sure how to work around this problem without becoming a manager.

Yeah, if your a dev in a company like that, it's incredibly hard to change - it takes buy-in from the top, as it involves paying developers more, while still paying managers too. Convincing them that the long term loyalty of staff and the expertise you'd have available by having people stick around with far longer tech experience is incredibly hard - if they believed that, they'd probably already have put something in place.

Finding a new job will very likely not help either.

In theory moving to a new job is an effective way of increasing salary.

Increasing, yes. But it won't get you into manager salary territory.

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

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' :-)

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

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.

One thing you may be overlooking is the importance of employees respecting management. We nerds tend toward inherent distrust of nontechnical management, and it is likely that promoting technical people into management helps overall team cohesion by enabling far better manager-managee respect and rapport.

I agree that non-technical management is a huge problem. I'm one of the first to complain about that. If a tech person wants to be a manager, and they can get the right training, then great!

But too often I think non-tech people are pushed into management because that's the only way to advance their career, get a raise, etc. They don't really want it. Pushing people who don't really want a job into management doesn't really solve the "tech vs non-tech" issue IME.

My company is going through a phase where someone thought "We're doing pretty well by promoting engineers into management/business positions. How well could we do if we put some people with "real" business backgrounds (MBAs) in charge?"

It's a disaster. It seems that finding a technical person and having them learn the business skills is more common and easier than taking a business person and hoping they can learn enough technical skills to be able to understand the piece of the business they're in charge of.

In my situation, it's a manufacturing engineer with an MBA who was asked to manage a design engineering department. What happened was that he forced the implementation of procedures and checklists on immature processes. So the procedures were immediately out of date and because the processes were immature, there's no solid theory of operation - just lists of steps that engineers and techs execute blindly.

There are actually a fair number of companies that have a tech ladder. I think the big 4 tech companies all do for starters.

The problem is mostly with non-tech companies and their "IT" departments that largely don't get it. It would be great for employees and for labor efficiency, but how do you even start trying to get buyin when the leadership's head is in such a different place?

My company has a tech ladder but it's incredibly difficult to climb the tech ladder. An engineer who wants to make the same money as a manager has to be a superstar whereas managers of the same salary level can be mediocre.

yeah, but we have an ice cream shop.

I think you'd have to "take one for the team" and play the game until you get to or near the top then introduce it. Probably true of a lot of changes that should be made in places like that. That's assuming you have the will power to not be turned into what you're trying to change or get washed out.

It's really not that they dont get it. It's that they dont have technical problems to solve that require a person of that tenure or experience. Many large corporations actively make an effort to avoid solving hard technical problems, they are business oriented, not technically oriented.

> Yet the career path is still set to go through management.

My current company (Google) and my previous company (Electronic Arts) both have job ladders for technical people that let you continue to progress without having to take a management position.

You are expected to have influence among other people, of course. Your work should have higher impact the higher you go. But you can get that impact without having to have direct reports.

It's one of the things I really like about both companies. I like working with people, and I like feeling like my expertise has wider impact as I get better, but I've never had any desire to manage other people.