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

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.

* 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.

> 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.

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.

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

- 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.

The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.

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 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!

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.

"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.

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.

- 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.

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.

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.

There's a short film going around that captures this perfectly. A guy uses AI to do what his whole department was working on, and instead of getting recognized, the org panics and pushes him out: https://youtu.be/O5FFkHUdKyE

The incentive structures in most companies are still built around headcount and hierarchy, not output. That's the real reason people get pushed into management -- it's the only path where more impact is actually rewarded.

Not to mention Anthropic has a huge conflict of interest in making you think nothing is wrong. And the author fell for it.

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?

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.

What tipped it for me is I spend most of my time managing agents now, why not manage some human agents too.

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.

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.

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.

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 fact that is the creator of claude code answering, not asking.

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!

Also from my perspective, the article doesn't make any sense.

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.

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.

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.

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).

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 :)

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

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.

> Unblocked changes the economics.

> It builds organizational context from your code, PR history, conversations, docs, and runtime signals.

Is that article an ad?

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.

> 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.

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.

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.

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.