Don't become an engineering manager(newsletter.manager.dev)
newsletter.manager.dev
Don't become an engineering manager
https://newsletter.manager.dev/p/dont-become-an-engineering-manager
280 comments
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.
> 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.
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.
> 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.
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.
Interesting, you've got it absolutely the wrong way around.
> Interesting, you've got it absolutely the wrong way around.
Maybe. That's why you need to put your scope on the resume :)
I had a CTO title 15 years ago. The complexity of what we were building was a joke compared to what I own now as a lowly "tech lead manager". And in fact back then I wouldn't even be able to comprehend how complex things can get.
Maybe. That's why you need to put your scope on the resume :)
I had a CTO title 15 years ago. The complexity of what we were building was a joke compared to what I own now as a lowly "tech lead manager". And in fact back then I wouldn't even be able to comprehend how complex things can get.
> That's why you need to put your scope
The problem is, "scope" is often equated to "how many people worked in my empire" rather than "how much business value did my work X generate".
The two things are vastly different, and I have seen the distinction/oversimplification play out over and over in my own career as well as many others around me.
As an extreme on the "individual technical expert side", there are things out there that can pretty much only be accomplished with a few people around the world who possess the dedicated expertise. These results can't be replicated by a cobbled together team of 10 or 100 people even though the latter sounds more impressive for "scope".
Some organizations do a decent job of recognizing these different "archetypes", many don't.
The problem is, "scope" is often equated to "how many people worked in my empire" rather than "how much business value did my work X generate".
The two things are vastly different, and I have seen the distinction/oversimplification play out over and over in my own career as well as many others around me.
As an extreme on the "individual technical expert side", there are things out there that can pretty much only be accomplished with a few people around the world who possess the dedicated expertise. These results can't be replicated by a cobbled together team of 10 or 100 people even though the latter sounds more impressive for "scope".
Some organizations do a decent job of recognizing these different "archetypes", many don't.
I agree. What counts as a positive signal for "scope" really very much depends what you're hiring for.
When looking for a manager type, people under management are a decent proxy. When looking for the world's greatest postgres optimization expert, some version of queries-per-second is prob the metric you want.
Or realistically if I needed the world's greatest Postgres expert (and could afford them), I would go talk to experts in the field and ask "Who's the best postgres person you know?" and work from there. At that point your resume is but a formality.
When looking for a manager type, people under management are a decent proxy. When looking for the world's greatest postgres optimization expert, some version of queries-per-second is prob the metric you want.
Or realistically if I needed the world's greatest Postgres expert (and could afford them), I would go talk to experts in the field and ask "Who's the best postgres person you know?" and work from there. At that point your resume is but a formality.
That may be your anecdote but CTO at a 30-50 person scale up would typically have much more management/accounting/signature/high-stake conversation/... experience than a senior developer at google.
But that's nothing to do with the comparison he made, which was "at 3-person startup"
Yes. Which is why it's important to put scope on your resume.
I can't know you ran a 30 person scale up unless you tell me. It doesn't have to be in those words exactly, usually it's tied to ARR or rounds raised or something you can easily talk about that translates across companies.
I've seen resumes with titles like "Lead Engineer" who under that title put something like "Hired 45+ people to run <huge systems> at <company you've heard of>". That person has more scope than the 30-people CTO in your example :)
PS: 30 people isn't even that many for a whole company. That's a Series A startup with early signs of product-market-fit. It's common to see a ratio of 10 employees for every 1 engineer in the company.
I can't know you ran a 30 person scale up unless you tell me. It doesn't have to be in those words exactly, usually it's tied to ARR or rounds raised or something you can easily talk about that translates across companies.
I've seen resumes with titles like "Lead Engineer" who under that title put something like "Hired 45+ people to run <huge systems> at <company you've heard of>". That person has more scope than the 30-people CTO in your example :)
PS: 30 people isn't even that many for a whole company. That's a Series A startup with early signs of product-market-fit. It's common to see a ratio of 10 employees for every 1 engineer in the company.
An unverifiable line item on a resume gives you real insight on an individual's experience and skills? I think your system is flawed.
It gives me more insight than a blank resume with just job titles.
The rest we can hash out in interviews, reference checks, and reaching out to mutual network connections at higher levels. Nobody gets hired just off their resume.
That is to say: All line items are verifiable if we care enough. Tech is small :)
The rest we can hash out in interviews, reference checks, and reaching out to mutual network connections at higher levels. Nobody gets hired just off their resume.
That is to say: All line items are verifiable if we care enough. Tech is small :)
When you swap between 9 hats, you don’t get meaningful experience at any of those roles.
Instead you become a generalist which is only really needed at tiny organizations.
Instead you become a generalist which is only really needed at tiny organizations.
Big organizations need generalists too.
Generalist means something very different for big orgs.
At FANG size companies have people to setup 401k and health insurance, tiny startups need 1 of 3 people to figure that out even if it just means finding a company to outsource such things it still needs to happen. Payroll doesn’t need to be a complex system but taxes must be paid etc.
At FANG size companies have people to setup 401k and health insurance, tiny startups need 1 of 3 people to figure that out even if it just means finding a company to outsource such things it still needs to happen. Payroll doesn’t need to be a complex system but taxes must be paid etc.
I would say I look at it from a different angle, big companies can afford specialists. Startups cannot afford specialized employee for database administration or setting up 401k.
But big companies would definitely love to have to pay a single salary for someone who does 401k and when this job is done administrates databases then in between reviews tweets searching for mentions of the company. Exaggerated example but I hope clear.
That already shows up with everything getting „Ops” obviously DevOps but I already have seen DataOps, SalesOps and MarketingOps.
But big companies would definitely love to have to pay a single salary for someone who does 401k and when this job is done administrates databases then in between reviews tweets searching for mentions of the company. Exaggerated example but I hope clear.
That already shows up with everything getting „Ops” obviously DevOps but I already have seen DataOps, SalesOps and MarketingOps.
That shows an ability to figure out what needs to be done and do it, regardless of whether it fits the formal job description. That can be an invaluable skill in an organization of any size.
It's the story of foxes and hedgehogs... Both have a time and place. Sometimes you need people who can aggressively put out fires, and sometimes you need people with deep focus for the long haul, who aren't overly distracted by the heat.
It’s a valuable attitude, but not a particularly valuable skill.
Expertise gains value when it can’t be subdivided. A doctor needs to know a who lot of related skills to be a heart surgeon, it doesn’t work to split it into two less demanding roles. However two generalists can sub divide the workload of a generalist with a lot more experience because experienced generalists aren’t particularly skilled at anything.
Expertise gains value when it can’t be subdivided. A doctor needs to know a who lot of related skills to be a heart surgeon, it doesn’t work to split it into two less demanding roles. However two generalists can sub divide the workload of a generalist with a lot more experience because experienced generalists aren’t particularly skilled at anything.
Well, what do you even mean by "put your scope on the resume"? Do you mean literally "Scope: blabla" for each occupation? Or do you mean something more implicit?
> Do you mean literally "Scope: blabla" for each occupation?
No I mean
> Tell me what you did, for whom, what was the impact.
It's really that simple. Just tell me what you did at your job. What was it that you worked on. Why did it matter. Did you own a workstream (or 5), code monkey all day, own a critical service, play code janitor, ... what did you do?
No I mean
> Tell me what you did, for whom, what was the impact.
It's really that simple. Just tell me what you did at your job. What was it that you worked on. Why did it matter. Did you own a workstream (or 5), code monkey all day, own a critical service, play code janitor, ... what did you do?
Ah OK, gotcha, thanks.
This is what I did in some interviews already. But maybe I can adapt my CV a little as well.
This is what I did in some interviews already. But maybe I can adapt my CV a little as well.
There's a lot of cogs at big companies, but the impact of the entire company is huge. Startups usually have small impact. Usually at these big companies there's quite a few atlases holding the entire world up.
Sure also in big companies there are plenty of places for low performers to survive by owning some very small and rigid scope that doesn’t require any real end-to-end thinking.
In my experience distribution of engineer quality is even across companies, countries, ages and any other dimension we can come up. Certain big scale skills can really only be practiced at honed at large tech companies, but it’s always a small minority that actually make those things happen. Resume alone can be an extremely misleading signal.
In my experience distribution of engineer quality is even across companies, countries, ages and any other dimension we can come up. Certain big scale skills can really only be practiced at honed at large tech companies, but it’s always a small minority that actually make those things happen. Resume alone can be an extremely misleading signal.
The engineer at the startup may have a broad scope of responsibility and ownership, but also might be working on relatively small systems that have not needed to scale yet.
I think that engineering at a large organisation and engineering at a startup are two completely different disciplines with very little crossover.
[deleted]
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.
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.
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.
"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.
A few teams have a "lead" role, but its mostly ceremonial.
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
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
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.
>> 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?
Failed to design Quantum Lattice Bloom Cascade algorithm in 5 minutes?
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.
For a good interviewer these people are obvious even without any coding tests.
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:
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.
- 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.
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.
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.
Amazon had the concept of terminal role (SDE2, but I’ve heard it has changed) long before facebook existed.
In my experience a lot of tech companies, at least in the Bay Area, have all copied this system.
I believe L5 was Google's terminal role at one point (over a decade ago) - not sure if it's changed since then.
It became L4 ~5-7 years ago, but who knows these days.
Terminal roles are definitely not a Facebook concept originally … Microsoft has had it for at least 20 years.
I'm guessing the terminal role is the 64 Senior? That's nearly everyone on my team. Someone has to retire or die to get a shot at Principal.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
They matter within a company for the reasons you cite. They mostly don't matter between companies however.
You don’t think companies look at your past titles when you apply for a job?
They may, but the amount of information they're getting is low.
As a hiring manager I'll look at progression of titles *within a company*. This shows a track record of upward mobility. But if they go from "senior" in one company to "principal" in another, I find it meaningless.
As a hiring manager I'll look at progression of titles *within a company*. This shows a track record of upward mobility. But if they go from "senior" in one company to "principal" in another, I find it meaningless.
> As a hiring manager I'll look at progression of titles within a company. This shows a track record of upward mobility.
That's quite shallow for those who are 'Member of Technical Staff' which does not have this which is why titles are meaningless for experienced candidates.
Someone can give themselves that title, all because they know the founders; thus it can be exploited.
So instead, I get the candidate to exactly explain to me what did they actually build / do and how much money did they make / save the organization and it must be in the millions to qualify or did they build side-projects that contributed to this or not.
In this era, "titles" aren't enough and you need verifiable proof of work with monetary returns in the millions and I favour those who just build things that make money without asking permission from a manager.
That's quite shallow for those who are 'Member of Technical Staff' which does not have this which is why titles are meaningless for experienced candidates.
Someone can give themselves that title, all because they know the founders; thus it can be exploited.
So instead, I get the candidate to exactly explain to me what did they actually build / do and how much money did they make / save the organization and it must be in the millions to qualify or did they build side-projects that contributed to this or not.
In this era, "titles" aren't enough and you need verifiable proof of work with monetary returns in the millions and I favour those who just build things that make money without asking permission from a manager.
> In this era, "titles" aren't enough and you need verifiable proof of work with monetary returns in the millions and I favour those who just build things that make money without asking permission from a manager.
While I like this approach personally, it's worth noting that lots of companies will fire people like you say you want, particularly if their manager is threatened by them (or they're difficult to work with etc).
While I like this approach personally, it's worth noting that lots of companies will fire people like you say you want, particularly if their manager is threatened by them (or they're difficult to work with etc).
The title only so matters to the extent the company is a known entity.
The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.
The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.
Titles are what “salary comparisons” go by when HR “compares” compensation between employees and “competition.”
What else would they be able to use?
What else would they be able to use?
I was promoted to senior software engineer three times in my early career. They just tossed out the title as a freebee more-or-less, and the hiring companies told me I was too young/inexperienced for it.
There seems to be an understanding that happens, which means they ignore it.
There seems to be an understanding that happens, which means they ignore it.
> What else would they be able to use?
I tell them what my range is. If they don't want to meet my range, then I tell them to GTFO.
Isn't that what everyone does?
I tell them what my range is. If they don't want to meet my range, then I tell them to GTFO.
Isn't that what everyone does?
Why do you think that? Senior, staff, principle levels are pretty standard across the industry, even if some companies call them different things
This is definitely not true. It’s all dependent on the company size.
I work in cloud consulting (specialize in app dev).
I worked at AWS ProServe (full blue badge RSU earning employee) before working for a much smaller company. I’ve seen the leveling guidelines for both.
An L5 (mid level) at AWS had to be a subject matter expert in at least one area (development, DevOps, security, etc) and be able to lead a “workstream” of a larger project including dealing with a customer or a smaller project by themselves. That maps to a “Senior Architect” at my current company.
A senior (L6) at AWS should be able to handle larger projects with multiple workstreams and deal with more ambiguity. That maps to a staff at my current company (current position)
An L7 is usually over a practice and/or handling multiple large implementations and more involved with strategy. Imagine someone (who hypothetically - they don’t need outside consultants) was working with Netflix.
That maps to a “Senior Staff” at our company.
You might ask what about lower levels in consulting? I never work with them. The bilingual cloud architects/senior cloud architects work with them. We don’t hire anything lower than that in the US.
I work in cloud consulting (specialize in app dev).
I worked at AWS ProServe (full blue badge RSU earning employee) before working for a much smaller company. I’ve seen the leveling guidelines for both.
An L5 (mid level) at AWS had to be a subject matter expert in at least one area (development, DevOps, security, etc) and be able to lead a “workstream” of a larger project including dealing with a customer or a smaller project by themselves. That maps to a “Senior Architect” at my current company.
A senior (L6) at AWS should be able to handle larger projects with multiple workstreams and deal with more ambiguity. That maps to a staff at my current company (current position)
An L7 is usually over a practice and/or handling multiple large implementations and more involved with strategy. Imagine someone (who hypothetically - they don’t need outside consultants) was working with Netflix.
That maps to a “Senior Staff” at our company.
You might ask what about lower levels in consulting? I never work with them. The bilingual cloud architects/senior cloud architects work with them. We don’t hire anything lower than that in the US.
I'm guessing you've only worked at very large companies, specifically tech companies then?
I've worked at pretty much every size company imaginable.As the top post pointed out, these titles are meaningless across smaller companies. I've been at startups where nobody had titles at all, I've small companies where anyone remotely senior as a principal. I've also worked at large non-tech companies with only 3 levels for IC, after that you were expected to transition to management.
Large, tech companies have some degree they can be compared but what these titles mean from company to company is pretty meaningless.
I've worked at pretty much every size company imaginable.As the top post pointed out, these titles are meaningless across smaller companies. I've been at startups where nobody had titles at all, I've small companies where anyone remotely senior as a principal. I've also worked at large non-tech companies with only 3 levels for IC, after that you were expected to transition to management.
Large, tech companies have some degree they can be compared but what these titles mean from company to company is pretty meaningless.
They're somewhat standardized in Big Tech in that people have worked out how to map titles across these companies. But that accounts for a very small fraction of the total industry.
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.
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.
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
You can be a “CTO” of your little 5 person company - you might be leveled as an mid level software engineer at BigTech
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
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
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
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
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.
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.
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.
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?
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?
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.
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.
It sounds like you were one of the actual Principal Engineers, then. In my experience, there are some who had presumably done some of that in the past but now had to maintain their position by generating "cross-team impact" which was mostly just a PITA to actual practitioners.
One case in particular, there was a re-org and the new org lacked principals but we had a common vision and a bunch of pieces in place. We needed a new vision that was led by the new principal, for obvious reasons. Whole thing was set back by a couple years while this was figured out. The existing, well-functioning pieces (with lots of users) were shipped to India teams for maintenance while the org slowly figured out facsimile pieces.
One case in particular, there was a re-org and the new org lacked principals but we had a common vision and a bunch of pieces in place. We needed a new vision that was led by the new principal, for obvious reasons. Whole thing was set back by a couple years while this was figured out. The existing, well-functioning pieces (with lots of users) were shipped to India teams for maintenance while the org slowly figured out facsimile pieces.
> I cannot be alone in feeling that titles (within "tech" in particular) are almost completely arbitrary?
I remember that 10 years or so ago, an E5 in Google is considered a pretty prestigious position. In Amazon, L6 is such a high achievement that the entire India site had one L6 for more than 300 engineers. But somehow things started to change. Everyone expected herself to get promoted every couple of years. There was a joke in Amazon along the line of L8 is the new L7.
My guess is that two factors came to play. One is that Meta (and then the Facebook) started to promote people really fast, so other companies followed. Also managers gradually treated promotion as a tool to retain the people they need. Once that's the incentive, a long title ladder becomes a natural choice.
I remember that 10 years or so ago, an E5 in Google is considered a pretty prestigious position. In Amazon, L6 is such a high achievement that the entire India site had one L6 for more than 300 engineers. But somehow things started to change. Everyone expected herself to get promoted every couple of years. There was a joke in Amazon along the line of L8 is the new L7.
My guess is that two factors came to play. One is that Meta (and then the Facebook) started to promote people really fast, so other companies followed. Also managers gradually treated promotion as a tool to retain the people they need. Once that's the incentive, a long title ladder becomes a natural choice.
>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
Titles at least useful to understand the hierarchy, but roles truly mean nothing. Sometimes the adult in the room is a PO, sometimes it's EM, sometimes they are responsible for the timelines and "project stuff", sometimes it's a Senior Engineer. In some places a QA is effectively doing PO stuff.
Titles at least useful to understand the hierarchy, but roles truly mean nothing. Sometimes the adult in the room is a PO, sometimes it's EM, sometimes they are responsible for the timelines and "project stuff", sometimes it's a Senior Engineer. In some places a QA is effectively doing PO stuff.
> In some places a QA is effectively doing PO stuff.
Or your support team could wind up owning it without even knowing that they own it.
Plan for who's gonna own the product because someone will, and that task will just settle somewhere random if you don't specifically assign it.
Or your support team could wind up owning it without even knowing that they own it.
Plan for who's gonna own the product because someone will, and that task will just settle somewhere random if you don't specifically assign it.
This is exactly why we built https://www.levels.fyi
Too often people were getting down-leveled because they didn't know any better. The level comparisons we show on the homepage compare scope and responsibilities. People frequently think levels are based on compensation but compensation is the byproduct of it.
Too often people were getting down-leveled because they didn't know any better. The level comparisons we show on the homepage compare scope and responsibilities. People frequently think levels are based on compensation but compensation is the byproduct of it.
Firstly, I love levels and thanks for it.
That said, in general for any given comp package, I’d want the lowest possible level I could take and get that package. That gives more upward runway.
That said, in general for any given comp package, I’d want the lowest possible level I could take and get that package. That gives more upward runway.
At my organization you can't get a raise beyond inflation percentages unless you go up a title.
It wouldn't surprise me if it's a way of gatekeeping salaries since years of employment typically outnumber the levels of title that are achievable in one's career.
It wouldn't surprise me if it's a way of gatekeeping salaries since years of employment typically outnumber the levels of title that are achievable in one's career.
I always think of the Gervais principle when it comes to titles - that they really just exist to provide illusory advancement and to get some of the minions to lord it over some of the other minions while the folks at the top of the organization benefit.
There's a wide variance, but there's been a lot of 'title inflation' over the past decade that has more to do, I think, with giving people incentives when they don't want to stretch the equity package any further.
I just got a new job, hired as level 5 with official title Software Engineer (Mid-career) although my boss tells me I'm Chief Engineer. All the level 2 people on my team seem to be Senior Engineer or Lead Engineer.
> titles (within "tech" in particular) are almost completely arbitrary
It wasn't like that some years ago.
Senior back in the days is probably your lead / staff of today.
The problem isn't just the companies but people and their expectations. You have people crying about not being made "senior" for having 2 years of experience and the world is blown apart now.
So is every company evil or broke or the social media culture these days expecting instant feedback etc?
You used to work 10+ years as an engineer and just that and it was fine.
It wasn't like that some years ago.
Senior back in the days is probably your lead / staff of today.
The problem isn't just the companies but people and their expectations. You have people crying about not being made "senior" for having 2 years of experience and the world is blown apart now.
So is every company evil or broke or the social media culture these days expecting instant feedback etc?
You used to work 10+ years as an engineer and just that and it was fine.
It really is arbitrary; I've never really been called senior or whatever, but apparently some people with 3-5 years of experience are already called that. It feels more like politics than a proper scale.
Which is actually an issue in our industry, I think, and it's causing widely different expectations and skills in different companies. A "lead developer" for company A might be considered a medior at best at company B.
Which is actually an issue in our industry, I think, and it's causing widely different expectations and skills in different companies. A "lead developer" for company A might be considered a medior at best at company B.
Engineering titles at least have a few things that are nearly universally shared (such as actually needing to code, expecting to mentor).
Product manager titles can have completely disjoint scopes of work between organizations - in one org they might be what was once systems designer role - getting requirements and writing specs, in another they might basically be doing UI or UX (even creating pages in figma), in others they are basically project managers.
Product manager titles can have completely disjoint scopes of work between organizations - in one org they might be what was once systems designer role - getting requirements and writing specs, in another they might basically be doing UI or UX (even creating pages in figma), in others they are basically project managers.
One thing that's worth remembering is that companies - especially in Silicon Valley - use titles as a way to compare salary levels with each other.
If you are an engineering manager looking to make the case for raises for your team members one of the tools you have available is usually an anonymized survey of similar compensation levels from other companies.
You can say things like "this person is a high performer and is being paid 85% of the expected level for this title at other companies nearby - we should bump them up".
Your company may use job titles in a non-standard way, but there's probably an HR document somewhere that attempts to map them to more standard levels in order to make these kinds of comparisons useful.
I don't know how this works in other industries or countries, but I've seen this pattern play out in San Francisco Bay Area tech companies.
If you are an engineering manager looking to make the case for raises for your team members one of the tools you have available is usually an anonymized survey of similar compensation levels from other companies.
You can say things like "this person is a high performer and is being paid 85% of the expected level for this title at other companies nearby - we should bump them up".
Your company may use job titles in a non-standard way, but there's probably an HR document somewhere that attempts to map them to more standard levels in order to make these kinds of comparisons useful.
I don't know how this works in other industries or countries, but I've seen this pattern play out in San Francisco Bay Area tech companies.
>> use titles as a way to compare salary levels with each other.
small companies typically go the other way, using titles to make up for concrete remuneration. This is why everyone in a startup is a VP and ICs climb the ladder to senior in a couple of years.
small companies typically go the other way, using titles to make up for concrete remuneration. This is why everyone in a startup is a VP and ICs climb the ladder to senior in a couple of years.
> This is why everyone in a startup is a VP and ICs climb the ladder to senior in a couple of years.
Another thing I've noticed happening is that if these companies grow into medium sized companies, these OG employees actually become VPs and directors whether they are qualified for these roles or not. Just by virtue of them being there first. I've worked at enough medium sized companies and have seen this at every one of them: "Why is this moron SVP of engineering?" "Well, he was employee number 5 back in the day."
Another thing I've noticed happening is that if these companies grow into medium sized companies, these OG employees actually become VPs and directors whether they are qualified for these roles or not. Just by virtue of them being there first. I've worked at enough medium sized companies and have seen this at every one of them: "Why is this moron SVP of engineering?" "Well, he was employee number 5 back in the day."
This brings back memories of the candidate who demanded coming in as a high level engineer. Their argument was they were currently a CTO. Of their 2 person company. While they were still in college. And they were only borderline hireable for our entry level role.
Titles are really a trap cannot reveal the real work, everything it's related to the size of company, type of organization and sector.
A "top" position in a small company could be a mid one in a big tech but with a narrow field compared to the small one when sometimes you need to refill the coffee machine. At same time the flexibility of small one helps to solve problems of big ones.
A "top" position in a small company could be a mid one in a big tech but with a narrow field compared to the small one when sometimes you need to refill the coffee machine. At same time the flexibility of small one helps to solve problems of big ones.
Outside of the FAANG style companies where how their levels map to each other are well known, titles are only useful to compare within the same company. You can't compare a specific title between two companies as they may not even have the same hierarchy much less requirements & expectations.
Yeah. "You already know what a title is, Neo. A title is a text field attached to a pay grade."
It's an artifact of humans being obsessed with hierarchy and pecking order.
Overall rather petty and boring.
Overall rather petty and boring.
It’s how good you are at politics, that’s it. Big modifier if you’re tall and attractive.
My employer has no formal titles for engineers pretty much for this reason.
Main distinction I tend to see is just whether you're doing line management or not, which tends to be the EM track
Beyond that, agree it seems like it can just be anything in virtually any title
Beyond that, agree it seems like it can just be anything in virtually any title
> 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.
All the responses here won't admit that it is entirely made up, and designed to be built around a structured hierarchy which rule followers and obedient servents to the system to get closer to the $$$ printer.
It takes a lot of back-stabbing, office politics, credit stealing and dishonesty to get to "the top", which is what the replies won't tell you.
> 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.
Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
Heck, you could even build your own startup and give yourself that title if you wanted to. But the majority here will not and will work for companies like Meta under EMs that have no idea what they are doing.
Therefore it is all made up. With some "staff", "leads" and "principals" are making it up as they go along and coasting as the low rankers hold the fort as the ship sinks.
All the responses here won't admit that it is entirely made up, and designed to be built around a structured hierarchy which rule followers and obedient servents to the system to get closer to the $$$ printer.
It takes a lot of back-stabbing, office politics, credit stealing and dishonesty to get to "the top", which is what the replies won't tell you.
> 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.
Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
Heck, you could even build your own startup and give yourself that title if you wanted to. But the majority here will not and will work for companies like Meta under EMs that have no idea what they are doing.
Therefore it is all made up. With some "staff", "leads" and "principals" are making it up as they go along and coasting as the low rankers hold the fort as the ship sinks.
i think i could reasonably drscribe a difference.
entry - needs mentoring to get stuff done mid - can build the whole thing by themselves, given enough time senior - can guide entry and mod to the same overall task and break up work such that both can do it. organizes and coordinates work across multiple teams principal/staff - sets direction for many teams worth of engineers
above that stops being so meaningful, except for directing where major engineering directions go, and is kinda more of a sales job about getting a lot of engineering managers pointed in the same direction.
a lead is orthogonal a bit, but reasonably a flavour of senior. you could have several seniors but only one lead in an area, who's a bit obsessed with a topic, and has the idea of where things are going.
> Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
yes? i set up projects and gave feedback for people younger than me to get promos, and they did the work well and showed that they can do that work. Just cause didnt want the promo doesnt mean they didnt show their skill. Age is just a number. The youngest principal i met is by far still the best and most effective one (other than the sandbagging senior-principal)
entry - needs mentoring to get stuff done mid - can build the whole thing by themselves, given enough time senior - can guide entry and mod to the same overall task and break up work such that both can do it. organizes and coordinates work across multiple teams principal/staff - sets direction for many teams worth of engineers
above that stops being so meaningful, except for directing where major engineering directions go, and is kinda more of a sales job about getting a lot of engineering managers pointed in the same direction.
a lead is orthogonal a bit, but reasonably a flavour of senior. you could have several seniors but only one lead in an area, who's a bit obsessed with a topic, and has the idea of where things are going.
> Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
yes? i set up projects and gave feedback for people younger than me to get promos, and they did the work well and showed that they can do that work. Just cause didnt want the promo doesnt mean they didnt show their skill. Age is just a number. The youngest principal i met is by far still the best and most effective one (other than the sandbagging senior-principal)
It's all about perception. People love fancy titles, even though it's ultimately meaningless. I worked with several "directors" that made much less than I did as a staff+ level engineer.
I went from Programmer to Staff, moved to Senior, jumped again to Lead, then only "Developer" promoted to Senior.
Each company has its own way to name things.
Each company has its own way to name things.
Titles are meaningless. Many tech ICs at top companies have more influence and responsibility as well as pay than managers at low tier companies.
Titles are arbitrary (as in people with different titles can do similar work), but compensation is tied to a title.
I am also not surprised that many P.E. have become Political Engineer as opposed to Principal Engineer.
Personally, I don't give two shits about my title. If I could just be "computer programmer", I'd be happy. But the org likes titles and as long as I have to play that stupid game, I try to get titles.
Wait until you meet a VP in finance.
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.
[1] https://en.wikipedia.org/wiki/Peter_principle
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.
[1] https://en.wikipedia.org/wiki/Peter_principle
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.
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.
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.
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
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.
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.
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.
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.
[deleted]
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.
> I have people under me who [...]
Instant red flag. You're a manager. You are managing. There is no one "under you".
Instant red flag. You're a manager. You are managing. There is no one "under you".
That's pretty standard lingo. Would you prefer "reporting to me"?
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.
Sometimes, it can look like management is doing very little because you only see the tail end of their outputs to the team.
He doesn't get much say about what thing gets done. He's just kind of there.
The question to ask of course is do you see how your manager interacts with their management?
Do the things that get done stay consistent, or are your priorities constantly changing? Do you and your team control your priorities or are they out of your control?
I think it's very difficult to see what managers are even doing (I'm not one, I'm a senior IC) until you have a particular level of visibility or exposure to planning and prioritization. But once I started to see that and see why it was hard as I began to interact with it myself, it becomes much clearer.
Do the things that get done stay consistent, or are your priorities constantly changing? Do you and your team control your priorities or are they out of your control?
I think it's very difficult to see what managers are even doing (I'm not one, I'm a senior IC) until you have a particular level of visibility or exposure to planning and prioritization. But once I started to see that and see why it was hard as I began to interact with it myself, it becomes much clearer.
He doesn’t understand enough to have any say. His management tells him what his reports will be doing and he says yes.
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.
Once you get to leadership you're giving credit where it's due and soaking up the loss.
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.
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
their role is to make sure the team can execute had the fastest best velocity.
usually as a shit umbrella
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.
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.
Everybody wants a manager that has engineering experience, but nobody wants to be that manager.
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.
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.
I didn't know freelance interim em was a thing, interesting role.
ive had that manager a few times. its quite nice, but also, parents do a better job than non-parents
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
> 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).
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).
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.
* 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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
[deleted]
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.
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.
> 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.
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.
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.
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.
> I think you over estimate how valuable really good Principal level talent is when you have AIs that can take over for entire teams.
I think you mean underestimate.
A good principal engineer (and they almost always are good) is someone who can understand both business requirements as well as the architectural foundations that underlay the product itself.
Principal (and Principal track Staff, Senior, and early-career) SWEs aren't going anywhere. In fact in an LLM-driven world, their domain experience is much more critical.
I think you mean underestimate.
A good principal engineer (and they almost always are good) is someone who can understand both business requirements as well as the architectural foundations that underlay the product itself.
Principal (and Principal track Staff, Senior, and early-career) SWEs aren't going anywhere. In fact in an LLM-driven world, their domain experience is much more critical.
[deleted]
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.
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.
> 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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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
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
The document is comparing salaries of staff engineers, and EM's. In my experience staff engineer positions are even rarer then EM positions.
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)
> 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.
Where do you work?!? If you are in Western Europe then the blogpost is irrelevant for you. The Western European market is weird.
Can you elaborate more about this? Why is it irrelevant in Western Europe?
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.
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.
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.
- 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.
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.
The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.
> 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.
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.
One thing I rarely see discussed: the best engineers I've worked with who moved into management didn't do it for the title or the career ladder. They did it because they noticed they were already doing the job informally — unblocking people, aligning priorities, having the hard conversations. The role just formalized what they were already spending 40% of their time on. If you're not already gravitating toward those activities naturally, that's a strong signal the role isn't for you.
True 100 %
A lot of strong engineers move into EM roles expecting deeper technical impact, but end up spending most of their time on coordination, hiring, performance reviews, and cross-team alignment. That’s valuable work — just very different from building systems. More orgs should invest in strong IC tracks (Staff/Principal) so people can lead technically without managing people. Not everyone who’s good at engineering wants to optimize calendars and org charts.
A lot of strong engineers move into EM roles expecting deeper technical impact, but end up spending most of their time on coordination, hiring, performance reviews, and cross-team alignment. That’s valuable work — just very different from building systems. More orgs should invest in strong IC tracks (Staff/Principal) so people can lead technically without managing people. Not everyone who’s good at engineering wants to optimize calendars and org charts.
> It’s a bad time to move away from tech
It continues to amaze me that becoming a manager of anything should mean moving away from it. The manager has to move away from the detail, but why should they move from the substance of the role. A legal partner has to stay up to date as much their staff, in fact a legal partner is often the only one who can answer complex questions. When I need complex advice on my statutory accounts I get referred to the Audit Partner, the most senior manager.
The manager at my structural engineers can still calculate a beam size, he is better at it than his staff.
So why in software should an engineering manager move away from tech? Isn't this just a sign of disfunction in those organisations rather than anything about the role. Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'?
And what do these managers even do if they have moved away from tech? Approve holidays and expenses? My personal theory is that in these kind of organisations a manager is the person who is better with PowerPoint than the other people!
It continues to amaze me that becoming a manager of anything should mean moving away from it. The manager has to move away from the detail, but why should they move from the substance of the role. A legal partner has to stay up to date as much their staff, in fact a legal partner is often the only one who can answer complex questions. When I need complex advice on my statutory accounts I get referred to the Audit Partner, the most senior manager.
The manager at my structural engineers can still calculate a beam size, he is better at it than his staff.
So why in software should an engineering manager move away from tech? Isn't this just a sign of disfunction in those organisations rather than anything about the role. Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'?
And what do these managers even do if they have moved away from tech? Approve holidays and expenses? My personal theory is that in these kind of organisations a manager is the person who is better with PowerPoint than the other people!
It's because the software EM function in tech companies doesn't have parallels to managers in other professions.
The technical decisions are made by the high-level SWEs. The product decision and customer-facing work is done by the PMs. The EM role only exists to hire, evaluate, promote, and fire SWEs. It's very light on the "engineering" and very heavy on the "manager". It's almost an HR-type role.
In my career, all my EMs who weren't recently internally promoted couldn't read the programming language that their team writes in. Some of them have good system design skills but they eventually atrophy from disuse. It's very much a role where you hang up the cleats.
The root cause is that other professions didn't bifurcate technical leadership and people management into separate streams. The partner lawyer or civil EM is the seniormost technical person on the team. Often the software EM is the least technical person on the team.
BTW there are countries (like China) that don't follow this model. Meaning, the only way to get promoted above a mid-level SWE is to become an EM. There is no parallel IC track, i.e. no "senior staff", "principal" or "distinguished" engineers. Just young ICs and older EMs.
The technical decisions are made by the high-level SWEs. The product decision and customer-facing work is done by the PMs. The EM role only exists to hire, evaluate, promote, and fire SWEs. It's very light on the "engineering" and very heavy on the "manager". It's almost an HR-type role.
In my career, all my EMs who weren't recently internally promoted couldn't read the programming language that their team writes in. Some of them have good system design skills but they eventually atrophy from disuse. It's very much a role where you hang up the cleats.
The root cause is that other professions didn't bifurcate technical leadership and people management into separate streams. The partner lawyer or civil EM is the seniormost technical person on the team. Often the software EM is the least technical person on the team.
BTW there are countries (like China) that don't follow this model. Meaning, the only way to get promoted above a mid-level SWE is to become an EM. There is no parallel IC track, i.e. no "senior staff", "principal" or "distinguished" engineers. Just young ICs and older EMs.
That is a great description, thanks.
The question really is why does American tech organise itself this way, a completely different way to other professions?
> The EM role only exists to hire, evaluate, promote, and fire SWEs
I can see why some people would find that unfulfilling. I work in one of those other professions and if I did just the hr bit I would be bored out of my mind! Do SWEs value the input of their EM? Does it really add value, or a bunch of busy work?
The question really is why does American tech organise itself this way, a completely different way to other professions?
> The EM role only exists to hire, evaluate, promote, and fire SWEs
I can see why some people would find that unfulfilling. I work in one of those other professions and if I did just the hr bit I would be bored out of my mind! Do SWEs value the input of their EM? Does it really add value, or a bunch of busy work?
>why does American tech organise itself this way, a completely different way to other professions?
The massive shortage of software engineer talent over many decades has created a situation where any work that a SWE doesn't like to do is carved out into its own role so that the SWE's job description stays fun and attractive.
DE, DS, BI, SDET, SRE, QA, FDE, SE and to some extent even PM are all roles that emerged from the boring stuff that SWEs don't like doing.
>Do SWEs value the input of their EM? Does it really add value, or a bunch of busy work?
Depends on the EM. Usually though, no. Usually EMs earn the respect of their reports by doing the people side of things really well, not by having extraordinary technical inputs.
The massive shortage of software engineer talent over many decades has created a situation where any work that a SWE doesn't like to do is carved out into its own role so that the SWE's job description stays fun and attractive.
DE, DS, BI, SDET, SRE, QA, FDE, SE and to some extent even PM are all roles that emerged from the boring stuff that SWEs don't like doing.
>Do SWEs value the input of their EM? Does it really add value, or a bunch of busy work?
Depends on the EM. Usually though, no. Usually EMs earn the respect of their reports by doing the people side of things really well, not by having extraordinary technical inputs.
> Is it this MBA idea that management itself is a profession
I don't think that you can take somebody with a finance background, take them straight out of their MBA, and drop them in an EM position. That's a bad fit. Good EMs need to come from software engineering backgrounds, mostly for the reasons you cite.
But management truly is a different profession with a different set of skills and a different set of challenges.
Even on the IC track, there's languages and frameworks that I touched early in my career (e.g. Java/Spring) and haven't touched in, I don't know, a decade, and I have not been keeping up with whatever is most recent best practice there. If I were to go into an IC role for one of those frameworks, I might as well be going into an IC role for a language I haven't learned before, ever. I expect someone who has been working with that language on a daily basis to really, really know it - having the standard library practically memorized, knowing common pitfalls, doing a lot of stuff from muscle memory, someone who you give them a PR that "looks OK" and they start reading and immediately can say "well that's just not even remotely idiomatic".
EMs are almost guaranteed to lose that touch because their day job is talking to people, not writing code. That's not to say that they couldn't go back to the IC track and start to sharpen those skills again, but EMs with FOMO who try to stay in the code are spending that time not talking to people. The lack of focus makes them bad EMs.
I don't think that you can take somebody with a finance background, take them straight out of their MBA, and drop them in an EM position. That's a bad fit. Good EMs need to come from software engineering backgrounds, mostly for the reasons you cite.
But management truly is a different profession with a different set of skills and a different set of challenges.
Even on the IC track, there's languages and frameworks that I touched early in my career (e.g. Java/Spring) and haven't touched in, I don't know, a decade, and I have not been keeping up with whatever is most recent best practice there. If I were to go into an IC role for one of those frameworks, I might as well be going into an IC role for a language I haven't learned before, ever. I expect someone who has been working with that language on a daily basis to really, really know it - having the standard library practically memorized, knowing common pitfalls, doing a lot of stuff from muscle memory, someone who you give them a PR that "looks OK" and they start reading and immediately can say "well that's just not even remotely idiomatic".
EMs are almost guaranteed to lose that touch because their day job is talking to people, not writing code. That's not to say that they couldn't go back to the IC track and start to sharpen those skills again, but EMs with FOMO who try to stay in the code are spending that time not talking to people. The lack of focus makes them bad EMs.
> The manager at my structural engineers can still calculate a beam size, he is better at it than his staff. So why in software should an engineering manager move away from tech...
Because a manager at a structural engineering company is essentially acting as the equivalent of what a Product Manager or Forward Deployed Engineer is in the tech industry, because they are expected to be a technical domain expert and own delivery.
Meanwhile, for most software companies the underlying codebase isn't want generates revenue - it's the codification of business logic that does. Additionally, companies tend to have a separate Princiapl Eng to Distinguished Engineer/Architect track that outranks EMs and is in direct contact with leadership.
> Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'
Most Engineering Managers and Beancounters aren't MBAs - no company wants to sponsor an employee at a PTMBA which can cost upwards of $250K now.
Because a manager at a structural engineering company is essentially acting as the equivalent of what a Product Manager or Forward Deployed Engineer is in the tech industry, because they are expected to be a technical domain expert and own delivery.
Meanwhile, for most software companies the underlying codebase isn't want generates revenue - it's the codification of business logic that does. Additionally, companies tend to have a separate Princiapl Eng to Distinguished Engineer/Architect track that outranks EMs and is in direct contact with leadership.
> Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'
Most Engineering Managers and Beancounters aren't MBAs - no company wants to sponsor an employee at a PTMBA which can cost upwards of $250K now.
> it's the codification of business logic that does.
Isn't that what product/project managers and architects do though?
Other comments describe EMs as just HR mangers
Isn't that what product/project managers and architects do though?
Other comments describe EMs as just HR mangers
> The manager at my structural engineers can still calculate a beam size, he is better at it than his staff.
That sounds insane to me. I want my manager to be good and managing. If they are writing code, it's a misuse of their time and skills. If they are good at writing code and bad at managing, they shouldn't be a manager.
That sounds insane to me. I want my manager to be good and managing. If they are writing code, it's a misuse of their time and skills. If they are good at writing code and bad at managing, they shouldn't be a manager.
And that confuses me. There are so many posts on hn complaining about managers and the bs they bring, 1:1s you didn't ask for etc.
What does a manager even do in this world where they are non technical? I have never managed a large sw team tbf, but in smaller teams I did manage I had to do project management stuff. In my normal profession I manage a large team, but one of my big roles is being there to advise technically and make the big decisions. I can see why people find these EM jobs boring, you must have to invent things to do!
What does a manager even do in this world where they are non technical? I have never managed a large sw team tbf, but in smaller teams I did manage I had to do project management stuff. In my normal profession I manage a large team, but one of my big roles is being there to advise technically and make the big decisions. I can see why people find these EM jobs boring, you must have to invent things to do!
The best managers can still do the work part, that much is obvious. Not necessarily being the best in the team but offering the best project-level advice because the manager has enough skill combined with being the only one in the team dedicating thinking cycles "to the whole picture". But that only works well if you have the buy-in skill level that needs to be kept sharp.
> Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'?
Yes I believe so. At uni i see soooo many people who are in software to make a startup (before even knowing how to code) and make a quick buck instead of being good programmers
Yes I believe so. At uni i see soooo many people who are in software to make a startup (before even knowing how to code) and make a quick buck instead of being good programmers
I suppose what really escapes me is that companies are willing to pay people to do a pointless job. I wonder if the most senior are just more comfortable listening to a meaningless PowerPoint meeting than hearing complicated stuff about the work their company does
The key is to stay hands-on. I go for the tech lead role.
Actually at my current company I'm co-lead of a team of 10 people. I've been CTO and also the sole team lead in the past but I was always hands-on coding.
I'm glad I have a co-lead at my current company; in fact, I'm the one who recommended to the big boss that he promote both of us. Normally, I'm the sole leader but in this company, we deal with corporate clients and so there is a fair amount of compliance work, team coordination and stakeholder management and also the project itself is very complex on the tech side. AI adds a lot of complexity. My co-lead is really good with coordination, planning, meetings, stakeholder management and alignment but at the same time he has less experience on the tech side so I have the last say on technical matters like architecture and choice of technologies and I'm in charge of general-purpose modules, configurations, migrations, data management...
I think staying hands-on is very important, especially now with LLMs. Managing complexity is itself a separate concern from managing people. There is a human/psychological component to managing complexity but it's different than pure time management and coordinating work based on priorities. On a project with 10+ people, with AI, the complexity can grow rapidly and so it needs to be managed.
Actually at my current company I'm co-lead of a team of 10 people. I've been CTO and also the sole team lead in the past but I was always hands-on coding.
I'm glad I have a co-lead at my current company; in fact, I'm the one who recommended to the big boss that he promote both of us. Normally, I'm the sole leader but in this company, we deal with corporate clients and so there is a fair amount of compliance work, team coordination and stakeholder management and also the project itself is very complex on the tech side. AI adds a lot of complexity. My co-lead is really good with coordination, planning, meetings, stakeholder management and alignment but at the same time he has less experience on the tech side so I have the last say on technical matters like architecture and choice of technologies and I'm in charge of general-purpose modules, configurations, migrations, data management...
I think staying hands-on is very important, especially now with LLMs. Managing complexity is itself a separate concern from managing people. There is a human/psychological component to managing complexity but it's different than pure time management and coordinating work based on priorities. On a project with 10+ people, with AI, the complexity can grow rapidly and so it needs to be managed.
Staying hands on matters.
I think it also matters how you stay hands on.
Initially, I was in the weeds quite often with my engineers. Over the years I’ve learned to maintain side projects that directionally follow what my teams are doing. It gives me some dispassionate separation and a unique look at things that my engineers appreciate.
I think it also matters how you stay hands on.
Initially, I was in the weeds quite often with my engineers. Over the years I’ve learned to maintain side projects that directionally follow what my teams are doing. It gives me some dispassionate separation and a unique look at things that my engineers appreciate.
I have been both an EM and a Staff software engineer at a bigtech.
Both are great career choices but lately being an EM means spending over 6 hours a day in meetings and having very little agency over your time. Your whole job is basically being in meetings and being a human router for information between people.
This changed when BigTech redefined the roles of an EM. Back in the days, the EM would naturally be the best engineer in the team that wanted to stay technical and grow the team. Since 2010, Bigtech has decided that EM should especially NOT be technical. They should do "People things" only. I think that was a turn for the worse in our industry,
As an IC I have way more control over my time. I can decide when I work.
That being said it depends what I want to optimize for. I think if your goal is to climb up the ladder you will do that more easily as a driven EM than a driven IC.
As an EM if you are driven and put the hours in and play the game well, you could get promoted to Director/Sr. Director. The skills here are not especially difficult. Getting promoted is all about being at the right time at the right place and playing the right game. If you are an EM in a growing company, you will almost certainly grow with the compant and get more scope.
As an engineer it feels way more difficult to get promoted past Staff. After Staff you are competing with people that are absolutely cracked coders and dedicated 12+ hours a day working. Most of them have a talent level that is almost unmatchable.
But really, if you want to manage your time, don't become an EM.
Both are great career choices but lately being an EM means spending over 6 hours a day in meetings and having very little agency over your time. Your whole job is basically being in meetings and being a human router for information between people.
This changed when BigTech redefined the roles of an EM. Back in the days, the EM would naturally be the best engineer in the team that wanted to stay technical and grow the team. Since 2010, Bigtech has decided that EM should especially NOT be technical. They should do "People things" only. I think that was a turn for the worse in our industry,
As an IC I have way more control over my time. I can decide when I work.
That being said it depends what I want to optimize for. I think if your goal is to climb up the ladder you will do that more easily as a driven EM than a driven IC.
As an EM if you are driven and put the hours in and play the game well, you could get promoted to Director/Sr. Director. The skills here are not especially difficult. Getting promoted is all about being at the right time at the right place and playing the right game. If you are an EM in a growing company, you will almost certainly grow with the compant and get more scope.
As an engineer it feels way more difficult to get promoted past Staff. After Staff you are competing with people that are absolutely cracked coders and dedicated 12+ hours a day working. Most of them have a talent level that is almost unmatchable.
But really, if you want to manage your time, don't become an EM.
While my friend was offered a bump with the promotion to EM, the total compensation was less than the offers he received for Senior/Staff Engineer at other startups.
"At other startups" is the important bit here. I assume 'startup' means less than 100 people, at which point it switches to 'scaleup', but whatever definition you use the question should really be 'When does an EM actually start being useful?'
Startups don't really need EMs because they don't really need managers at all. There is a strong expectation in a startup that the staff there are capable of managing themselves, plus there are usually fewer business functions that developers need to work with. Where an EM is useful is in a larger business that has many competing demands of engineering teams: features, roadmaps, BAU, KTLO, tech debt, compliance, etc ... it's a long list. There's a necessity for someone to manage that, and support the teams to be doing the right work at the right time, without letting standards slide, and to support the team to navigate and negotiate the political maze of multiple stakeholders wanting their thing to be priority #1.
I've been an EM for a few years and I would not recommend someone takes an EM role in any company that has less than 70-100 staff (assuming about 1/3 is engineering). Once you get to that scale I think the role starts getting interesting, and valued, but if the company is smaller it should be managing those processes fairly easily already. If it isn't then that's a signal there's problems with the way the business works that an EM probably can't solve because they're rooted in the business's leadership culture.
"At other startups" is the important bit here. I assume 'startup' means less than 100 people, at which point it switches to 'scaleup', but whatever definition you use the question should really be 'When does an EM actually start being useful?'
Startups don't really need EMs because they don't really need managers at all. There is a strong expectation in a startup that the staff there are capable of managing themselves, plus there are usually fewer business functions that developers need to work with. Where an EM is useful is in a larger business that has many competing demands of engineering teams: features, roadmaps, BAU, KTLO, tech debt, compliance, etc ... it's a long list. There's a necessity for someone to manage that, and support the teams to be doing the right work at the right time, without letting standards slide, and to support the team to navigate and negotiate the political maze of multiple stakeholders wanting their thing to be priority #1.
I've been an EM for a few years and I would not recommend someone takes an EM role in any company that has less than 70-100 staff (assuming about 1/3 is engineering). Once you get to that scale I think the role starts getting interesting, and valued, but if the company is smaller it should be managing those processes fairly easily already. If it isn't then that's a signal there's problems with the way the business works that an EM probably can't solve because they're rooted in the business's leadership culture.
I have a few different reasons why you might think twice about this role.
- if you transition from a technical role into this, beware your technical skills need regular usage to stay relevant. Not a show stopper for this role and I've had good non technical managers.
- Be ready for a lot of relatively short lived jobs as a CTO or VP Engineering. Many startups create engineering manager type roles around the time they start scaling struggling a bit. Maybe the founder CTO wasn't so good at management or whatever. You'll inherit a mess. And they might not like you after all. I've had a few friends facing a lot of churn in this role. Just one company after another, do ungrateful work, and then move on to the next. It can pay well but it's not stable work. And quite stressful. Some people get lucky of course.
- Make sure that this is really what you want to do the rest of your career and see the above two points.
If you find the right employer, then this can be a great role of course. I've had a few excellent engineering managers (some of them retired now) in my career. But I have heard of people burning out or getting a rough deal, repeatedly trying to do VP Engineering roles in messy startups/scaleups as well. I know a few more of those.
- if you transition from a technical role into this, beware your technical skills need regular usage to stay relevant. Not a show stopper for this role and I've had good non technical managers.
- Be ready for a lot of relatively short lived jobs as a CTO or VP Engineering. Many startups create engineering manager type roles around the time they start scaling struggling a bit. Maybe the founder CTO wasn't so good at management or whatever. You'll inherit a mess. And they might not like you after all. I've had a few friends facing a lot of churn in this role. Just one company after another, do ungrateful work, and then move on to the next. It can pay well but it's not stable work. And quite stressful. Some people get lucky of course.
- Make sure that this is really what you want to do the rest of your career and see the above two points.
If you find the right employer, then this can be a great role of course. I've had a few excellent engineering managers (some of them retired now) in my career. But I have heard of people burning out or getting a rough deal, repeatedly trying to do VP Engineering roles in messy startups/scaleups as well. I know a few more of those.
Manager or not I think the real risk is overly adapting your skills to one company. Managers becoming experts at one companies politics and cannot instead of general organizational dynamics. The devs who seem to only get by in this one team / codebase, and neglect general skills, looming down on outside info as buzzwords.
It seems smart at the time, and makes you more effective in the near term. But it might cause many of your skills to lose portability.
It seems smart at the time, and makes you more effective in the near term. But it might cause many of your skills to lose portability.
I'm a former EM who would never go back in an AI age.
EMs deal with friction and from my experience more output is more friction.
You have org leaders and businessy people putting their foot on the gas because AI is so productive and then programmers shipping 2-3x more code.
These two forces collide and you're stuck dealing with the friction so 10x the amount of initiatives you did before.
The friction is like sandpaper on sandpaper.
EMs deal with friction and from my experience more output is more friction.
You have org leaders and businessy people putting their foot on the gas because AI is so productive and then programmers shipping 2-3x more code.
These two forces collide and you're stuck dealing with the friction so 10x the amount of initiatives you did before.
The friction is like sandpaper on sandpaper.
As an EM I don't get this. You are the sole responsible for quality. You are the sole responsible for what tools use. AI is voluntary to use. If AI produces code that no one knows and is hard to maintain, don't use AI in that way. If you can't make that decision, are you really the EM?
> AI is voluntary to use.
> If you can't make that decision, are you really the EM?
You'd be served well as an EM by this part of the Serenity Prayer:
"God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference."
Depending on your organization, odds are high that AI use is one of the things you cannot change. Perhaps not even something you're ought to change. If your team is delivering x% more, "it makes my job x% more difficult so don't do that" won't fly neither upwards nor downwards.
> If AI produces code that no one knows and is hard to maintain
I think you're making an assumption here that the main problem with AI use is necessarily quality.
OP wasn't even talking about AI producing bad code, just that it creating more code, and enabling more things to happen. More things going on at the same time, means you'd have more friction points and more things that can go wrong. Whenever those happen, the EM is pulled in.
> If you can't make that decision, are you really the EM?
You'd be served well as an EM by this part of the Serenity Prayer:
"God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference."
Depending on your organization, odds are high that AI use is one of the things you cannot change. Perhaps not even something you're ought to change. If your team is delivering x% more, "it makes my job x% more difficult so don't do that" won't fly neither upwards nor downwards.
> If AI produces code that no one knows and is hard to maintain
I think you're making an assumption here that the main problem with AI use is necessarily quality.
OP wasn't even talking about AI producing bad code, just that it creating more code, and enabling more things to happen. More things going on at the same time, means you'd have more friction points and more things that can go wrong. Whenever those happen, the EM is pulled in.
> You are the sole responsible for what tools use.
Sure, but now competitors are shipping like crazy (at their EM's sanity expense?). What to do?
> AI is voluntary
Until the company mandate. And also there 10 other EMs that I am competing with on my org tree alone, and their teams are all AI-heavy. Is that really a matter of choice?
Sure, but now competitors are shipping like crazy (at their EM's sanity expense?). What to do?
> AI is voluntary
Until the company mandate. And also there 10 other EMs that I am competing with on my org tree alone, and their teams are all AI-heavy. Is that really a matter of choice?
I agree with that. The way I see the marketing going forward with AI, you need to be able to have proven outstanding technical skills and deep understanding across several technical domains to be able to add value to the chain. This mean staying in the trenches along with serious self-education schedule. You should be reading books now and doing hard stuff.
Alternatively, this is all a psy-op by AI companies to make engineers willing to work harder for less money so they can pretend all that productivity growth is thanks to their stuff.
I will stay as an individual contributor as long as possible. My one step into team
management at 23~ was very enlightening.
> My friend was afraid that as a manager, he'd have less time to experiment and adapt. Especailly with a bigger team (he was offered to manage 6), you don’t have much time to play around.
You guys get time to play around? As lead/staff?
> You can be a great EM for years and find yourself stuck.
Better start now then, right?
You guys get time to play around? As lead/staff?
> You can be a great EM for years and find yourself stuck.
Better start now then, right?
yeah?
my job is basically self-directed. I'm expected to predict the future for what we as a business will need in 6 months to a year and become the expert in it now. lay the framework, prototype, sell to the larger org, integrate and move onto whatever else. This is in addition to the normal jira-driven feature/bugfix bullshit. I am looking at the problems we might run into then derisk them by figuring out what to build.
But I'm at a large org where timelines are about as flexible as jello. I think I'm also overqualified and underpaid so my boss just lets me do whatever.
Like I've been porting firmware from C to rust a day or two a week while I also am directing some more jr devs for our VP's latest product obsession.
my job is basically self-directed. I'm expected to predict the future for what we as a business will need in 6 months to a year and become the expert in it now. lay the framework, prototype, sell to the larger org, integrate and move onto whatever else. This is in addition to the normal jira-driven feature/bugfix bullshit. I am looking at the problems we might run into then derisk them by figuring out what to build.
But I'm at a large org where timelines are about as flexible as jello. I think I'm also overqualified and underpaid so my boss just lets me do whatever.
Like I've been porting firmware from C to rust a day or two a week while I also am directing some more jr devs for our VP's latest product obsession.
this is peak "the majority of people in this role are garbage but I'm a rockstar". 98%+ of people identify as special snowflakes.
We shouldn't move away from tech, because Anthropic is hiring 100+ people to prompt a chatbot to write code? Hahaha, how fast we've fallen.
Not to mention Anthropic has a huge conflict of interest in making you think nothing is wrong. And the author fell for it.
Not to mention Anthropic has a huge conflict of interest in making you think nothing is wrong. And the author fell for it.
After years of being asked to be a manager I finally said yes and started on Monday this week. This article could've come out a little sooner! j/k
What tipped it for me is I spend most of my time managing agents now, why not manage some human agents too.
What tipped it for me is I spend most of my time managing agents now, why not manage some human agents too.
Every job in engineering is changing right now. Managers aren't immune. I've been an EM for almost 20 years in some flavor or another, and I've been thinking a lot about how I want to adapt to this era.
This is the first time I've seriously considered swapping out of management. Not for any of the reasons the author says, but because:
- I don't feel as confident mentoring others through this period given how much the work is changing
- I find myself enjoying the work more
- EMs tend to have more difficulty justifying their existence at the best of times let alone a period of change like this
The AI world will still need EMs. It's just unclear what those EMs will be doing every day and how it will work.
This is the first time I've seriously considered swapping out of management. Not for any of the reasons the author says, but because:
- I don't feel as confident mentoring others through this period given how much the work is changing
- I find myself enjoying the work more
- EMs tend to have more difficulty justifying their existence at the best of times let alone a period of change like this
The AI world will still need EMs. It's just unclear what those EMs will be doing every day and how it will work.
Isn't being an engineering manager about leverage? Someone needs to organize people, allocate resources, or even decide the direction of products. We may say that ICs can make equally good such decisions, but every company has a hierarchy and someone does call the shots. And for better or for worse, some people are indeed good at navigating company dynamics and driving an organization forward, even though they may suck at building. An example would be IBM's Watson Jr. He was known for being awkward at mastering IBM tech as a salesperson. Even in a holacratic company like Zappos or Valve, some people still manage, right?
In addition, I think the roles of manager and engineer will blend and management layers will flatten - companies are mostly looking for managers who code some of the time. It helps them run lean and avoid layers of management which slow down execution.
As we demand more productivity out of our devs, we’ll be demanding similar efficiency gains from our managers as well, and that means they’ll need to be doing more than just pushing paper and cheerleading.
So if you do go into management, keep in mind you can’t let your engineering skills atrophy… you now have to be good at both. There aren’t many people who can do both well, but companies will expect this moving forward.
As we demand more productivity out of our devs, we’ll be demanding similar efficiency gains from our managers as well, and that means they’ll need to be doing more than just pushing paper and cheerleading.
So if you do go into management, keep in mind you can’t let your engineering skills atrophy… you now have to be good at both. There aren’t many people who can do both well, but companies will expect this moving forward.
Or, because coding is now not a bottleneck, it'll become increasingly important to ensure all your developers know what to do/achieve, and you'll need to put more effort into setting up structures, processes etc to do that. More collaboration (instead of lone wolf coder) may actually increase the need for good managers.
That could be - I hadn’t thought about it that way, actually
> that means they’ll need to be doing more than just pushing paper and cheerleading
That never lasts. No one can do do both and do them effectively.
That never lasts. No one can do do both and do them effectively.
I happen to agree with you entirely… but I just have this feeling things will go this way as companies put more and more cost pressure on middle management layers.
People should know that you can't "just" turn down a promotion. You might be leaving management in a tough position where they were hoping to rely on you to fill a gap, and by turning it down, you're making it hard for them to be objective. They might default to seeing you as unreliable, and cut off future advancement opportunities (the ones you actually want). It's not fair, but that's how people think. This isn't a big problem when the money is free and everyone is trying to poach employees. You can just jump ship. But in this hellish economy, everyone is stuck. So take that damn promotion.
I had a similar realization today. I work as an EM, and one important aspect of my work is becoming worthless: experience.
Having been an IC for a long time usually enables me to support my team, or identify risks, lead projects and so on. However, since I never was an IC in the day and age of AI, I find that this experience is less and less applicable.
A significant part of what helps me increase impact of others is that I’ve „been there, done that“ and that’s going away right now.
I don’t mind - it’s exciting! But if I was an IC right now I would not switch tracks under any circumstances. There is so much more to learn directly in the trenches.
Having been an IC for a long time usually enables me to support my team, or identify risks, lead projects and so on. However, since I never was an IC in the day and age of AI, I find that this experience is less and less applicable.
A significant part of what helps me increase impact of others is that I’ve „been there, done that“ and that’s going away right now.
I don’t mind - it’s exciting! But if I was an IC right now I would not switch tracks under any circumstances. There is so much more to learn directly in the trenches.
There is also another aspect of title that needs to be considered. A part of a company I used to work for did work with the banking industry. There is the meme of everyone is a VP at a bank, but for those of us who interacted with customers, we did have VP in our title, which caused internal angst, otherwise at some institutions it was seen as a snub to be dealing with anyone below a VP in title and did actually cause customer relationship problems. So sometimes there are business justification for titles outside of employee relations.
Personally with the impending changes in the industry I feel like I'm better positioned as an engineering manager than an IC. If the bullish predictions come true and software development teams shrink dramatically or disappear I will not just be a developer - I'll be a manager. There is still an entire world of industries not impacted as much by AI - I could manage a team of mechanical engineers or conservationists or business analysts. These skills are more transferable outside of tech.
Bad advice. You want to have at least one managerial role on your resume before you turn 40/45/50 so you can get hired as you age, and being offered one is something that doesn’t happen often. It’s far easier to go back to IC than to hope someone offers you an EM role later. I say take it while the offer is there.
There’s far less age discrimination when you’re looking for management and strategy oriented roles. Those roles want experience, not the raw energy, output, and fresh skills of a younger IC.
There’s far less age discrimination when you’re looking for management and strategy oriented roles. Those roles want experience, not the raw energy, output, and fresh skills of a younger IC.
> You've probably seen this tweet - the creator of Claude Code asking why Anthropic still needs software engineers:
In fact that is the creator of claude code answering, not asking.
In fact that is the creator of claude code answering, not asking.
There is so much going on in the industry right now that it is not fun to be an EM with rusty tech skills. However, the claim that staff engineers are more in demand is unsubstantiated. Hiring will slow to a crawl as everyone is watching to see where this is going. The EM role is not being replaced as fast by agents as much as the IC role, simply because EMs don't have as much to gain from agents yet.
One thing I will say is: I wish I had had some EM/hiring experience before starting a startup.
My technical skills served me very well in year 1/2, but once we started hiring enough people I could definitely feel my lack of experience.
Maybe big tech EM experience wouldn't have helped me a lot, the context is definitely very different, but at least it would have been some sort of baseline to draw from.
My technical skills served me very well in year 1/2, but once we started hiring enough people I could definitely feel my lack of experience.
Maybe big tech EM experience wouldn't have helped me a lot, the context is definitely very different, but at least it would have been some sort of baseline to draw from.
Totally agree, completely different skillset. Every engineer I've seen "promoted" as such becomes miserable, and frankly is not very good at their new role, effectively making it a double loss.
It's totally different skill sets yes, but some developers can become good managers.
Honestly, I’m pretty good at it but yes indeed quite miserable, particularly now, in this market. With hiring very slow, companies know people are trapped.
Some people seem to genuinely enjoy being people managers and excel at it. It's not always obvious in advance who those people are so I'd still recommend people try it out early in their career if they get the opportunity, particularly if their company allows them to back out if it's ultimately not a good fit
Flagging due to being an advert in disguise.
> Here are the main arguments from our conversation:
> Thanks Unblocked for supporting today’s article!
> AI coding tools are fast, capable, and completely context-blind. Even with rules, skills, and MCP connections, they generate code that misses your conventions, ignores past decisions, and breaks patterns. You end up paying for that gap in rework and tokens.
> Unblocked changes the economics.
Yeah I was reading through this going... huh? This is the same font and layout as the article. uBlock let this slip through. Maybe there's good content here, and maybe they need advertisements to pay the bills (as a well-paid Engineering Manager...) but I couldn't finish the article knowing that it was deceptively formatted.
> Thanks Unblocked for supporting today’s article!
> AI coding tools are fast, capable, and completely context-blind. Even with rules, skills, and MCP connections, they generate code that misses your conventions, ignores past decisions, and breaks patterns. You end up paying for that gap in rework and tokens.
> Unblocked changes the economics.
Yeah I was reading through this going... huh? This is the same font and layout as the article. uBlock let this slip through. Maybe there's good content here, and maybe they need advertisements to pay the bills (as a well-paid Engineering Manager...) but I couldn't finish the article knowing that it was deceptively formatted.
If you're reason to not become an engineering manager is because you live so much under a rock you're unaware of a glorified MCP ensemble tool blowing up as number one, then you're not really fit to be an engineering manager in the first place, and obviously not a very enthusiastic engineer at that.
I don't get this argument: don't do it, you have better otptions, but it is good for me because i enjoy it.
This article periodically surfaces in some shape or form. There's this idea that there's a "dual ladder", and the IC ladder offers just as much respect and compensation as the management one. This is a lie, and the sooner we stop telling it to the young generation - the better.
Human societies have always rewarded and valued those who built hierarchies more than those who built things. If you focus on building a thing - you will forever be a cog in someone's big project. There's a reason that management ladder is more competitive.
Human societies have always rewarded and valued those who built hierarchies more than those who built things. If you focus on building a thing - you will forever be a cog in someone's big project. There's a reason that management ladder is more competitive.
I think some places pitch the dual ladder a lot morethan they actually support it, but it's still there.
EM vs IC are totally different jobs though. The whole thing where you're a good IC, so you get "promoted" to being an EM is insane. There's some overlap, I guess, every job has pieces of managing other people even if it's not in the job description, but...
Just because EM offers higher positions in the hierarchy (and salaries etc to go with it) doesn't mean that accepting a "promotion" to being an EM is going to make your life better. Personally, I hated being an EM; I don't like the work, and I don't like that when I do a bad job, it directly impacts the careers of my reports.
I don't mind being a cog in someone's big project; but even if I did, I don't see how being an EM avoids it, unless you start your own thing, which I absolutely do not want to do.
I'm pretty sure I did well enough for myself in the IC track. I could have gotten bigger compensation as an EM, I suppose, but diminishing returns wouldn't have justified the additional stress. Obviously, that may depend on individual factors, everyone's path is their own and I got a lucky draw.
EM vs IC are totally different jobs though. The whole thing where you're a good IC, so you get "promoted" to being an EM is insane. There's some overlap, I guess, every job has pieces of managing other people even if it's not in the job description, but...
Just because EM offers higher positions in the hierarchy (and salaries etc to go with it) doesn't mean that accepting a "promotion" to being an EM is going to make your life better. Personally, I hated being an EM; I don't like the work, and I don't like that when I do a bad job, it directly impacts the careers of my reports.
I don't mind being a cog in someone's big project; but even if I did, I don't see how being an EM avoids it, unless you start your own thing, which I absolutely do not want to do.
I'm pretty sure I did well enough for myself in the IC track. I could have gotten bigger compensation as an EM, I suppose, but diminishing returns wouldn't have justified the additional stress. Obviously, that may depend on individual factors, everyone's path is their own and I got a lucky draw.
> There's this idea that there's a "dual ladder", and the IC ladder offers just as much respect and compensation as the management one
It is not a lie. It is true IF you live and work in the Bay Area, Seattle, and TLV - which represent the bulk of tech industry employment.
Companies where the underlying stack is a revenue generator and not a cost center are companies where these kinds of dual tracks exist, but these are only found in the major tech hubs and are not available if you are remote first.
They also require you to be both technically and socially adept.
It is not a lie. It is true IF you live and work in the Bay Area, Seattle, and TLV - which represent the bulk of tech industry employment.
Companies where the underlying stack is a revenue generator and not a cost center are companies where these kinds of dual tracks exist, but these are only found in the major tech hubs and are not available if you are remote first.
They also require you to be both technically and socially adept.
>It is true IF you live and work in the Bay Area, Seattle, and TLV - which represent the bulk of tech industry employment.
Is that actually true (the bulk of people in the tech industry are working in "big tech" or startups)?
I don't know if there's any hard data around this, but my understanding has been that people working for these types of companies are maybe a single digit percentage of all tech workers (if that).
People working for those companies are certainly the most vocal online, though, which maybe skews perception.
Is that actually true (the bulk of people in the tech industry are working in "big tech" or startups)?
I don't know if there's any hard data around this, but my understanding has been that people working for these types of companies are maybe a single digit percentage of all tech workers (if that).
People working for those companies are certainly the most vocal online, though, which maybe skews perception.
Sorry, I guess we'll have to agree to disagree. The ladders are simply not comparable, even in the Bay Area. Sure, at the entry point where one transfers from the IC ladder to management compensation can even drop. However, that's the bottom rung - and one typically can't get straight into management as a new grad. The management ladder goes higher.
Best to remember this isn't a ladder but rather a tree. Yes, it goes much higher, but you chances of ever getting there is minimal because it narrows so quickly.
I mean, this is true and also not true. The management ladder does start higher and arguably does end higher with C-suite titles (though even that may not be the case, e.g. Google now has a Chief Technologist or two, who are SVP/C-suite level). But at the major tech companies under discussion in the parent, yeah the levels do map basically 1:1.
You can maybe argue that it's easier to advance on the management side, and I think that was certainly true pre-2023, but since then there's been a clear tightening of easy empire building advancement, and at least in my neck of the woods, I've seen IC-track advancement has been faster from staff to principal than from manager to director.
You can maybe argue that it's easier to advance on the management side, and I think that was certainly true pre-2023, but since then there's been a clear tightening of easy empire building advancement, and at least in my neck of the woods, I've seen IC-track advancement has been faster from staff to principal than from manager to director.
Oh no, someone might be "stuck" as "just" an IC manager for years, making a comfortable salary to provide for their family and their retirement.
Not everyone wants to move up. Some people are happy doing a job they're good at until the times comes to move to something else.
Not everyone wants to move up. Some people are happy doing a job they're good at until the times comes to move to something else.
The IC vs EM debate always skips the third option: neither. Start something. You end up writing code, managing people, doing sales, and shipping product in the same week. Way harder, but you never have to wonder if the ladder is worth climbing because there is no ladder
Tbh, lots of EMs/VPs in wild that only behave like salespersons without the actual context. I sometimes find it hard to justify them making as much as senior engineers but could be considered as a stress-pay for those meetings..
It is a precarious time to look backwards on the definition of the roles of an IC or an engineering manager and make any extrapolations to what those will look like in the future.
In my own team, I have seen ICs increasingly function like engineering managers, and even suffer some of the pitfalls of the role switch, as they change from reasoning about creating code to delegating to teams of software agents.
Increasingly, ICs are needing to understand the product roadmap more deeply, figure out how to spec a problem and constraints on a solution in the right way to get their subordinates to produce reasonable output, and be the communication bridge between other jobs functions and the entities actually producing the code.
I've also heard concerns of skill atrophy, as these team members spend less brain energy on language syntax, low level logic, etc, and more on interpreting abstract strategies to solving a problem and pattern matching those strategies against their software engineering wisdom.
If anything, ICs should consider that the skills that will make them successful managing agents might be the ones that have made first-level engineering managers successful: the ability to coordinate with other job functions, map implementation strategies to product and organization needs, and deliberately and carefully delegate and coordinate work of others writing the actual code.
In my own team, I have seen ICs increasingly function like engineering managers, and even suffer some of the pitfalls of the role switch, as they change from reasoning about creating code to delegating to teams of software agents.
Increasingly, ICs are needing to understand the product roadmap more deeply, figure out how to spec a problem and constraints on a solution in the right way to get their subordinates to produce reasonable output, and be the communication bridge between other jobs functions and the entities actually producing the code.
I've also heard concerns of skill atrophy, as these team members spend less brain energy on language syntax, low level logic, etc, and more on interpreting abstract strategies to solving a problem and pattern matching those strategies against their software engineering wisdom.
If anything, ICs should consider that the skills that will make them successful managing agents might be the ones that have made first-level engineering managers successful: the ability to coordinate with other job functions, map implementation strategies to product and organization needs, and deliberately and carefully delegate and coordinate work of others writing the actual code.
I came to read an article, and all I got was a crummy advertisement.
> Thanks Unblocked for supporting today’s article!
> Unblocked changes the economics.
> It builds organizational context from your code, PR history, conversations, docs, and runtime signals.
Is that article an ad?
> Unblocked changes the economics.
> It builds organizational context from your code, PR history, conversations, docs, and runtime signals.
Is that article an ad?
I took an EM role. About a year later they eliminated all EMs in the US and replaced them with people in Poland. So I guess take the EM role if you're in Poland.
I genuinely think everything would work far better without management, from what I’ve seen most managers make organisations need more managers…
Yeah. There's always such a lack of realpolitik in these discussions. They turn into endless bike shedding about what a manager is supposed to do according to some ideology of management, rather than the reality of the decisions managers are actually in control of and their actual tangible outputs.
I work at a tech-adjacent company with no middle management and no, it sucks even more. The work doesn't disappear, it simply gets divided and spread out over a lot more people, many of those with no real executive power. I don't even think this saves my employer any money in the long run.
The manager role is inevitable once scale reaches certain thresholds.
The author forgot one very important reason to go for engineering manager: the hiring process does not include X slow rounds of leet code.
In all honesty, I don't think I have met one dev that could be a manager.
Also from my perspective, the article doesn't make any sense.
Also from my perspective, the article doesn't make any sense.
This article is not very helpful, just like any sort of absolute yes/no advice. The ad in the middle that looks exactly like the "content" makes it worse.
Using OpenClaw as an example of exploding technology and why it's a bad time to move away from this (not sure how EM is a move away?) is ridiculous. And stating the career path is too competitive shows they don't really know what a true technical ladder looks like. Most organizations are going to have about as many staff developers as senior EMs and principal developers as senior directors. If it's stability you're after neither is particularly at risk in my experience, but I'd bet your CTO is looking to shake-up the domain of staff developers more than management with the AI hype train.
Using OpenClaw as an example of exploding technology and why it's a bad time to move away from this (not sure how EM is a move away?) is ridiculous. And stating the career path is too competitive shows they don't really know what a true technical ladder looks like. Most organizations are going to have about as many staff developers as senior EMs and principal developers as senior directors. If it's stability you're after neither is particularly at risk in my experience, but I'd bet your CTO is looking to shake-up the domain of staff developers more than management with the AI hype train.
// but I'd bet your CTO is looking to shake-up the domain of staff developers more than management with the AI hype train.
Well that's a given, isn't it?
The contemporary CTO is looking for quantitative proof of productivity increases via Agentic AI adoption based on things like delivery cadence or SLAs. Management is a qualitative function, and guaranteed to be skilled in 'mapping' their role to the delivery of value and reporting such things upward anyway.
Engineering Management are there to make firm commitments and reasonable compromises around the ability to deliver features generally already committed to hard dates by either Sales or by virtue of external market forces. How this is achieved using social and political capital alongside Domain Knowledge is the distinguishing factor between an IC and a Technical Manager imo.
Well that's a given, isn't it?
The contemporary CTO is looking for quantitative proof of productivity increases via Agentic AI adoption based on things like delivery cadence or SLAs. Management is a qualitative function, and guaranteed to be skilled in 'mapping' their role to the delivery of value and reporting such things upward anyway.
Engineering Management are there to make firm commitments and reasonable compromises around the ability to deliver features generally already committed to hard dates by either Sales or by virtue of external market forces. How this is achieved using social and political capital alongside Domain Knowledge is the distinguishing factor between an IC and a Technical Manager imo.
As someone who has been a coder/em/vp/founder for over 40 years.
The last 3 months of using Claude Code has convinced me that in order to have a job in software very soon you will have to a both a coder and an engineering manager.
It takes both of those skills to effectively manager AI, and managing AI teams is all it will be about within 2 years. Problem is if you dont understand coding, its hard to see the traps AI falls into. They are both amazingly smart, and incredibly dumb at the same time. Just like people!
The last 3 months of using Claude Code has convinced me that in order to have a job in software very soon you will have to a both a coder and an engineering manager.
It takes both of those skills to effectively manager AI, and managing AI teams is all it will be about within 2 years. Problem is if you dont understand coding, its hard to see the traps AI falls into. They are both amazingly smart, and incredibly dumb at the same time. Just like people!
There will always be a place for EMs and ICs. This goes back generations, there have always been labourers and managers of labourers.
Perhaps the balance may tip one way or the others due to AI but something else will come along and tip it back again.
Do what you enjoy and are the most effective at.
Perhaps the balance may tip one way or the others due to AI but something else will come along and tip it back again.
Do what you enjoy and are the most effective at.
For my friend specifically, staying on the IC track, becoming a Staff engineer and switching companies would have given him ~20-30% more than the EM promotion he was offered.
This is missing something... the friend wouldn't immediately become a staff engineer - that could take just as long, or longer, than a promotion to middle management.
At least where I am, the staff engineer equivalent (called Technical Fellow here) is considered Director or VP equivalent. In an engineering org of thousands, we have tens of these positions.
Or, if I've misjudged what "staff engineer" means, our next lower position would be principal engineer (typically 1 in 10-15 engineering ICs, roughly). And their salaries are in the ballpark of our engineering managers.
Anyway, all this sort of misses the point - it's two completely different jobs. I know plenty of people who don't want to manage people. Or tried and hated it. And plenty of people who are bored with coding and want a chance to put their management skills to work.
EDIT - grabbed this from another comment... - 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
We have fewer levels than that... - Engineering Intern - Engineer 1 - Engineer 2 - Senior Engineer - Lead Engineer - Principal - Senior Principal - Tech Fellow
So, staff is somewhere close to our Lead or Principal, who earn similar money as line managers. And only Principal+ are on a bonus plan (where all people managers are). For any of the lower ICs, a bonus is a rare thing (where for higher positions and managers, it's part of the comp package).
This is missing something... the friend wouldn't immediately become a staff engineer - that could take just as long, or longer, than a promotion to middle management.
At least where I am, the staff engineer equivalent (called Technical Fellow here) is considered Director or VP equivalent. In an engineering org of thousands, we have tens of these positions.
Or, if I've misjudged what "staff engineer" means, our next lower position would be principal engineer (typically 1 in 10-15 engineering ICs, roughly). And their salaries are in the ballpark of our engineering managers.
Anyway, all this sort of misses the point - it's two completely different jobs. I know plenty of people who don't want to manage people. Or tried and hated it. And plenty of people who are bored with coding and want a chance to put their management skills to work.
EDIT - grabbed this from another comment... - 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
We have fewer levels than that... - Engineering Intern - Engineer 1 - Engineer 2 - Senior Engineer - Lead Engineer - Principal - Senior Principal - Tech Fellow
So, staff is somewhere close to our Lead or Principal, who earn similar money as line managers. And only Principal+ are on a bonus plan (where all people managers are). For any of the lower ICs, a bonus is a rare thing (where for higher positions and managers, it's part of the comp package).
> It’s a bad time to move away from tech
Working at big tech these days I see EMs and directors playing with AI, building tools, contributing to codebase through AI agents. Today when there's less hiring and building the org, becoming EM doesn't mean moving away from tech
> The ladder is very competitive
Just like on IC path. You think that being a great builder will move you from staff to principal role? Nope. It's about setting direction, aligning people, finding opportunities. A set of skills that's very close to what managers do.
> The pay is lower
When you compare EM against staff engineers. Is EM and staff the same level? In some companies, yes. In some companies, EM is at senior or between senior and staff. So yes, on average it will be lower than staff, but EM is not a promotion, it's a change of career path.
In any case, if someone's wondering whether they should try EM role given a chance, I still say: go for it. Going back has never been easier, a lot of companies now cuts manager roles and allows people to move back to IC, so if you have a chance to become EM and are curious about it, give it a try.
Working at big tech these days I see EMs and directors playing with AI, building tools, contributing to codebase through AI agents. Today when there's less hiring and building the org, becoming EM doesn't mean moving away from tech
> The ladder is very competitive
Just like on IC path. You think that being a great builder will move you from staff to principal role? Nope. It's about setting direction, aligning people, finding opportunities. A set of skills that's very close to what managers do.
> The pay is lower
When you compare EM against staff engineers. Is EM and staff the same level? In some companies, yes. In some companies, EM is at senior or between senior and staff. So yes, on average it will be lower than staff, but EM is not a promotion, it's a change of career path.
In any case, if someone's wondering whether they should try EM role given a chance, I still say: go for it. Going back has never been easier, a lot of companies now cuts manager roles and allows people to move back to IC, so if you have a chance to become EM and are curious about it, give it a try.
Might be worth talking about peer respect. Do soldiers respect the West Point grad that hasn’t or doesn’t do soldering? Not really right?
Some won’t ever take that position out of sheer self respect.
Many EMs are not ready to roll their sleeves up and do the full work, they are only ever riled up enough to roll their sleeves up and begin hiring like a maniac or going batshit crazy with micro management. You see, we all saw you too at work. Just know that. This is the LinkedIn comment you won’t see to your stupid fucking work achievement post - fuck you. Morning rant over.
But for my real EMs, much respect :)
Some won’t ever take that position out of sheer self respect.
Many EMs are not ready to roll their sleeves up and do the full work, they are only ever riled up enough to roll their sleeves up and begin hiring like a maniac or going batshit crazy with micro management. You see, we all saw you too at work. Just know that. This is the LinkedIn comment you won’t see to your stupid fucking work achievement post - fuck you. Morning rant over.
But for my real EMs, much respect :)
// Do soldiers respect the West Point grad that hasn’t or doesn’t do soldering?
Yes, just like an Office Hierarchy there's an expectation that they respect the Rank - based on the caveat that the Officer/Manager doesn't confuse Rank with Authority.
Also, to clarify some previous assertions, VP title is often needed to empower a given member of staff to sign contracts on behalf of the company in certain jurisdictions or configurations.
Yes, just like an Office Hierarchy there's an expectation that they respect the Rank - based on the caveat that the Officer/Manager doesn't confuse Rank with Authority.
Also, to clarify some previous assertions, VP title is often needed to empower a given member of staff to sign contracts on behalf of the company in certain jurisdictions or configurations.
I’m going to be giving off: ”Grandpa screams at clouds”-vibe with this comment. But I’m so sick and tired of ads and popups online.
I’ve barely gotten far enough to be drawn in by the article and then I get a giant popup (on mobile) to subscribe to read more posts like this.
Put it at the very end and I might. I’ve made it a habit to just exit the article whenever this happens. Nobody respects each other’s time in today’s internet, more intrusiveness = numbers go up.
Rant done
I’ve barely gotten far enough to be drawn in by the article and then I get a giant popup (on mobile) to subscribe to read more posts like this.
Put it at the very end and I might. I’ve made it a habit to just exit the article whenever this happens. Nobody respects each other’s time in today’s internet, more intrusiveness = numbers go up.
Rant done
He makes good arguments, but so did all my managers throughout. I think EMs telling ICs to stay in the IC role is an age-old talk. To me, it sounds a bit like “the grass is greener on the other side.”
Although, I’m not disregarding his points. I’m just saying that this article feels less about the challenges of becoming an EM and more about the challenges of stepping down from EM to IC.
Although, I’m not disregarding his points. I’m just saying that this article feels less about the challenges of becoming an EM and more about the challenges of stepping down from EM to IC.
It's curious to see the rational argument against the emotional choice the author makes.
The critical piece here is the anecdotal (but true) insight that engineering orgs have been flattening over the last few years.
There are a lot of factors, but rarely discussed is the realization that senior engineers are completely capable and often willing of managing other engineers directly. The definitive text on this subject is literally called "Herding Cats" :facepalm:
In reality, senior engineers often have strong communication skills (albeit different than the styles of other management and leadership positions), very good time management, and likely can perform many of these 'soft skills' that engineering management is doing out-of-band from the teams directly responsible for shipping software.
The engineering manager role feels like it was borne out of a very west-coast ideology from another era responsible for removing agency from people based on dated stereotypes. There was a self-fulfilling prophecy wherein we said engineers aren't capable or willing to have agency to work across teams, manage resources, or communicate about career goals or blockers, and then plugged someone in the middle to take these activities away from engineers.
I'm exposed to a lot of teams with high-aptitude/techincal people that are not software engineers and almost never do you do see the equivalent of a traditional software engineering manager.
I wouldn't be surprised to see a continued and dramatic compression of these roles going forward.
The critical piece here is the anecdotal (but true) insight that engineering orgs have been flattening over the last few years.
There are a lot of factors, but rarely discussed is the realization that senior engineers are completely capable and often willing of managing other engineers directly. The definitive text on this subject is literally called "Herding Cats" :facepalm:
In reality, senior engineers often have strong communication skills (albeit different than the styles of other management and leadership positions), very good time management, and likely can perform many of these 'soft skills' that engineering management is doing out-of-band from the teams directly responsible for shipping software.
The engineering manager role feels like it was borne out of a very west-coast ideology from another era responsible for removing agency from people based on dated stereotypes. There was a self-fulfilling prophecy wherein we said engineers aren't capable or willing to have agency to work across teams, manage resources, or communicate about career goals or blockers, and then plugged someone in the middle to take these activities away from engineers.
I'm exposed to a lot of teams with high-aptitude/techincal people that are not software engineers and almost never do you do see the equivalent of a traditional software engineering manager.
I wouldn't be surprised to see a continued and dramatic compression of these roles going forward.
Unpopular opinion: either you manage people or you manage work/processes, you shouldn't do both. if you're an engineering manager, either you manage your people and let them be engineers, or you don't manage any people and you focus on engineering solutions and managing the solutions themselves.
Why unpopular? Sounds about right to me.
I understand that some people take the manager path for the title/pay and never understands that the role is about handle people - not the tech. But they will not be very appreciated or it's a very small shop.
I understand that some people take the manager path for the title/pay and never understands that the role is about handle people - not the tech. But they will not be very appreciated or it's a very small shop.
Because being a manager is the only way you can move up in most companies. And engineers who end up being engineering managers don't really want to let go of their former life, they'll end up managing people and doing the work at the same time causing all manners of issues. Of course there are exceptions, and the environment plays a factor as well.
>If you are a senior engineer, the bottom line is that I wouldn’t recommend the jump to management right now. I would wait a couple of years to see how things will look like.
> BUT, and it’s a big but - if your gut tells you to do it (and not your brain), if it’s truly a path you want to pursue - then go for it!
It feels more like the purpose of this article was to get the sponsored segment out than to actually give useful advice. Like how is this the conclusion?
> For my friend specifically, staying on the IC track, becoming a Staff engineer and switching companies would have given him ~20-30% more than the EM promotion he was offered.
Company promotions do not give a higher salary bump than moving companies. The friend could be at a company that pays less for all roles. Additionally, that visualisation does a low-high representation and doesn't take outliers into account. Staff engineer roles tend to have outliers when it comes to salaries. EM roles do not
If anyone wants some advice from an engineering director
* If you only want to become an EM for the money, you probably won't like it. It's the same as an engineer that's only coding for the money. The more you like something, the more you would want to learn it
* The EM title means different things at different companies. Some companies are only/mostly about line management duties. In other companies, you're expected to do project + stakeholder management. In other companies, you're also expected to do operations, budgeting and technical + business strategy. As you can see, it's different to an IC who is building software and there's more of a focus on the things around building software.
* Being hands on is one thing. But what distinguishes one EM from another is engineer empathy. If you're an EM on the team and haven't did a PR (with or without ai), then you have zero empathy for your engineers because you have no idea what it takes to build a feature for your team. Using LLMs improves engineer empathy, but you need to learn it despite it.
* AI/LLMs will change two main things: the ability for an EM to be more hands on and the way EMs design team processes. Just like it changes engineer's ability to code, the EM needs to think holistically on how the development process will change and adapt accordingly. Do you have a path for the team to use AI agents? Do you have ways to reduce meetings and achieve the same level of alignment with LLMs? This is the type of thing EMs will/should be thinking about.
* The career path of an EM is largely dependent on the growth of a company. You will only get "stuck" if your company is not growing. If a company grows, there will be a need to hire engineers, then hire someone that manages those engineers and eventually someone that manages those managers.
* The other thing about EM careers. Advancement also depends on how well you are fitting into the business. For small companies, being more hands on as an EM is better. For larger companies, fitting in well with the company values, culture and leadership principles of the company is better.
I really don't appreciate the author's lack of understanding on how engineering leadership works and the general gatekeeping in this article. Sure AI is changing things, but there's really no need to steer people away and gatekeep roles like this role implies.
> BUT, and it’s a big but - if your gut tells you to do it (and not your brain), if it’s truly a path you want to pursue - then go for it!
It feels more like the purpose of this article was to get the sponsored segment out than to actually give useful advice. Like how is this the conclusion?
> For my friend specifically, staying on the IC track, becoming a Staff engineer and switching companies would have given him ~20-30% more than the EM promotion he was offered.
Company promotions do not give a higher salary bump than moving companies. The friend could be at a company that pays less for all roles. Additionally, that visualisation does a low-high representation and doesn't take outliers into account. Staff engineer roles tend to have outliers when it comes to salaries. EM roles do not
If anyone wants some advice from an engineering director
* If you only want to become an EM for the money, you probably won't like it. It's the same as an engineer that's only coding for the money. The more you like something, the more you would want to learn it
* The EM title means different things at different companies. Some companies are only/mostly about line management duties. In other companies, you're expected to do project + stakeholder management. In other companies, you're also expected to do operations, budgeting and technical + business strategy. As you can see, it's different to an IC who is building software and there's more of a focus on the things around building software.
* Being hands on is one thing. But what distinguishes one EM from another is engineer empathy. If you're an EM on the team and haven't did a PR (with or without ai), then you have zero empathy for your engineers because you have no idea what it takes to build a feature for your team. Using LLMs improves engineer empathy, but you need to learn it despite it.
* AI/LLMs will change two main things: the ability for an EM to be more hands on and the way EMs design team processes. Just like it changes engineer's ability to code, the EM needs to think holistically on how the development process will change and adapt accordingly. Do you have a path for the team to use AI agents? Do you have ways to reduce meetings and achieve the same level of alignment with LLMs? This is the type of thing EMs will/should be thinking about.
* The career path of an EM is largely dependent on the growth of a company. You will only get "stuck" if your company is not growing. If a company grows, there will be a need to hire engineers, then hire someone that manages those engineers and eventually someone that manages those managers.
* The other thing about EM careers. Advancement also depends on how well you are fitting into the business. For small companies, being more hands on as an EM is better. For larger companies, fitting in well with the company values, culture and leadership principles of the company is better.
I really don't appreciate the author's lack of understanding on how engineering leadership works and the general gatekeeping in this article. Sure AI is changing things, but there's really no need to steer people away and gatekeep roles like this role implies.
god dam the ads on this website are embedded into the article in a way where you dont know what is an add or part of the article til you are finished. What the fuck. am not reading because of that
> he'd been offered a promotion, to an Engineering Manager role
Funny how this lateral move to another function is seen as a promotion.
I've done both for significant amounts of time, and rather than a blanket, utilitarian "dont become a manager", I'd go with the antithesis to that blog buried at the very end:
> So why am I still an EM [...] the main reason is that I enjoy my job
EM positions come in all sorts of shapes and sizes, and it's an entirely different function from that of a developer. I had tremendous fun being a manager in a couple startups, where left with lots of autonomy I could learn about, then experiment with better ways to deliver than "let's do 2w sprints" and ship shit. The human management was interesting, especially the continuous improvement side of things: it's especially exhilarating when you find something someone can do better and have a durable impact on their career ; it's especially tiring when you have to become something at the convergence of a psychiatrist, a referee and a nanny.
In large companies, the job isn't the same. You're stripped from autonomy and forced into a bureaucratic aspect of things. Dates are the main control dial that VPs have, so your main goal is to provide random dates, track random dates, make sure it's gonna be delivered at random dates, and make up excuses for why that date was not met.
After alternating a couple of times between the two functions, I figured development is what brings me the most joy, so I staid with it. But to each their own, and you might want to be a manager:
- if you have a true interest in the function, go fo it. There's a lot of learning to be done (the main problem with bad managers, I believe, is that they're thrown there because they were good devs, and they just make shit up rather than learn) and you'll discover things
- at the opposite side of the article's thesis, AI is a chance for you to innovate as a manager. The bureaucratic aspect I mentioned can be smoothed by it, and new tools mean a new way of working, so good times to experiment!
- don't just do it for the utilitarian side of things. Developing your career is important, but you also need to do it a sustainable way. Something I keep telling: it sucks to be good at something you hate. So do something you like.
- it is not my experience that pay is lower, Amazon paid SDMs more than SDEs, Microsoft pays them the same.
- titles mean very little. VP at MyFavoritePet who employs 12 people is not the same job as VP at Amazon. Principal (not principle - makes my eyes bleed every time) is harder to achieve at Amazon than at Facebook. Not because the job is more complex, but just because they define things differently.
Funny how this lateral move to another function is seen as a promotion.
I've done both for significant amounts of time, and rather than a blanket, utilitarian "dont become a manager", I'd go with the antithesis to that blog buried at the very end:
> So why am I still an EM [...] the main reason is that I enjoy my job
EM positions come in all sorts of shapes and sizes, and it's an entirely different function from that of a developer. I had tremendous fun being a manager in a couple startups, where left with lots of autonomy I could learn about, then experiment with better ways to deliver than "let's do 2w sprints" and ship shit. The human management was interesting, especially the continuous improvement side of things: it's especially exhilarating when you find something someone can do better and have a durable impact on their career ; it's especially tiring when you have to become something at the convergence of a psychiatrist, a referee and a nanny.
In large companies, the job isn't the same. You're stripped from autonomy and forced into a bureaucratic aspect of things. Dates are the main control dial that VPs have, so your main goal is to provide random dates, track random dates, make sure it's gonna be delivered at random dates, and make up excuses for why that date was not met.
After alternating a couple of times between the two functions, I figured development is what brings me the most joy, so I staid with it. But to each their own, and you might want to be a manager:
- if you have a true interest in the function, go fo it. There's a lot of learning to be done (the main problem with bad managers, I believe, is that they're thrown there because they were good devs, and they just make shit up rather than learn) and you'll discover things
- at the opposite side of the article's thesis, AI is a chance for you to innovate as a manager. The bureaucratic aspect I mentioned can be smoothed by it, and new tools mean a new way of working, so good times to experiment!
- don't just do it for the utilitarian side of things. Developing your career is important, but you also need to do it a sustainable way. Something I keep telling: it sucks to be good at something you hate. So do something you like.
- it is not my experience that pay is lower, Amazon paid SDMs more than SDEs, Microsoft pays them the same.
- titles mean very little. VP at MyFavoritePet who employs 12 people is not the same job as VP at Amazon. Principal (not principle - makes my eyes bleed every time) is harder to achieve at Amazon than at Facebook. Not because the job is more complex, but just because they define things differently.
//Funny how this lateral move to another function is seen as a promotion.
Not at all. IC salaries outside of the absolute top-tier companies are capped, and were traditionally always capped lower than any degree of Senior Management prior to the 2000s.
More to the point, they were capped illegally and in collusion with the main players in the game, completely separate from market forces.
This was ably demonstrated by the class action taken when five former software engineers sued Apple, Google, Adobe Systems, and Intel in a Federal District Court in California for colluding in an “overarching conspiracy” to keep wages low by promising not to poach each other’s employees.
https://equitablegrowth.org/aftermath-wage-collusion-silicon...
65,000 software engineers eventually claimed they were unable to jump companies for higher pay because of a series of non-solicitation agreements by the likes of Sergey Brin, Eric Schmidt, and Apple's Steve Jobs.
Outside of VC/PE funded American tech hotspots, this depression of salaries for IC roles still tends to be the case - particularly in Europe - for whatever reason.
Simply put, the promotion is in the remuneration; the lateral move in functionality is simply a required re-alignment of role and responsibility to meet the expectations of the 'Leadership' tier - something always distinct from original job function, be it in Sales, HR, or Engineering.
Not at all. IC salaries outside of the absolute top-tier companies are capped, and were traditionally always capped lower than any degree of Senior Management prior to the 2000s.
More to the point, they were capped illegally and in collusion with the main players in the game, completely separate from market forces.
This was ably demonstrated by the class action taken when five former software engineers sued Apple, Google, Adobe Systems, and Intel in a Federal District Court in California for colluding in an “overarching conspiracy” to keep wages low by promising not to poach each other’s employees.
https://equitablegrowth.org/aftermath-wage-collusion-silicon...
65,000 software engineers eventually claimed they were unable to jump companies for higher pay because of a series of non-solicitation agreements by the likes of Sergey Brin, Eric Schmidt, and Apple's Steve Jobs.
Outside of VC/PE funded American tech hotspots, this depression of salaries for IC roles still tends to be the case - particularly in Europe - for whatever reason.
Simply put, the promotion is in the remuneration; the lateral move in functionality is simply a required re-alignment of role and responsibility to meet the expectations of the 'Leadership' tier - something always distinct from original job function, be it in Sales, HR, or Engineering.