Hacker News Reader

> The ladder isn’t really taller. Most EMs end up clustered at the equivalent of L6/staff engineer. Promotions to senior manager and beyond are situational and rare. Meanwhile, my peers on the engineering ladder get promoted when ready, without needing to wait for the stars to align.

This sounds like an anecdote tainted with confirmation and survivorship bias. Most SWEs get stuck at senior (especially at Google), getting clustered at L6 is already a privilege relatively speaking. Promotions to L6 are not super rare but less than a majority get them. Promotion to a L7+ is a struggle, if you say most of your peers get there naturally maybe you discounted those who left because they can't get promoted, or you just didn't happen to make many friends with people below your job level ? Or, as a senior manager, are you really sure you see that more than half of the team you manage reach L6+ and a good number to L7 just by waiting?

Now I do agree that the EM path doesn't open as many doors as some old school people think (especially since high level ICs tend to lead in some way too), but at least promotion opportunities doesn't seem to be thinner for EM than IC.

The expectation that everyone should reach these career levels is easily dispelled by basic math. L6 and EM can by definition exist at a ratio of, at best, 1:6 to the people at more junior levels. Most engineers might be “stuck” at L5, but most potential EMs are stuck before they even become EMs, due to the same math.

But of the people at L6 on either ladder, who are ready to work at the next level, opportunities are definitely easier to find for ICs, than managers. An L7 IC, after all, doesn’t have to come with a team of 30-50.

I've never seen a large company with more L7+ engineers than L7+ managers. Usually it's a ratio of drastically more managers hired/promoted into those levels than engineers, and some orgs don't have any engineers in those levels at all.

> L6 and EM can by definition exist at a ratio of, at best, 1:6 to the people at more junior levels

And for the respective IC of that level the ratio is even worse as in many companies they help out with many projects consisting of 5-10 people. In short there are many more manager positions at a respective level than IC ones.

I also found it weird that the author thought being an EM is a good path to being an entrepreneur.

Going from zero to one has very little to do with engineering management. Being able to hack out code quickly and being comfortable talking to potential customers (preferably not in that order) are the most important things and not at all related to being an EM. It's no guarantee that you'll get to hire anyone to manage.

And yeah, there are mechanically far fewer management roles than engineering roles, and since the boundary between lead engineer/first line manager is pretty porous in both directions, you're not actually competing with an equivalently smaller pool.

> I also found it weird that the author thought being an EM is a good path to being an entrepreneur.

This was the pitch from my manager that led to me moving into an EM role. He knew I was interested in doing a startup in the future, but I didn't have experience with people management.

I don't think it's necessarily a great path to entrepreneurship, but if you are solid on the engineering side it's a good skillset to develop.

If your company has any chance of success you will be managing other engineers.

Thanks for the feedback! I must say I've never worked in real big tech, and I've never worked with an IC beyond staff level. I'd imagine promotions to principal / fellow are quite rare as well? Besides, most "normal" companies don't have these grades, at all.

By transferable, I mean skills that are useful outside of our big tech bubble. You might not want to go out as money is very nice, but still good to know you can do something beside computer beep bop.

Ah right, I tend to think the tech bubble is the default context for stuff posted on HN, but of course that's just my bias.

I think staff engineers are slightly more common than first level EMs, but senior EMs are slightly more common than senior staff. Beyond that, it's small numbers and hard to draw conclusions. The nuance I've felt is that promotions to staff and up on the IC ladder are more in your control, while EM promotions are very much about being in the right place at the right time, in addition to being ready for the role.

I have worked at "normal" companies as well, and I think the EM role there is slightly different? To me it seemed like it's people management + technical, while in the tech bubble, that would be called "TLM". "Pure" EMs are mostly doing people management only, with strategy and XFN alignment. Does that sound correct to you?

Good point on the control over your promotions, it's something I experienced when moving into an EM role. Banging my head until hitting an actual growth team.

I come from Russia, we're not exactly known for great people management, and I'd say management up to department head is expected to handle the tech part as well even in larger companies such as Yandex / VK. This fits your definition of normal companies perfectly.

> I think staff engineers are slightly more common than first level EMs

That’s going to depend a lot on company (and how they define staff vs senior; that varies quite a bit).

Beyond being in the right place at the right time, the higher EM promotions are also more obviously zero-sum, since there is a clear number of roles and only one person can get a role. Dynamics for ICs at higher levels are somewhat similar but not as clear cut

Quite a lot of smaller companies do have some sort of staff/principal level, though arguably it’s largely an excuse to pay people they want to retain more, and isn’t _that_ similar to staff/principal roles in Big Tech(TM).

Of course, companies on that scale don’t really have senior EMs in the Big Tech sense, either.

>The single most transferable skill I know in this industry is Linux internals.

I'm glad it's not just me who has noticed this!

Would either of you mind expanding on this? What kind of roles have you held?

I have worked on security, databases, some distributed systems, a couple of video games, AR/VR and some ML systems, mostly connected to database and data pipelines. Knowing what the kernel is likely doing underneath has been useful in all those domains. More than that, being able to set up a production environment by yourself is hugely useful.

If you know the internals, the complexity of a lot of middleware kind of collapses, too. There are a million frameworks for doing threading, for example, but they basically all boil down to clone, a futex and some atomics. Similarly, you can figure out how almost anything works with strace. It demystifies so many things that you otherwise need years of experience to debug.

As a practical matter, you can always find a job as a competent DevOps type who can code and talk to SWEs.

Are there any books etc that you could recommend on Linux internals. I am mostly write c# code, and I didn't do computer science, I mostly self taught. I recently set myself the task of learning some c as I was finding that I was hitting a brick wall when it came to trying to learn more lower level concepts.

I want to work my way through computer systems a programmers perspective :

https://www.amazon.co.uk/Computer-Systems-Programmers-Perspe...

If you're the kind of guy who likes to work through one 1000+ page behemoth at a time, I can recommend The Linux Programming Interface specifically. As a nice secondary bonus, the code examples are all in good old fashioned C, so you can compile and run them to test things out as you please. :)

Seconded and the book is https://man7.org/tlpi/. One can even reads parts of it digging deep into the area one is trying to understand better.

Thanks

I recommend consuming everything Brendan Gregg produces. His work is mostly around kernel performance profiling and tracing, but you can learn a lot from just doing that. Also, the vast majority of time when you need to dive into kernel internals it is for performance reasons.

https://www.brendangregg.com/linuxperf.html

If you prefer physical books “Systems Performance” by Brendan is good as well.

As the sister comment says, Linux Programming Interface is really good for learning linux system programming topics but it is mostly focused on user space.

For more userspace stuff I like Chris Wellons‘ blog at nullprogram.com

Thanks for this :)

> Similarly, you can figure out how almost anything works with strace.

I recently had an example of this higher in the stack than anything you listed: A co-worker couldn't install node_modules because yarn appeared to be running an older version no matter what he tried to upgrade it - turned out there was a hidden config file in his home directory none of us knew about that could tell yarn to use a different version of itself.

A couple of other points that struck me as different from my experience, and maybe more a function of where this person is working rather than some fundamental difference between the roles:

The idea that your word is taken more seriously as an EM rather than an IC when it comes to (for example) needing to test more.

I have to admit that this may have been one of the reasons I felt the need to switch to a management role myself (I was an IC that had recently been promoted to a staff level role and subconsciously I felt like I lacked credibility and hiding behind a title would help me get some). In practice that turned out not to be true -- I didn't need to do that at the time, and now as an IC in a different company, my thoughts and feedback are taken seriously at an organisational level and by my peers.

The fact that you have to stack rank and pick an under-performer every half is just broken. I know it's a sad reality of performance management in a lot of places but it's not a universal truth that you will have to do that as a manager. Statistically, you can't avoid having difficult conversations about real performance problems, but there are companies where managers don't have to have the "everyone else on the team did better than you this half" conversation or the "I had to pick so this half you got the short straw" conversation.

> The fact that you have to stack rank and pick an under-performer every half is just broken.

I've sworn to myself, that the moment that this idiotic idea get introduced in the "performance management" process at the place I work, will be the day that I'll start to send out resumes. Even if it were handled lottery style ("the short straw") I would not cut slack to either manager or company for such an indignity.

Yeah, I even asked my current employer if its there in the company. He said no. Its there under a different name. I realised why the team culture was so bad. I am sending resumes to other companies already.

It mostly masquerades as performance curves.

You're not being told to pick someone, you're being told that your org cannot really have 80% of people meeting/exceeding expectations and that because reasons (budget), you should review the cusp cases and adjust them down.

IME in ~20 years I’ve never been on a team where there wasn’t someone underperforming (I acknowledge sometimes it was me!). So while I agree it’s stupid to force a curve, it also doesn’t seem realistic when every manager claims their entire team is great.

Your personal experience notwithstanding, I don't think that it can be generalized that there is always an under-performer on every team.

If I may offer my anecdata, I've seen several teams that could be characterized by stability and depth of expertise in their respective areas. You could say they always performed on a very high level, but never over-perform, because the high level is what is expected. Stack ranking those teams equates to killing them.

I also agree that a scenario where all individuals over-perform all the time is also rather unrealistic. But individual evaluation of performance is not stack ranking.

It depends how big a “team” you consider. At the 5-10 level maybe not. At the 30-50 level most likely yes. At the 100+ level there are certainly a few.

In the well run orgs at Amazon the bell curve is applied at the larger scales where it makes sense.

I would use different terms for such organizational units (group, department, division), team, in my mind and use of language, would mean low two-digit (at most) number of people reporting to the same manager and collaborating on similar topics.

But sure, the larger the structures the more likely regression toward the mean will kick in.

> The idea that your word is taken more seriously as an EM rather than an IC when it comes to (for example) needing to test more

i thjnk this has to do with where you’re testing your word as the power of a statement from anyone in an org from my experience has entirely to do with how much money is missed potentially by listening to someone’s opinion.

im quite far up the management chain in past orgs and while i could make calls like “no we aren’t hotfixing in a new feature the client wants in 2 days since it will never work well and that’s not enough time to properly smoke test this very involved feature.”

the rnd team loved this statement because they understood it and agreed with it and saw i took their concerns seriously.

sales management was pissed understandably as the client abandoned the negotiation because we didn’t meet their demands, no matter how right i thjnk we were to deny this request. but the argument got pretty far in the company despite the fact that everyone agreed it would be a disaster to do this.

it’s not really about power and position i guess, it’s how convincing you can be this is profitable for most companies. ego and power tripping are of course part of it but the ultimate decision is how well you can paint the financial prospects of it.

a similar request in the future was shit down faster as i asked the qa test to show on some mock code how many considerations we needed and the plain time for such a feature to be properly implemented — the financial impact was dire if we raced it out and that stopped the conversations very fast.

What you’re saying is true but being able to talk and convince people gets you wayyy further than any other method.

> The fact that you have to stack rank and pick an under-performer every half is just broken

I didn't realise places still did this. Even Microsoft stopped, and I think acknowledged that it was crippling to them in the 2000s as talent rushed to less silly companies.

Isn't this the standard in Amazon? But I guess the cutthroat approach is part of their corporate DNA.

> The ladder isn’t really taller.

In my company, I think it's roughly 2-3% at L7 or more. It takes really special skills to reach that level, not just years of experience. I don't know how it compares to EM though, but it's a tall ladder!

> those of us happy to go back to IC roles have no trouble finding work

My concern as an IC is ageism. I wish that I can say that when I'm 50+. I feel EMs are a little more immune to that (perhaps more so in Europe where SWEs aren't very well respected).

There were slightly more L7 EMs than L7 SWEs every time I looked, but there's nuance to that. If the company decides it needs an L7 EM and nobody is available to promote, they'll hire externally. Your chances of being promoted into that role are reduced by the proportion of L7 EMs who were external hires. The other nuance is that those numbers don't correct for overall tenure, but I don't know how that would change things. Finally, getting to L7 EM is maybe 30% in your control and 70% circumstances, but that ratio is IMO inverted for ICs.

So even though there are more L7 EMs than SWEs, you might still have an easier time getting to L7 SWE, if you're ready to be an L7 SWE.

Your point about ageism is well-taken. I'm not yet old enough to really feel it, but I have heard it's rough.

> Finally, getting to L7 EM is maybe 30% in your control and 70% circumstances, but that ratio is IMO inverted for ICs.

That sounds like a positive. As an EM, there's a good chance you'll be promoted to L7 via pure luck - with no abnormal amounts of effort, and with no outstanding talent for management. It sucks if you're in the minority which "deserves" the promo (is super hard working and talented), but for everyone else, it's a free lottery ticket to a higher comp.

That's... not actually how that 30/70 statement is meant to be read.

Imagine as a simplified analogy, applying to get into Harvard. Imagine Harvard has 1000 spots to fill, and that there are 10,000 applicants with roughly equivalent credentials (because they all have: near perfect test scores, high GPAs, strong extracurriculars, etc.).

In that environment, one might conclude that, for people who successfully get into Harvard, it was 30% their own skill, and 70% "luck" that the they happen to be semi-randomly picked by the admissions committee who could've easily gone with a nearly-equivalent alternative.

So sure, in that environment, "luck" is a factor, but this is by no means a "free lottery ticket" because the near-equivalent applicants had to work hard and be smart to reach the point of being near-equivalents of each other... So it is with promotions in competitive tech companies at least, where good talent is the norm.

When an external hire happens, they don't truly know what they'll be like unless they've already worked with them, so they could actually be of a lower quality who lucked into it

SWEs are generally speaking less respected (and compensated!) in Europe, but ageism is AFAICT much less prevalent. If I was in the US, it would be time for me to start worrying about it.

In my early 40s in the US, I try to stay close to deep tech companies that have profoundly hard problems. (The kind of stuff that eats juniors alive unless they have guidance.)

Even there, you kinda feel the org's Eye of Sauron looking at you wondering why you haven't ascended into the clergy of management sometimes.

I think digging into the roots of SWE's not being respected is worth discussing.

Are doctors, lawyers, or surgeons viewed the same way? I don't know those industries well enough to say. Some domains of software are very, very deep and require many years of study and practice.

It feels like the root of SWEs not being fully respected simply comes back to the fact that they aren't considered as part of the org as much as management is.

When I see a doctor, I kinda want them to be in their 30s/40s. If they're in their 60s it's been a long time since they've been to med school and while they have continuing-education requirements things do change

> I think digging into the roots of SWE's not being respected is worth discussing. Are doctors, lawyers, or surgeons viewed the same way?

Those are three very different things with different growth paths. But as someone who went from engineer to entrepreneur and is now on the product side, I can say that software people, almost as a rule, focus on stuff that doesn't matter for promotion. It's really frustrating sometimes.

Modulo pathological things like corporate politics, companies care about profit and loss. Grow the business, make the money roll in, and your chances of advancement approach unity. But far too many software people devote their time to "honing their tools", when, to the company, the entire tools budget is just a cost center. Identifying as a "tool person" at all just means that you're climbing a greasy pole. This is true even in "pure" software companies -- the difference between working on a business-critical initiative and, say, code-review tooling, can be everything to your career path.

Just to emphasize this point, consider the growth paths for the other careers you mentioned. Lawyers get paid well overall, but making partner depends on bringing in business. Surgeons and doctors are a bit more complex due to licensing scarcity, but if you know anyone in private practice, it's the same gig: get clients, grow the business. Meet the minimum threshold for technical competency, and nobody really cares if you're the best surgeon in the state, so long as you're bringing in patients.

The world revolves around money. Software is relevant only to the extent that it makes money.

Do you really respect doctors for growing their business? I would look down at a doctor whose mind is on money. When I really need a doctor, I sure do look for the best, not the one with the most patients.

your opinion of doctors is probably off. i'm married to a doctor (in the US) and i would say 4/5 doctors i meet spend most of their time talking and thinking about money. there are lots of reasons for this (some valid), but assume your doctor has money on the mind

Well, let's hope they still think of the interest of their patients first or that the incentives are aligned. Also, in the US, everything is more money oriented than in Europe which may explain the difference of views here. I grew up in a family of doctors and they didn't see their job as a business, but rather as a public service.

Ageism doesn’t seem to apply so much at the higher levels. At my company I see many L7+ in the 50+ range.

Promotions on the engineering ladder "when ready without needing to wait for the star to align" is because very often those promotions only entail better title and pay. Periodic promotions keep people happy.

But any promotions that entail a real step up in responsibility requires team/company growth for those positions to open up.

There are many different ways to grow beyond staff engineer:

- Become an expert in something hard. Fix bugs nobody else can. This requires sticking around for longer than most people, maybe 10 years or more.

- Have impact across the industry. Maintain a kernel subsystem, run a C++ subcommittee, etc.

- Be a TL for multiple teams, because you have experience and a plan the other TLs can get behind.

- Wear multiple hats, e.g. be a solid manager who is also a really good engineer. Be great at, e.g. Audio and ML, or some other rare combo.

These archetypes are starting to get documented by some companies as part of their careers ladders, even. As a SWE, you have many options to create scope. As an EM, you really only have one.

> Become an expert in something hard. Fix bugs nobody else can.

This is risky advice. :) Context matters. It's going to sound very appealing to a self-motivated, mobile IC, and could work very well in orgs that value individual effort. But in many orgs, solo experts playing non-fungible roles are very big red flags, and can draw negative management attention. Maybe I could build a team around you... but I might not have the resources, or the problem might not warrant it. So I just might end up making your work life harder -- mitigating the risk by devaluing the service you're working on, just moving it to SaaS, or maybe keeping it but making you train up all your colleagues on the risk area (turning you into an unhappy tutor), etc.

It might be better to phrase it as an architectural expert. Being in a position where you understand how everything works together better than anyone else is valuable. You can't necessarily train any other person to have such diverse knowledge, nor outsource it. This might lead to you being able to solve otherwise unfixable bugs, but that's more of a side effect.

Maybe. I get that being the best source of information might be a job-security feature. But it doesn't necessarily translate into growth opportunities. From a manager's POV, I might view you as a hoarder of information, a silo builder, a poor communicator, or poor team player. You might get job security out of this, because your knowledge will cement you in place. Why would we promote the linchpin out of the system they are holding together? Or it might just draw scrutiny to the larger business risks of your system, as I mentioned earlier.

If you could leverage your knowledge in a business-strategic way -- e.g., empower a team to work better by clarifying, simplifying, and standardizing the architecture -- you might draw attention as a future leader. (If you have a selfish boss who will steal credit, a little more political work might be needed alongside this.)

Most of your points are requirements for staff not “beyond staff”

I don’t think so - I’ve been in promotion committees to L7 and I feel fairly confident those are examples of L7 impact. Not by themselves sufficient maybe, but they’re the kind of stuff L7 SWEs do with their time.

I suppose I have heard that the L6 bar has lowered somewhat from ~2015, mostly in response to people complaining about being stuck at L5. But I wouldn’t have any first hand experience with that, other than my own promotions, which surprised me every time. So maybe the bar has been lowered.

Well at least they should be and most companies other than faang don't have enough scale to warrant staff vs sr staff (L7) breakdown so next level is principal with company-wide impact.

> I suppose I have heard that the L6 bar has lowered somewhat from ~2015

Yes title inflation is real. A lot of "Staffs" today would barely make it Senior 10-15 years ago. IMO this is a result of ZIRP so we might see reversal of that trend soon...

So you get paid more and have better career options without more stress... and you see that as a bad thing?

Another point: there many more senior+staff engineer roles than EM roles. Once you become an EM, it's much harder to make a switch, because:

a) the roles are fewer

b) companies are wary of bringing in an EM for a team (prefer to promote within the ranks, in my experience).

c) switching from EM to a senior engineer role is hard both because it feels like a downgrade and because I see companies not that willing to offer it.

Of course, if the company is on the right course, you've hit a jackpot and can become an important leader few years down the line, but I know many EMs who are trapped in a bad org because of this. I believe engineers transitioning to a management role should keep these things in mind. I prefer making less bucks and keep my peace of mind about moving somewhere else.

companies are wary of bringing in an EM for a team (prefer to promote within the ranks, in my experience)

In Band of Brothers TV series there is a plot line where an NCO is promoted to be an officer. Soon after he is moved to a different unit because the Army has a policy to distance such promotions from their organic units.

I’ve literally never seen this happen in the tech world

Neither have I but it is an interesting point to consider - to what extent is the EMs thinking biased by their previous experience of the team as an engineer.

Doesn't this seem like a useful bias to have?

The word bias has a negative connotation so perhaps you mean something else.

Given two EMs, one that came organically from a team and another that came "from the outside" and spent a few months working with a team - what advantages and disadvantages would the first EM have over the second?

IME internally promoted EMs are 4x better. They understand what problems the team is facing, how the product works, the various interactions with other teams, and the company processes. It takes at least a year for an external hire to ramp up to that level of familiarity.

I will say that for very dysfunctional teams it could be valuable to get an outside perspective which can do more severe change but hopefully this is less common.

Note, almost happened to me. My team's EM left, I said I would take his place even though I had no real desire to become EM. I'd rather just do it than bring in someone from the outside because our team was great.

Well, as soon as HRBP found out I would become a EM, suddenly there were 2 other areas that needed EMs much more than our team. (As we were very functional).

I made a condition that I would become EM only for our team and did not desire to lead others I didn't know.

I find it bizarre that HR would be involved in this at all. I'm glad I've only been a manager at places where HR pretty much functioned as a consultant available to management.

Also there is a comment by Major Winters that this is a stupid rule, because Lipton is one of the best and most respected platoon leads in the company.

True, Winters indeed said that but the interesting question is why would the Army have such a policy in the first place (I assume that here as in other things BoB sticks to the realities of the time).

The new LT would have to continue to interact with SNCOs in the battalion who had outranked him, which might cause friction.

Emotional detachment? Military officers have to send their troops into harm's way.

> The idea that 5 years of experience is enough to solve most problems is crazy to me. 18 years in the industry, and I’m still very aware of things I don’t know and need to get better at. I know amazing engineers with 40 years of experience who are still learning and getting better.

Recently retired engineering manager here. Manager I all the way to VP of Engineering at several successful startups and a few big companies.

I was continually surprised that fresh and new challenges continually appeared, until I got wise enough to know there will always be something you not run into before.

Be wary of anyone who think’s they’ve seen it all.

This guy gets it.

Senior management often seems like a popularity contest.

The ability to get along with others often seems to be more important than actually being a good manager, being aligned with the business, and delivering value.

>IMO the best thing about being a manager is that you get to spend a lot of your time thinking about the future

In some places it's the opposite: domain-specific codebases far outlive the separate projects they are used for, and the devs are the ones thinking about what their product should be. Kind of like how Linux is a long-lived product made by devs, used in many short(er)-lived C-level projects.

> senior management in many companies is basically a high school clique. Behavioral problems that would get normal people fired are sometimes tolerated in VP, C-levels, even directors sometimes, and working in such environments is trying.

I didn't see any other comments on this part, and want to give a huge +1. I use to wonder how overall cultures got so misaligned with what Sr. Leadership was saying in open sessions. The amount of contradiction in what they say in large groups, and what they *do* in reality, is the smart lower layers of the org seeing right through the BS. It was eye opening to be able to see behind the curtain.

omg so true re: terrible behavior of senior people (though thankfully not universal)

I suspect people view these senior leaders are irreplaceably important and tolerate all sorts of terrible/pathological behaviors from them...