Hacker News Reader

Comment by siliconc0w | Hacker News Reader

Sadly this is mostly true. It used be at $bigtech you needed to be the equivalent of a senior engineer (L5+) to go into management. This is categorically not the case anymore.

TPMs, due to their role, work across orgs and interface more with leadership so they do seem to get a lot more visibility/exposure than normal ICs and do seem to get promoted into leadership positions more easily. My wife is less technical and is looking for a career change and last year I literally suggested this path for her.

(you can argue separately that this isn't as important which I might agree with on a case by case basis in that I've seen really strong leaders who are less technical who make up for in various ways but it's not the common case).

View on HN

I think alot of engineers are under the impression that if they work hard enough they will be promoted. But actually, the company gains the most from highly productive mid level engineers. These are the workhorses, they do not want to promote them.

You never get promoted for “working hard”. You get promoted by showing your ability to work at a larger “scope”, showing “impact” and “dealing with ambiguity”. All of the leveling guidelines of tech companies I’ve seen or heard about have the same concepts.

The whole "scope" argument is the carrot on the stick. Many engineers, regardless of performance and scope, will not get promoted. They are more valuable to the company as work horses, even if they have higher level capacity and have shown that.

I don’t disagree with that. The best way to get a “promotion” is to work toward more scope, impact, ambiguity - and then leave.

Or in my case get PIP’d from Amazon with a nice severance and found a much less stressful job within three weeks at a smaller company. My hearts always been at smaller companies and I knew from the minute I virtually walked into AWS I wanted to go back to smaller companies.

https://news.ycombinator.com/item?id=37969302

What about the ambiguity engineers cut through when making decisions like whether to use "React" or "Svelte"? and subsequent success or failure, whatever the case may be. Are these decisions less important that top level ones?

That’s not what is meant by ambiguity.

I was actually just interviewing someone for a position for a green field project where I’m leading the backend parts across teams. I needed to be able to “fire and forget” an assignment where the requirements weren’t clear and there will probably be a lot of XYProblems.

I need them to talk to the vendor/customer, come up with a game plan, research the technology and present their idea to the team. I want them to know how to talk to developers, technical directors who don’t want to get into the weeds and non technical people.

After they have done the research - especially about a technology I don’t know - I want to lean on them to teach me and for me to be able to go to for advice.

I’ve given the thumbs up plenty of times for team members and now dotted line reports that impressed me by giving me “imposters syndrome”.

Organizations are generally pyramids, where you have fewer people on top than on the bottom. You can't promote everyone, so you have to decide on criteria - and hard work in software engineering isn't always high-leverage work. In my experience the best engineers can figure out the right work to get done, saving hours of hard work that never even needed to happen.

> TPMs, due to their role, work across orgs and interface more with leadership so they do seem to get a lot more visibility/exposure than normal ICs and do seem to get promoted into leadership positions more easily.

TPM here. More cross-org work: Yes. Interface more with leadership: Yes. Visibility/exposure: Yes. Easier promotions? Nope. Not in my experience.

There are fewer of us, therefore our org chart trees don't grow as fast as engineers' trees, therefore there are fewer opportunities to add a layer and move into it as a manager.

Reply on news.ycombinator.com