Get the top HN stories in your inbox every day.
halper
Aurornis
> that it really depends on the organisation.
This is entirely it. Titles should be consistently ordered within an organization, but they are not portable from one organization to another.
This is a lesson I’ve had to explain over and over to people at the beginning of their careers. I’ve been asked for advice about which offer to take from people thinking about leaving 10s of thousands of dollars on the table because another company will give them a Senior Engineer title and they think that’s important.
When hiring, titles are basically ignored unless the person is coming from a company like Microsoft or Google where their leveling system is publicly known.
I’ve interviewed so many “Prinicpal Staff Engineers” or even “CTO” people who would barely qualify as senior engineers at an average company. I’ve also interviewed “Senior Software Engineers” who had more experience than knowledge than anyone on our teams (and that’s saying a lot!)
Hiring managers know this, but it’s not obvious if you haven’t done a lot of hiring or worked at a lot of different companies.
Swizec
> When hiring, titles are basically ignored
As a hiring manager, this is completely accurate. I don't look at your title, I look at your scope. Tell me what you did, for whom, and what was the impact. That's all I care about.
We all know that Senior Principal Architect Engineer at 3-person startup is somewhere around junior to mid-level at a real company. Whereas some poor schmuck at a larger company with a title like "Senior Engineer I" probably owns and runs more impressive systems and works with more stakeholders than that 3-person startup will see in a year.
democracy
Interesting, you've got it absolutely the wrong way around.
marcus_holmes
I think that engineering at a large organisation and engineering at a startup are two completely different disciplines with very little crossover.
undefined
scribblings
[dead]
stego-tech
This is why I align on comp ranges rather than title. I've been a "Lead" where all I contributed was a new imaging pipeline and introducing NAT to the product line, a "Manager" of a failing company where I had no managerial authority or direct reports, and a "Senior" at a SV firm where I actually behaved a level above a Senior Engineer - owning outcomes, doing research, mentoring juniors, building relationships across silos, governance councils, etc.
Titles are fungible, but your comp isn't. Don't let a company sell you on a better title for less comp, especially when the JD or role doesn't align with the title; the next place won't give a shit what your title was if all you did was Junior-level work because you bought into someone else's narrative rather than control your own.
icedchai
I've worked with several "Directors" that all had between 0 and 3 reports. Vanity titles make people feel good and look nice on a resume, but that's about it.
madeofpalk
"Lead" is a funny one, because its just not a level that exists where I currently work.
A few teams have a "lead" role, but its mostly ceremonial.
Esophagus4
100%
This is complicated during acquisitions… you have a new company coming in and leveling them is hard because it’s a mass title migration exercise, and nobody wants to be down-titled.
In the 2 examples I’ve seen gone wrong:
-the people at the parent company look at the acquisition’s team and think, “there’s no way this idiot should be a director.”
-the people at the startup think they’re geniuses because they got acquired but their tech is crap and they’re actually just 28 year olds running around without adult supervision
-the startup guys will all leave once they vest or be pushed out for being lousy
-the tech gets even more unstable because no one left knows how the code works
nradov
In pretty much any software startup acquisition by a much larger company, even if they do technical due diligence up front they have to assume that all the code will need to be rewritten within a couple years. It's good to keep a few key technical resources around during the transition period but otherwise a high attrition level is acceptable.
democracy
>> I’ve interviewed so many “Prinicpal Staff Engineers” or even “CTO” people who would barely qualify as senior engineers at an average company
Failed to design Quantum Lattice Bloom Cascade algorithm in 5 minutes?
Aurornis
More like: Couldn't cite anything they accomplished and had no real responsibilities.
For a good interviewer these people are obvious even without any coding tests.
pkaler
As others have said, levels and titles are generally for compensation and performance reviews. Each company has their own bespoke ladder but it generally maps to:
- L1: Intern with undergrad degree
- L2: Intern with graduate degree
- L3: Junior
- L4: Intermediate
- L5: Senior
- L6: Staff
- L7: Senior Staff
- L8: Principal
- L9: Distinguished
- L10: Fellow
L5 or Senior is usually considered a “terminal” role. That means all engineers should be able to get to this role. And people without the headroom get managed out if they can’t get to L5.
Staff+ is usually “special”. It means that people count on you to drive initiatives and you have something special other than just writing code. You are able to make product and business impact.
Distinguished and Fellow are very rare. Large FAANG companies will only have a handful of these engineers. It means you’ve made industry-wide impact like inventing map-reduce or DynamoDB or Kubernetes.
madhadron
You're describing a very small number of companies that all copied each other's systems. The idea of a terminal role, for example, is pure Facebook. These do not apply in general across the industry except where managers from those small number of companies came in and shoved them in before they were fired.
seangrogg
In all fairness, a LOT of this was copied over from the military. From ranks to "High Year Tenure" (aka "Up or Out") nothing here is particularly innovative.
digitalPhonix
Amazon had the concept of terminal role (SDE2, but I’ve heard it has changed) long before facebook existed.
sgillen
In my experience a lot of tech companies, at least in the Bay Area, have all copied this system.
tmp10423288442
I believe L5 was Google's terminal role at one point (over a decade ago) - not sure if it's changed since then.
hawaiianbrah
Terminal roles are definitely not a Facebook concept originally … Microsoft has had it for at least 20 years.
OJFord
> L5 or Senior is usually considered a “terminal” role. That means all engineers should be able to get to this role.
Doesn't it mean more like it's an acceptable end, a destination - obviously not everyone's career track is to take over the company as CEO one day, but nor is it necessarily to progress to Staff and beyond.
The idea being that it's a bit of a role change, to a greater extent than the levels before it which could be seen as advancement. Or, we've long had the idea of 'technical' and 'management' tracks, the more recent (I think?) idea here being that actually maybe they're both specialist tracks you switch onto, and you don't necessarily have to do either.
But I think, outside FAANG et al., whether companies subscribe to that sort of thinking is vastly more varied (or it's more niche) than titles and 'track' splits (or lack of them) already are.
joquarky
In my experience, it's the highest point you can reach before you have to deal with politics on a daily basis.
mlrtime
The equivalent in IB (Investment Banking) is VP (Vice President)
Everyone is expected to be a VP, if not you move out. But you can stay VP forever.
rcarr
This does remind me somewhat of military command structures with L1-L5 being enlisted ranks and L6-L10 either being NCO or Commissioned depending on your view of how much gatekeeping is involved.
jjmarr
Western militaries have a parallel commissioned officer and enlisted command structure where an O1 (junior officer) is technically senior to an E9 (senior enlisted NCO) and can order them around.
The idea is that command requires a separate set of skills and that experience needs to start early to have senior officers in their 50s.
In practice, junior officers are "advised" by senior enlisted on how to order people around and not taking that advice is a bad idea.
Kind of like how companies have managers and technical tracks where a line manager ignoring a senior technical person always blows up in their face.
locusofself
At Microsoft I would map your L6 to Principal, and L7/L8 to what we call "Partner". I'm a Principal, but I'm definitely not an 8 out of 10 yet.
palata
> Each company has their own numbers and names but it generally progresses like that.
But the big difference, I believe, is that being at the top of a ladder in one company may be completely different from being at the top in another one.
It's easy to be the CTO of a company of 2, much harder for BigTech. Even if the company of 2 has the same levels.
I have met people being very very proud of their title of CTO, and when I asked, their company had a handful of developers.
jrjeksjd8d
Titles for ICs matter for two reasons: comp, and perf reviews. At bigger companies the amount of RSUs for Staff versus Senior can be substantial. At a startup where equity is worth nothing and salaries are in a tight band anyways it doesn't make a difference.
For perf reviews your title dictates the rubric you get evaluated against, but in fact your manager is probably trying to fit a curve and then work backwards to the rubric. So they'll decide you're a 3/4 and then pick some boxes for your weakest areas to mark you down in. The realpolitik of it is that you can do the same work or more at a lower level but get paid less, depending on what you negotiate coming in, your experience, previous roles, etc.
Once you get into VP, Director, and C level they are comparable between orgs on their own kind of ladder. There's levels of responsibility for outcomes associated with being higher in the food chain. Not to say there also isn't a political aspect, but they are broadly comparable between bigger orgs.
cj
> At a startup where equity is worth nothing and salaries are in a tight band anyways it doesn't make a difference.
It doesn't make a big difference to the company, but a lot of employees want these titles for ego / resume / status / recognition. And titles are free for startups to give away, so many do.
bombolo
[dead]
jghn
They matter within a company for the reasons you cite. They mostly don't matter between companies however.
adamwk
You don’t think companies look at your past titles when you apply for a job?
LgWoodenBadger
Titles are what “salary comparisons” go by when HR “compares” compensation between employees and “competition.”
What else would they be able to use?
jjfoooo4
Why do you think that? Senior, staff, principle levels are pretty standard across the industry, even if some companies call them different things
hiAndrewQuinn
Your job title encompasses the highest-order bits about who you are, professionally. The value is much more between organizations than within a single one.
If you plan to stay at one place for a long time, it's much less important. You have a chance to figure out how things 'really' work in practice. I know a guy who is a senior architect, and everyone refers to him as that at his company, but his actual on-paper title is something like "project technical lead". It's just not very important if you are going to stay there for 20 or 30 years and chase deep breathing metis.
I don't have the same career outlook, so my job title is important to me. I actively negotiate for it. My own title is "senior DevSecOps engineer". Criticism of the acronym notwithstanding, this paints an instantly legible set of competencies around what I do best, what I do adequately, and what you probably would get better value for money paying someone else for. I'm probably pretty good at vulnerability management and securing CI/CD pipelines. Optimizing weights on our anti-spam logistic classifier is probably not the kind of thing I can do well. Etc., etc.
raw_anon_1111
Titles mean even less across organizations. Any interviewer worth their salt is going to hire you and level you based on how they ascertain the level of scope , impact and dealing with ambiguity you dealt with.
You can be a “CTO” of your little 5 person company - you might be leveled as an mid level software engineer at BigTech
Balgair
Rant:
I was a systems engineer for a while there.
But not a pure S/W one. Like an actual engineer with nuts and bolts and pneumatics and amps and bolts and the like. That was the title at many many companies, it was a pretty rigid one too, despite the job function being quite jack of all trades.
But then tech decided that they wanted to use Systems Engineer too. The reasons weren't bad, I guess.
But then trying to find a job in my version of the role was near impossible on any job site.
Unix this, Windows that. Sure, I used Unix systems for my job too, little servers for controlling some mechanical systems. Not like huge racks that served up billions of requests.
And then I'd get the job spam too, as I matched some keyword threshold for the S/W type systems engineer. Always a entry level role through.
Gah! Why couldn't S/W take the title of Unix Server Engineer, or Python Integration Engineer or something just a tad more specific and not bleeding all over my discipline?
Okay, whew, rant over
convolvatron
this is not at all restricted to your case. try 'distributed system engineer' or even 'software engineer'. for the latter, one is an engineer of software, and the other is one that engineers with software. both perfectly valid jobs. it doesn't help that the interviews for the latter adopt the questions and expectations of the former, even though they are different jobs.
its entirely possible to go through the software engineer hiring pipeline, and end up in a situation where the organization and the new employee have a fundamental disagreement about the slate of work.
somehow in the giant waterfall of money, our ability to even talk meaningfully about our work to each other got lost
qsort
Titles make no sense whatsoever, you're correct, but in nearly all organizations there's a split between IC track and manager track, so the argument the OP is making is debatable but it's not absurd on its face.
Scarblac
Same for "programmer", "software developer", "software engineer", and so on. People insist that there's a real difference even when I have been all those things and there was no difference.
yodsanklai
Within a given company, I think these roles are well-defined. In a big tech company, a principal engineer will influence decisions at a much higher level then a senior whose isn't visible outside his team. And an engineering manager support, evaluate, represent the team, and help with goal alignements.
nixon_why69
Maximally cynical take, tongue somewhat in cheek:
If we measure principal engineers by "cross team force multiplier impact and its visibility to management" (second part being key), what kind of behaviors do we incentivize? Are there, possibly, bunches of mid-level and senior engineers dealing with extra hassles to demonstrate this impact?
jpgvm
Sort of?
My journey up from Senior/Staff was mostly on the back of proposing and then leading cross-functional projects.
Which means I was doing Principal work before being granted the title. To be honest it was (and remains) a huge amount of work and I wouldn't continue doing it if the recognition and compensation hadn't been forthcoming in the following perf reviews.
If you are doing this stuff and aren't moving up where you are then you should be going somewhere else as that is probably a very exploitive work relationship.
etothet
If you are reading this and you are thinking you want to become an engineering manager, I urge you to think long term what you want that to look like. I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role.
And, as you move up to Director and beyond, those higher often have much less to do with actual engineering than tasks that sort of surround the world of engineering - lots of organizing information and attending meetings.
I've seen too many developers who though they wanted to manage become victim to the Peter Principle [1].
There is nothing wrong with staying a developer, even if you're not "moving up" to some idealized title. If you like the work and you can tolerate the place you work, you're probably ahead of most people in our field.
kubb
On the contrary, my manager doesn't do much outside of the perf evaluation season, and takes home a higher salary than me. He also gets to take credit for pretty much everything that his team does, despite not contributing to it much. Sounds like a fairly easy job most of the time.
keeda
Here's how I see it: Ideally a manager / reportee relationship is a symbiotic relationship. A manager becomes more successful by making their reportees more successful, and both roles grow together. And repeating this across teams, the whole company grows as well.
There's a lot of nuance but here's a simplistic overview: a manager tries to land a big project for their team, which lets the team stretch their abilities and grow, which over multiple successful deliveries results in promotions / raises for everyone involved AND the cachet to ask for bigger projects (and more headcount!)
The manager's role is the hustling and jockeying in landing the project, ensuring their team is executing and getting any mentorship needed (directly or indirectly) and protecting them from disruptions ("shit umbrella") -- which includes managing everything around the team including stakeholders and dependencies and escalations -- and then making the case for promotions / raises / PIPs based on their performance.
I've never been a manager, but having been involved in all these aspects, I can tell you none of this is easy. All of these can get very contentious, even in the best-run of companies; in the rest, a lot of pathologies spring up (like politics and empire-building) that cause even more nastiness.
So it may seem like they're taking credit for your work, but that's literally part of the arrangement, and it's only unfair if you're not seeing any upside. If you feel that way, this is 100% something you should bring up (very tactfully!) in a 1:1 or (even more tactfully!!!) a skip-level.
InfiniteRand
I think a good manager should also be a cushion between the higher up politics and his team, so they do perhaps get more praise than is deserved for their team's successes but they should also absorb much of the criticism for their team's failures
drdec
Until you are dealing with a difficult employee or struggling with whether to put someone on a PIP or being asked to deliver things you don't have direct control over or dealing with penny-pinching edicts from above etc. etc.
AdamN
Also when the project becomes a dumpster fire and you have to save it - or go through months of justifying what path is being taken or be clear with leadership what needs to change or be fired for the failure.
JaumeGreen
Engineering Manager can be a social role with some tech aspects.
You attend meetings, negotiate deadlines, evaluate people, navigate project minefields, take decisions or force people to take them,... and the technical aspects are quite minimised.
Depending on the company this is not an upgrade, it's a lateral move. I have people under me who earn more than me, and I agree with that.
The job it's not easy, it's different. Spending 5 hours on meetings it's easy, but exhausting. Giving credit to your people but taking the blame (which is what should be done) it's easy, but demoralising. Not having a peer group of people with whom easily socialise makes the job feels lonely, when you talk with other managers it's 99% work related, and you can't make your people like you as a person.
Most days I'd love to have a clear objective.
One of the worst is the strange feeling that you have because you've studied for a long time some skills, and worked using them, and now those are hardly used. You need to use a set of skills that you haven't trained for, and haven't used as much (depending on your personality/skillset, of course).
Being a manager is not for everyone.
undefined
cucumber3732842
No clear objectives, blame when it goes bad and no credit when it goes good sounds a lot like being an IC with a crap manager.
beernet
> I have people under me who [...]
Instant red flag. You're a manager. You are managing. There is no one "under you".
SkyPuncher
I've jumped back and forth between IC and Management. The roles are measured on completely different things. Most of IC is about through put. Most of management is about building/doing the right thing (aka making money).
Sometimes, it can look like management is doing very little because you only see the tail end of their outputs to the team.
kubb
He doesn't get much say about what thing gets done. He's just kind of there.
ljm
On the front of it he's not a very good manager for the team then.
Once you get to leadership you're giving credit where it's due and soaking up the loss.
etothet
Sorry to hear that. From that description this person does not sound like a good manager.
kubb
I've had worse!
zhivota
A lot of people think this until they become managers and discover all the bullshit they have to deal with from above and below. You're literally something of a human shock absorber, and in the analogy when the road is smooth there's not much to it, but when things get bumpy, you're the one taking the hits.
8note
if you arent hearing from them when you dont need to, theyre doing a good job, and if you arent being pulled into random junk, theyre doing their job
their role is to make sure the team can execute had the fastest best velocity.
usually as a shit umbrella
tombert
In my experience, I kind of think that The Dilbert Principle [1] holds more than the Peter Principle.
With the Peter Principle, it's implied that they were good at their previous job and are bad at their current one, but having had to debug awful, awful, broken code at Apple by people who had been promoted into managers or directors, I'm not convinced that they were ever good at their job. I remember some code we had in iTunes, my manager would say "that was written by X. Don't worry, he's been safely promoted out of danger".
I think management, especially higher management, is often about how much you can make it look like you're doing important things. It requires zero effort or skill to book a dozen meetings in Outlook or Google Calendar, and it only requires a fairly small amount of effort to make slide shows to talk about how "important" the work is that you're doing. Instead of getting good at engineering and writing good software, it's much easier and more effective to tell people how good at engineering and writing software you are instead. Most of the higher-level managers are pretty removed from the low-level work so when promotions come along, they remember the person who kept booking all the meetings with them and assume what they were doing is important.
I'm admittedly more than a little cynical about this stuff; I have been routinely negative about big corporations (and particularly Apple) and I think that the Peter Principle is assuming a level of rationality and intelligence that I really haven't observed.
[1] https://en.wikipedia.org/wiki/Dilbert_principle#Definition Not saying I'm a huge fan of Scott Adams, but I don't know any other name for this principle.
crims0n
Everybody wants a manager that has engineering experience, but nobody wants to be that manager.
_blk
I'm a freelance interim EM and I do it for the same reason the article explains: I genuinely enjoy it.
I love engineers and I love tech. I still code daily but I'm not the guy that delivers at the pace of some of the amazing engineers that I had the privilege to work with. I love putting others ahead of myself wherever I can and it's never cost me anything, so I'm not afraid to do it again. I love telling the engineers how what they do actually matters because they're too focused on the work to sometimes see why changing goals doesn't mean their work and efforts were wasted and I also love shielding them from the corporate mess upstairs (that I somewhat masochistically don't even dread being part of)...
So, yeah, I really love my job and if one of my guys (or gals) wants that too, the more of a joy it is to me to mentor them into that process.
zhivota
I didn't know freelance interim em was a thing, interesting role.
8note
ive had that manager a few times. its quite nice, but also, parents do a better job than non-parents
madeofpalk
> I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role
As an IC, this is baffling to me because that seems like the biggest and most obvious part of the job. I never want to be approving people's leave requests or telling someone they're being a jerk on slack.
alephnerd
This.
EM is a terminal position that does not own the product roadmap (Product Management) nor the underlying implementation (Staff/Principal Engineers).
They primarily own delivery and execution because orgs can't be bothered to hire program managers anymore.
If you are great at managing upwards and ensuring delivery by hook or by crook, you will make a great EM. But the next jump after EM is extremely difficult because you are competing with Principal Engineers and technical-minded PMs making a lateral move and cofounders who are being managed out by the board; and dealing with micromanaging CTOs or CPTOs.
Illniyar
Are you saying principal engineers and tech minded PMs make lateral moves into director level manager without going through being entry level EMs first?
I've never heard of something like that. Usually the requirement for being director level manager of engineers is to at least have managed people as an EM for several years before.
lukevp
At my company it’s lateral.
Lead -> EM
Sr. Lead -> Sr. EM
Principal -> Director
Sr. Principal -> Sr. Director
The pay is aligned with the level whether or not you’re a people leader. To your point though, it may be difficult to go from Principal to Director. I see the lateral moves happen more at the Lead/Sr. Lead levels. They might do a Principal to a Sr. Manager as a trial period with the expectation that you’d be Director after a short time if you perform well. I’ve definitely seen directors become principals as well, so it goes both ways.
sbinnee
Learned something new, about the Peter principle. Thank you. I don't know if I should be surprised that it was published in 1969, and it seems that the principle still holds.
ecshafer
There is a major gap in this analysis by not controlling for industry or companies. Engineering Manager is a very generic title, so this is going to get Start Ups, Big Tech, Little Tech, Enterprise, Contract Shops, etc. Staff Engineer is very uncommon in Enterprise or Contract shops, there you typically see SWE 1/2/3 -> Tech Lead -> Architect. Most Tech companies I think have more of a SWE 1/2/3 -> Staff Engineer -> Principal.
The other part is that Engineering Manager is a terminal position, I've known a few people who were manager for 20 years without ever going to Director / Exec whatever, its just a competitive jump and mathematically most will never go up. This is ALSO true for Senior -> Staff and Principle though. But Engineering Manager positions often have more of an upside with bonuses / incentives than Engineers get.
Finally it is ultimately a career change, and that should be the primary factor to consider.
alephnerd
> Engineering Manager positions often have more of an upside with bonuses / incentives than Engineers get
Not really.
Staff Eng and above will end up making similar to an EM including bonuses and has much more job mobility. You have to remember that most EM roles only open up once you hit Staff, so you are basically taking much more responsibility and longer hours for a marginal salary impact.
Engineering Manager jobs are hard to come by and your job security is actually less than an individual contributor, because even if an initiative was delivered late due to no fault of your own, if sales is braying for blood in order to protect themselves after failing to meet quota, it's the EM's head that is offered on a silver platter.
willahmad
> Staff Eng .... has much more job mobility
Not really.
Above Staff and Staff+ companies are usually looking for expertise in domain, in addition to cross org leadership. Unless you want to get hired with Sr title.
Management is different though, you have highly transferrable skillset, managing people, up and down.
janalsncm
> you have highly transferrable skillset
Of course this also means the pool of people who can do your job or quickly learn it includes essentially every other EM.
And many of those people are looking for jobs now.
For an IC, no one can become an expert in Rust overnight.
alephnerd
> Management is different though, you have highly transferrable skillset, managing people, up and down
Most tech companies are not hiring an EM without relevant domain experience. "People Management" is a table stakes skill in 2026 and Staff/Principal Engineers and Product Managers largely offer that as well as technical or product insight.
Additionally, it's something that can be cultivated in-house and is why internal promotions to EM tend to be preferred unless a director, principal engineer, or PM is getting their friend a job (which happens fairly often).
GlibMonkeyDeath
The arguments:
* It's a bad time to move away from tech
As a manager your role isn't to be the "best technical person" anyway. You still need to understand fast-changing capabilities of course. But you are managing people now, and the required skills are different. See below.
* The ladder is very competitive
It's always competitive, and in my experience it was the exact opposite - there were far fewer VP-level technical roles than VP people managers.
* The pay is lower (for senior managers vs. senior technical track)
Again, this is the opposite of my experience (besides at the first-line manager level, where pay was comparable.) Where I worked managers could quickly get paid more with more responsibility. I always thought it was because managing people is actually a lot less fun (at least for me it was.)
The biggest reason not to become a manager is because _it is a completely different job_. Although managers need to be technically competent, management skills are much more about people (and politics.) If that isn't your jam, then don't become a manager.
alephnerd
I think you underestimate the job mobility that is lost when you transition from being an individual contributor into someone on the management track.
The reality is, there are very few EM and above jobs, and job security is tough - if I have to choose between firing an EM or a SWE, I'd fire the EM first because I can always find another replacement or split their responsibilities across multiple individual contributors and the PM.
If an EM is laid off or fired, it's extremely difficult to find another role, and it truly is a terminal position. Why would I hire a laid off or fired EM or Director when I can promote internally or hire someone from within my network?
Additionally, back when I was an SE, if we had a deal go bad in order to protect our ass we'd blame the EM so that we can have a head on the platter to hand our CRO, unlike a seasoned SWE who can push back and argue PM requirements were unclear and PM can argue that sales+product was aligned.
ahtihn
> if I have to choose between firing an EM or a SWE
When does this choice ever come up?
My experience is that most engineers are seen as interchangeable while most EMs aren't.
Only time I've seen EMs fired for economic reasons is when a larger amount of engineers were also laid off.
Atreiden
Anecdotally, pretty often. Whenever there is an engineering org failure, whether it be missed deadlines, unreliable software, missed KPIs, etc, there is no such thing as a truly blameless org. Somebody will be accountable in the eyes of leadership, and that boils down to this very choice.
Was it the devs fault for shipping code with a disastrous edge case, or the EMs fault for over- allocating work, resulting in less-refined code and a minimal review process that let the defect slip into production? Just as an example.
alephnerd
> When does this choice ever come up
Fairly often, but we usually manage them out so that line-level engineers don't get paranoid and jump ship.
When an EM is suddenly shifted to work on another project, or all you ICs are suddenly talking to other managers or staffed on other projects, that's us as organizations managing out the malcontent and messaging to them that their time is up.
GlibMonkeyDeath
I agree at the first-line manager level (which this article is about), it's tough to get hired from outside, so getting the same position somewhere else after a layoff will be a tough job search.
My comment was more on the next levels - there seemed to be about as many high-level technical roles as managers (paid similarly) where I worked in biotech (that might be a different situation for software-only companies.) And there were more Directors/VP's than Principals/Fellows for sure. So at some point the "ladder width" crosses over.
And if you get laid off as a senior IC, good luck getting hired into another IC position. Age discrimination is real. The robust network is a must for anyone, manager or IC, in this case.
alephnerd
> My comment was more on the next levels - there seemed to be about as many high-level technical roles as managers (paid similarly) where I worked in biotech (that might be a different situation for software-only companies.) And there were more Directors/VP's than Principals/Fellows for sure. So at some point the "ladder width" crosses over.
Yea. Biotech is different. The equivalent of a VP for a specific formulation at a Pfizer would be a Staff or Principal Product Manager at a Salesforce.
In software, Engineering Managers have increasingly become solely people+program managers with a bit of a technical component.
EMs aren't expected to own product - that's PMs. Additonally, EMs aren't expected to own architecture - that's Principal and Distinguished Engineers. All that leaves EMs is program management.
ilc
I think you over estimate how valuable really good Principal level talent is when you have AIs that can take over for entire teams.
As an older and higher up engineer, I worry more for the youngsters than myself. I'll find a spot. I'm using AI, I'm doing things at rates that are pretty crazy.
That's all powered by decades of good decision making practice. Youngsters don't have that. They don't have the painful lessons hard earned.
undefined
jedberg
Not sure I agree (and I made the jump from IC to management).
Look at the parallel tracks. A VP is the same level as a distinguished engineer, roughly. To be a VP, you have to be a great manager and got lucky with a few big projects.
To be a DE, you basically have to be famous within the industry. And when I look at a large tech company, while there aren't a lot of VPs, usually the number of DEs is countable on one hand (or maybe two).
They are very different skill sets. You shouldn't choose your role based on money or career progression, you should choose based on what you love to do, because especially in this world of AI replacing all the "boring" work, the only people who will be left will be the ones passionate about what they are doing.
saghm
> The pace of change in the last year has been completely crazy, and it’s not stopping.
> But even if you don’t give in to the constant FOMO - it’s impossible to argue that the way we worked hasn’t changed. Almost every part of our work looks different, and will continue to evolve.
My experience is anecdotal, but this seems to be overblown. I'd say that almost every part of my work looks pretty identical to how it did a few years ago, and that the changes are relatively small in scope so far. Most of the arguments I've heard from those who advocate adopting AI tools are that the rate at which the tools are improving is exponential (or super-exponential, or whatever), which is a prediction about how it will change rather a claim that it has already reached a point that it's necessary. I don't pretend to have any expertise that lets me evaluate those predictions better than anyone else, but unless I happen to be a severe outlier, it seems like gross hyperbole to claim that every part of our work has already changed.
dirkc
That comment made me wonder how long the person advised have spent working in tech, I'd wager that it's < 5 years.
I'm not saying that to be snide. When you come from a academic CS setting like university, there are so many new things to learn in industry that after 5 years you could still be completely unfamiliar with a lot of things.
hnfong
I don't understand what you mean by "prediction". Are you simply saying you're not using the AI tools out there and making a claim that they don't boost productivity at all?
Otherwise, even if the existing tools are overhyped (eg. instead of "exponential" gains, they are simply incrementally better), you're still gaining productivity by adopting them. And if they change your workflow, then "almost every part of our work looks different, and will continue to evolve" would be true.
saghm
> And if they change your workflow, then "almost every part of our work looks different, and will continue to evolve" would be true.
No, if almost every part of my work looks the same except for a few specific places that are changed, then the claim that almost every part of my work looks different is false.
tomgp
Yes. Also there's a weird thing going on where the claims are simultaneously that these tools are super easy to use and everyone and their dog is going to be using them to create awesome software and that it's only going to get easier to do so BUT ALSO that you have to immediately start using them or you'll get left behind. Why should we start now if they're going to be more powerful and more accesible in a years time? seems like the effort working with the imperfect exising version will be wasted.
generic92034
It is just so that the CEO can claim they are an "AI first" company and the shareholders might believe that the company is not being eaten by AI but profits from it. Check the claims of the software vendors whose stocks have fallen by some 30% in the last few months, without any reason in the fundamentals.
DaedalusII
for the same reason people had to start using microsoft excel when windows 95 came out
yes you could wait a few years as an accountant until quickbooks/intuit/whatever was built out, but arguably being good at spreadsheets+basic VBA between 1995 and 2010 paid about as well as being a python dev these days
zkmon
Not quite. In most companies managers are seen as 'inner circle' people while technologists are just workers. Managers get exposed to a lot more comms, giving more visibility and get ability to act like a smart person purely because they have more emails and get into more calls than the others. They not only get more power, but also get more info.
tamimio
I agree, and they have more power because they have more info and are given more visibility, and because they lack the deep technical knowledge in xyz, they compensate it with all sort of office politics.
jollyllama
If you already don't know that though, are you really cut out to be a manager? You're joining the company "mafia", with all that implies, for good or ill.
raw_anon_1111
Line level managers are the most easily replaceable and in my experience powerless people in an organization. When I was being hired as an IC in product companies before to lead major initiatives. One of my requirements was to report to either the director or CTO (startup). Even after the startup grew and they hired a EM, the CTO carved out a position for me so I wouldn’t report to an EM.
siliconc0w
My experience is that the 'separate but equal' dual engineering track is largely a myth and that if you want advancement, the manager track is a much more viable track. Even with some of the recent flattening, there are still far more higher level roles for management than ICs. They are also given far more visibility and access inside the company which is extremely valuable in a large org. It also seems a good choice if you're not very good - I've seen bad managers hang around far longer than bad engineers.
mgraczyk
The part about pay is wrong, it's not comparing apples to apples.
I've been a staff engineer at Google and other companies, I have been an EM and a very senior IC at big and small companies.
If you're a very good IC, you can make a lot at a small number of good companies
If you're a relatively worse manager you can make a similar amount at many other companies
So the decision tree I would use is (focusing exclusively on compensation), if you're a very good IC, go somewhere willing to pay you >1M/year. If you can't get that you should be a manager
UK-Al05
The document is comparing salaries of staff engineers, and EM's. In my experience staff engineer positions are even rarer then EM positions.
makapuf
sure, as long as we're talking about 110 to 170k$ non-managing, technical roles in EU, I'd like to see a full eclipse soon (both exist but I think the latter could be easier to find)
alephnerd
> In my experience staff engineer positions are even rarer then EM positions.
Where do you work?!? If you are in Western Europe then the blogpost is irrelevant for you. The Western European market is weird.
DDerTyp
Can you elaborate more about this? Why is it irrelevant in Western Europe?
alephnerd
Western Europe has a very different hiring market for SWEs due to how traditional industries like financial services, media, law, government, pharma, chemicals, and automotive are overrepresented.
In these kinds of organizations, software is viewed as a cost-center and as such the only way you as a SWE can protect yourself is to climb up the management chain as soon as possible.
d_burfoot
It's a bad idea to phrase advice as "Don't Do X", for most values of X that are often undertaken:
- Don't move to Detroit
- Don't go into academia
- Don't use dating apps
- Don't buy Google stock
It's most obvious for the last one: you should buy Google (or any other) stock if you think it's underpriced and sell it if you think it's overpriced. But even for the other advice, a kind of Efficient Market Hypothesis holds. If there were a massive exodus of people from academia, causing universities to increase salaries and reduce administrative burdens, going into academia might be great for the right people. For many people Detroit is a terrible city, but I know a guy who worked for the Tigers, and bought a large house for a small amount of money, and did a lovely job renovating it, so Detroit worked well for him.
Life is all about finding underpriced value: options that you will appreciate more than others, for whatever reason.
ZitchDog
Saying that becoming an EM is "moving away from tech" is crazy. As an EM you will be steeped in tech, just as you would be as an IC. It just may not be the tech you want to be steeped in. Again, same as an IC. In either case, unless you are working in AI, you will need to "play" with things like OpenClaw in your spare time.
The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.
CoffeeOnWrite
> The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.
This is true, but our job was getting kind of boring anyway. Time to lead, not manage. We should be having just as much fun as the ICs, and the best I know are having the time of their lives.
Get the top HN stories in your inbox every day.
I cannot be alone in feeling that titles (within "tech" in particular) are almost completely arbitrary? What constitutes a "senior", "lead", "principal" and "staff" X, respectively, has so much overlap that it really depends on the organisation. I myself have been called all of those things, but have honestly not been able to tell the difference: in some cases, I have had much more responsibility as a "senior backend developer" than a "staff engineer". I have recently interviewed for a number of roles with titles like CTO, engineering manager, tech lead etc and there is so much overlap that they seem to be one and the same. Have worked at companies on three continents, in organisations ranging from 6 people to 10k+, so have seen a few titles.