Hacker News Reader

Comment by ThJ | Hacker News Reader

The tendency to promote people out of engineering and into management is probably down to the bottom line. At some point, an engineer's economic worth plateaus, and the only way to justify a bigger paycheck is to have him offload the upper management. Managing people is extremely time consuming. Time spent on managing people is time not spent on closing deals, maintaining business relationships, securing investments, etc, so it becomes extremely important to delegate.

View on HN

Why not just hire a (hopefully) good people manager? It's hard to find good managers, but it's also not entirely likely that your best IC engineer is going to be a good manager naturally either. Whereas you know they're good at what they're doing now.

If they're not going to find a way to be more worthwhile, just don't pay them more. If they find a way to be more worthwhile (teaching, coaching, setting standards, whatever), then pay them more.

You need to know the domain in complex fields. In my area, the non engineers have no clue what is going on and are almost dead weight. The high output engineers now in management aren't always the best at managing people, but at least they make good decisions and don't slow the rest of us down.

You probably don't need to force the _best_ engineers go into management to achieve this - you just need someone with the necessary background and experience - and from that larger pool you can choose the ones that want to do management, and are more likely going to be good at it.

The managers I deal with day-to-day were all once ICs in the same role, but I wouldn't put almost any of them in the same category as the strongest ICs we have in technical skill. And they mostly don't make bad technical decisions - because they mostly don't make any technical decisions - they defer to their strong ICs.

For my own knowledge and perhaps others can understand your comment better, what's an IC?

Individual contributor

Individual Contributor, i.e. non-manager.

You're making the assumption that the company actually has a technical track (or one deep enough to match management) where the only way up isn't management.

It shouldn't be that way, but it commonly is.

I think this is a good general point. Looking at management as "just hire a good people manager" is too myopic. It takes many things to just be a good "people" manager - empathy, high bar setting, ability to negotiate compromises. And that doesn't include the _other_ skillsets a good engineering manager has: understanding the time tradeoffs of the team, delivery management, ability to resolve technical stalemates, ability to communicate effectively up, down and across to ensure people are coordinated, work is non-duplicative and efficient. Being an engineering manager is not a "black hole" for old people who don't program, it's a completely different technical skillset. A good one produces quite a bit more value to the company than _most_ single engineers can. Not because they are bad, but because writing good software requires lots of good engineers working together.

In my case I'm referring to a regular/traditional engineer and not software engineer for my particular industry, but the concepts a as far as management go are the same. One thing that makes me glad I'm not in a software shop is that I see virtually zero age discrimination. It takes years and years to build up industry experience, so generally speaking, the older the better. Where young folks usually do better is with computers/programming/automation as it wasn't common place outside of college for older engineers. This doesn't mean that some older engineers can't write some Fortran though.

> At some point, an engineer's economic worth plateaus, and the only way to justify a bigger paycheck is to have him offload the upper management.

Why not just accept a paycheck that plateaus as well? Mine's been pretty flat since I first (prematurely) got to that "senior" title. I'm not anticipating big gains in future.

Yeah, I peaked in my 30s. I was happy about that - I was making good money. Unless someone at Google has an aneurysm and accidentally hires me, I expect my salary to stay about the same from here on out.

Why not go get a job at Google? If you’re good the received wisdom seems to be to inhale Cracking the Coding Interview and the Algorithm Design Manual. If they don’t have any open positions where you’d like to work that’s one thing but why not take the extra money if it’s there?

It is not just about the interviews.

Google and others in the big five also evaluate "career trajectory".

That means you need to show continuous progression in your career as a non-entry-level hire. Someone who has reached a plateau in salary usually doesn't have that, a "grizzled" tech veteran won't be able to show continuous career progression after surviving ups and downs in the industry (layoffs, failed companies, career changes).

There are exceptions, of course, but those of us who are "olds" have to be more than just "good" to compete with younger talent in many (but not all) workplaces.

That's a misunderstanding.

They want you to show growth at Google, and if you are hired as an entry-level engineer. It isn't about what you did up to that point.

Source: did a lot of hiring at Google.

    >show growth at Google, and if you are hired as an entry-level engineer. It isn't about what you did up to that point.

Wait, do you mean: IF you are an entry-level engineer, they want you to show growth at Google upon getting hired at Google?

What about NON entry-level? That's my point-- career trajectory is, I am told, very important to them.

Yes.

There's an expectation that if you're hired below the level of Senior SWE you will get enough promotions over time to reach that level, more or less, although as long as you show the right trajectory there isn't any deadline attached.

If you're hired right in at director level or something, it's not like you're expected to end up CEO or you get fired :)

Do you think Algorithm Design Manual is better to read than Introduction to Algorithms for preparing for programming interviews at the big companies?

I have no idea. Probably just spending some time on Wikipedia is enough. Interviewers ask algorithms questions mostly because it's hard to find programming tasks small enough to fit in an interview which cover all the basics and which aren't implementing basic algorithms.

promoting people out of engineering and into management is among the worst things that an organization can do

It depends, sometimes it’s a good move to give an unofficial leader an official position.

Yes, I am all for technical leadership and giving people additional responsibility based on that but I think more organizations should take the 'people manager' approach managing people. In that case their lack of technical credentials can be accommodated by having 360 degree peer reviews for everyone. That has the added benefit of encouraging everyone to care more about what their colleagues think of them rather than one manager.

What often happens is a mediocre but ambitious engineer with only a few years experience tries hard to get into management track and succeeds. Sometimes they end up being good managers; sometimes they don't.

Reply on news.ycombinator.com