What I gave up to become an engineering manager | Hacker News Reader

What I gave up to become an engineering manager

emdiary.substack.com

81 pointskiyanwang74 comments

> I realized that although my one foot was in the new role, my other foot was still in the previous one. I needed to stop doing the old things to make room for the new stuff!

This is exactly why it seems to odd to me that many companies see management as a logical "next" step in someone's career. It is a completely different path and requires very different skills. At least, the way many companies have set up their company structure.

Any career progression involves changes in the nature of the work. If the new job involves doing the same thing as the last job then (while it might be a great job that you want to keep forever) it isn't career progress.

The reason that the progression is expected to be IC -> EM is because that is a path that leads to software people being managed by other software people. Alternate paths lead to less efficient managers because they tend to have critical knowledge gaps.

Let me add that it’s also an incentives thing. I’ve seen software companies where management is an entirely different career path, and it makes a lot of less talented ICs focus away from the work, jockeying for a place on the management train. And why shouldn’t they?

So if you want junior engineers to really try to learn and contribute don’t tell them “well, if you really suck as an IC and focus on socializing you can be the boss of everyone here”. It’s pretty self explanatory actually.

Totally agree! Especially the second point. Often on HN or reddit people complain that their managers are "only managers" without engineering experience and thus are incapable of understanding the various technical requirements needed for the project.

To be clear, I am not arguing there shouldn't be any changes. But when it involves effectively an entirely different skill set I strongly believe that something is not quite right.

Do note that I specifically said many companies, not all companies. I think there certainly is room for software people being managed by other software people. If this is done in ways where the managing people also do keep being involved in the actual work in order to keep their skills and, more importantly maybe, their perspective up to date with what is happening.

I see too many companies where this is not the case and I see ex-software people giving justifications based on skills and insights that have very little relevance with the current situation on the floor.

It involves a similar skillset. Especially if you see soft skills as something an IC should be capable of then you should basically have everything you need to be dumped into an EM role as an IC. If you don't the overlap is still quite substantial. And the companies of the world generally agree with the view that similar skillsets apply - that is why they keep promoting software engineers to be engineering managers. If the skills were different they'd promote more socially savvy individuals than you generally find in engineering.

For an IC the application of those skills will be quite novel. But that is what career progression is. Same skills, new puzzle.

Companies that see it this way, at least acknowledge that a good manager tends to understand the problem and ways of working of the people they manage.

> This is exactly why it seems to odd to me that many companies see management as a logical "next" step in someone's career.

That's because there's a clear career ceiling for engineering roles in those companies. They're in a mindset of let's say McDonald's management - there's no career track for cashiers, no "principal burger flipper". They see engineering similarly. It follows from there that the only way to go up is to go to the management.

Isn't this the mindset in almost all companies? (No need to name exceptions)

Not in software companies from what I have seen. They usually have a lot of steps after "senior developer"

That's a good observation. The career ladder also scales with the size of the company. I've seen many smaller shops where the ladder ends with a "lead dev" who is also usually some kind of mixed role (not purely technically) - project/team/product lead.

> They usually have a lot of steps after "senior developer"

They're also not the same roles. Usually roles (except fake titles) above senior are a completely different beast just as well. Staff / principal replaces things like architect, system designer and other positions we had in the past.

Companies that need to keep their software developers around long-term often introduce a (notionally) parallel career track with titles like "Senior Principle SDE L8"

I don't think it's just "notional". These people are usually put in technical charge of progressively bigger / more complex projects. They have a lot of clout, decision power, but not organizational/disciplinary powers, no direct reports.

Alternatively, I've seen a "senior principal" dev working effectively as IC in a technically very demanding project (specialized database engine).

I'm a 'principal SRE' which is a weird thing. More made up than the rest of the titles out there, at least. It exists in the void created by others, eliminating toil and such.

Basically champion firefighter in addition to what you describe. Arguably the role we'd have if there were many CTOs and they were still practicing, instead of getting showtime

Having worked in such companies, you basically end up as architect, or senior team lead, where management like tasks still take place.

You end up doing less coding, more mentoring, drawing diagrams or doing requirements analysis with the team output customers.

Yeah, that's exactly my experience. After switching from managing to a senior (L7) IC position at Google, most of what this article mentions continued to apply to my work.

> Companies that need to keep their software developers around long-term

I never get why companies are so fixated on salaries being tied to titles. People just do different jobs and you shouldn't need technical or people leadership to get paid more.

If someone is really effective at their job they don't need to be called (or do the work of) a principal engineer. Just pay the 10x engineer 10x.

What’s a 10x engineer and how do you measure that?

> and how do you measure that?

That's on a company's performance reviews... and so how do you measure salary increases, bonuses, anything? There shouldn't be a different standard to it.

The only difference is the engineer shouldn't be forced into a different field to get paid more.

> What’s a 10x engineer

It's just an expression I'd say. Can be 2x, 5x, whatever. Most of the time a good engineer is forced into management of some sort (technical or people) before the 2x mark (salary wise).

Generally speaking, there are hard, concrete pay bands associated with roles. As you progress through the pay bands there's less room for raises. There isn't an idea of "an exception" to this rule. There aren't special employees in the rank and file.

More frustratingly, for example quasi-governmental places, the total comp raise any individual can receive is a hard limit written in their rules. Even if you skipped 5 levels you couldn't even get that raise. That's why new employees are hired at a higher rate than existing employees. The only solution is to quit for a time and then come back to the org. Though maybe once every 5 years they'll do a realignment of pay bands.

Whether you're very left wing and want to lean on "elite theory" or more economically minded and want to call them "principal agent problems", it seems hard to avoid some employees having a lot of power in a larger company, and if some employees have a lot of power it's easy to see them using that power to them make their own jobs unfairly well paid.

All companies except the most successful companies in the world maybe.

It is about scaling, you either scale your work output as manager of people (Eng. Manager), or as designer of the higher abstraction (Architect). Technically you can also scale as IC by employing better tooling to make bigger impact quicker, unfortunately that rarely is encouraged in ladder-shaped companies.

How about just appreciation for the continuation of a good work? Titles aside, it should be no brainer increasing the salary by 30-50% periodically without changing the type of the job. Otherwise, people will leave, continuing the same type of job they enjoy at companies which pay 30-50% more.

There’s zero places in the world paying 30-50% more for burger flippers though. I just don’t think it makes sense to pay more over time because if they leave it takes about 3 days to grow a rookie to roughly the same skill level.

I meant experienced engineers who just enjoy engineering.

There is a ceiling to how much value you can add vs someone that is not getting a 30-40% bump. Your salary is going to be a formula based on the value you add to the company and their ability to find someone else to do that work for less. There are a lot of factors of course but the gist of it is if you keep doing the same work and providing the same value increasing a salary by a large percentage just doesn't make sense.

> There are a lot of factors of course but the gist of it is if you keep doing the same work and providing the same value

If only we do the "same" work and provide the "same" value in software. 90% of the time you're always doing something different and hence why estimates fail.

Someone that knows the ins and outs of an ever complex system will be worth the 30-40% bump. If it was so simple there would be a lot less stories about rewrites etc, which often occur because no 1 knows and maintained the existing system.

There isn't really a ceiling to great engineers, I'm not sure how you came to this conclusion. As an engineer, your knowledge base constantly expands, and building a well engineered system can make a product far better for far cheaper.

Knowing how an entire large or complicated product works can be very important, and can take an immense amount of time.

In fact, most engineering jobs that I've worked existed entirely because shoddy and poorly engineered products needed whole new product categories invented to make up for shortcomings.

> it seems to odd to me that many companies see management as a logical "next" step in someone's career

I was lucky enough to work at a company where one logical next step was to move into technical consultancy with companies, so rather than managing a project, you became the technical interface between the customer and the project. At best, this could involve conducting or facilitating some really fascinating collaboration both with the customer and the supporting devs.

It sometimes also involved myself and the PM doing a good-cop-bad-cop routine with the customers, which could be 'interesting'.

I worked for exactly one company in 35+ years that had a career track for senior engineers as an alternative to management. I would have taken that instead of going into management but I had long ago left that company.

Tangentially related: I've been struggling with the decision to go for the technical track or the management track in my current org. I'm lucky to work in a company that has a technical ladder (though one can certainly argue that everything above staff isn't really realistically achievable). Certainly has my preference.

But being in Western Europe, most companies don't have this, and with the current state of the industry, with somewhat regular lay-offs, if I have to change jobs and want to stay an IC, I'll basically have reached the plateau of where I can get career-wise. The only way to get past that barrier is becoming an EM.

I hate to even have the thought, because, purely on principle, it's the worst reason to become an EM. But career-planning wise, I'd be crazy not to.

Anyway, your post is another argument in the column to stay on the technical track a bit more, we'll see what life brings :).

As a Staff and higher engineer you may be paid on the level of EM or Director. So switching the career track as an engineer beyond senior in most cases will not lead to salary increase.

Second argument is the assumption that switching to management opens the doors to much higher salary ceiling. In theory, yes, but realistically there is a strong competition for high level positions, few of us reach those places, and there is a big chance that one will simply stuck at a Director level position till retirement. Think if you enjoy management so much that you are ready to replace ability and joy of building things with more meetings, budget discussions, and politics.

Particularly in Europe with our taxes the benefits of slightly higher income may not have a sensible impact on your life.

Of the given list, any innovative and competent staff developer should already have given up (1) and lost (2). Similarly for (3) if you're creating new designs and patterns of working it can be an uphill battle to get it socialized and accepted, even if/when it turns out to be just the thing that's needed.

  5. Building Things
  4. Focus Time
  3. Fast Feedback
  2. Conflict Avoidance
  1. Short-Sightedness

The other thing about (5) is that many managers think/feel like they 'built' something when their team did. Of course they were also part of the team, but some would say "Back when I was in ... I built..." rather than "my team built...". Taking it to the top a CEO may say they built such and such, but really they built the company that built it. So they created the conditions and directions/motivations but didn't make all the decisions along the way etc. This varies greatly though, some CEOs are super-technical and can get in the weeds on occasion and make a good call.

I'll leave one more point that many managers give up (but shouldn't):

  6. Keeping up with currently used and relevant upcoming tech
     to communicate effectively and make good decisions + plans

Middle management (eng. managers) is by far the worst role in software engineering. I either want to keep working and make my way through the IC ladder or jump directly from senior/staff engineer to be a manager of managers.

How will you ensure you have the skills to be manager of managers without every managing people before?

writing more code

Most managers I worked for in corporate setting didn’t really care for people. They were loyal to their superiors. And their subordinates were more or less tools for a goal. Most absurd situation was in my previous job where the company hired experienced manager as a developer and suppressed him on every occasion. My precursor and I left that place very quickly. So the people skills from my single data point are not the prerequisite for becoming manager. But again. I am single data point. Maybe there are places where managers care about something else than budgets, timelines and their own bonuses.

That's kind of beside the point - for the sake of argument, let's say managers only care about "budgets, timelines". It would still be a stretch to switch from an IC role to suddenly managing the "budgets, timelines" not only of a team but of a whole department

I am convinced, that the guys, who got promoted, know how to manage things. Even in toxic place I worked as an important IC I assisted doing project plans and technology roadmaps. The department things were same charts, but without technical slang and absolutely anonymized threading workers as an abstract number “headcount”.

"Generally, management of many is the same as management of few. It is a matter of organization. And to control many is the same as to control few. This is a matter of formations and signals."

Sun Tzu

> Middle management (eng. managers) is by far the worst role in software engineering

Like most middle manager roles, I think it's only good as long as you have a good team and a decent support from the company. If the team I work with is going to be bad I'd rather be the IC than PM 100%, at least I can get some stuff done and have a level of control.

The smart move is to run a small startup and then either make that very successful or go back to industry as somebody that can actually run a company instead of just a little team. Even the failure modes here are quite alright (freelancing, consulting, etc.). You learn a lot trying to make a startup work. And there's nobody else to blame except yourself. Whether or not you are a good manager is of course a different matter. There are a lot of mediocre managers out there; especially in big companies. The Peter principle is the sad reality of middle management.

My experience working as a principal engineer in a large multinational was pretty good. Even though there was a lot of pressure for me to stop engineering and start joining the power point brigade. I once did a headcount between me and the CEO. The number was 7. Three layers up, management was so detached from reality that it's not surprising that they ran the company into the ground. That company was Nokia. I learned a lot about how not to manage a company. My direct managers were excellent but generally powerless.

I became my own boss after that. I've learned a thing or two since then about managing other people and getting results from them.

> I've learned a thing or two since then about managing other people and getting results from them.

What did you learn?

I agree but some people seem to thrive on managing people or on the status upgrade of being called a manager that its worth it for them. Really depends on the personality. Overall though you're right - the pay gap isn't significant in most places and there's a bit more stress in being a manager I think. I'm sticking to IC till AI takes my job :)

Personally I think it may be the other way around: When you’re a first line manager you still have 1-on-1s with people who do real work and you can spend a lot of your days “connecting the dots” and really making a difference. One you get to the second level it’s essentially 100% politics. For me the next level where it gets interesting again is when you get to the strategic level: board or C-suite.

Still mostly politics at that level too, unfortunately.

But I agree at least there’s a chance to do something worthwhile.

Middle management IS about managing the managers - hence the "middle".

The name is meaningless and what you say is 100% untrue in my experience across banking, telco, government, retail, car manufacturers, insurance or energy distribution.

In same vein say Vice President in banks is no (vice) president of anything, just above Assistant VP (who is not assistant to anyone). Meaningless words on their own.

I guess its down to ego game - nobody ambitious would like to be called ie 'low manager' or 'assistant manager', that sounds like proper secretary position.

I think it’s the other way.

As an EM you’re closer to the product and the team that builds it. You have direct influence on the success and failure of the product and the team and it’s where most of the fun is. It’s a truly fulfilling role for those who are hands-on and love the wholistic experience.

Managers of manager and above are often in rarified air and have to cast their nets wide and farther to make decisions.

You have an illusion that you have direct influence. But the reality is you can replace the EM with a rubber duck and the engineers would still build the product.

On the other hand replace the engineers with a rubber duck and there is no product.

Re: 5. building things: The only thing that keeps me sane since moving into a leadership role is that the what I love about building, namely watching things that didn't exist-- begin to exist, still happens. I guess I'm more of a farmer now than a carpenter, but I'm still seeing my environment change in a way that I contributed to and take pride in. That includes not only watching our product evolve, but also watching our team grow.

If it's any consolation, this jump between contributor to manager exists in other industries.

I have a friend who is a senior ground worker (managing a team that digs up roads with a JCB/backhoe to put in eg gas mains) and he'd been asked to "go off the tools" to work in head office and was debating the pros and cons.

Even inside of Google, Amazon and others it's a huge mistake to not go into management if you want to maximize your power and compensation at the company. Don't fall for the trap of "parallel careers" even the highest level technical person can't hold a candle to the power or compensation of a VP or SVP.

Roles like Principle engineer or distinguished engineer and such are just a sucker's share of the bag and make me question, why isn't this dude an SVP or VP? Why did they have to carve out a special role for him? He's probably a good engineer and good at his job, but hard to work with? Maybe he has dirt on the CTO? Those are the questions that go through my head.

It also looks like that Principle/Staff engineers have to justify everything they do to get their compensation whereas VPs/directors have a lot of great excuses to brush off failures while keeping power.

The power dynamics are absolutely not the same, the VP can fire you or make your life hell. You can’t fire the VP.

This is so wrong for a number of reasons.

At any major tech company the total compensation is, in fact, parallel between both tracks. Most Staff/Principal+ engineers I have seen enjoy CONSIDERABLY better WLB compared to their management-track peers. In addition, they don't have to deal with random people drama nearly as much. If you want to get particular about it, that would mean that they are earning significantly more per-hour of work. How is this the "sucker's share of the bag"?

I really don't mean to nitpick but your misspelling of "principal" (as well as the commenter in thread) makes me suspect you are new to the industry.

Most important thing not mentioned: got a bigger salary.

If you didn't get that, you were skinned.

>If you didn't get that, you were skinned.

What if a (purely numeric) 'bigger salary' thereafter involved a 1.5hr commute? Each way. Or, a lower salary, but involves living in Europe?

Skinned? Only if non-monetary factors are equally included in the 'most important thing[s]' list.

Engineers going into management generally don't change jobs to do it.

The best manager I had never gave up on building things and getting deeply technical: he just spent half of his time asking around people if everything is good, and whenever he saw that somebody is stuck, sat down together and helped debugging the problem (and maybe helped finding people getting it unstuck).

About meetings: he put some ,,meeting''s in the calendar entry, becuase PMs loved taking his time unnecessarily (he was still available for meetings, just not all the time).

As a high level example Elon Musk talks a lot about his managing style at Starbase in his interviews with Everyday Astronout, and it looks similar: he always goes to the place which is most critical for the product and looks at the technical issues.

> 1. Short-Sightedness

> As an IC, my focus was on immediate tasks and technical details. I thought in terms of sprints and short-term goals, which are more predictable and easier to estimate.

> I wasn’t ready to think about the uncertainties around long-term plans, roadmaps, and quarterly goals.

Promoting to management people who haven't demonstrated skills at long-term planning, roadmap design, and goal setting? What the hell. Though that would explain a lot about the state of things, wouldn't it.

Here I am having to plan multi-year roadmaps, execute them, and consider quarterly progress as a lowly senior IC. If you're only thinking about and working on sprint-sized goals, what are you actually getting promoted for past junior level?

Congrats and I hope you will make a positive difference for your team. Non-technical managers of technical teams are the bane of my professional life so it is good to see "one of us" on the other side of the fence.

Good piece. I've done mostly IC work but have had a stint as tech lead, where a lot of this applies even if people management wasn't directly part of my role.

One thing I'm curious about as well is more on the zero-to-one side of becoming an EM: If you're a "junior" manager, it seems there's quite a dearth of jobs out there. Everyone wants someone with 2+ years of experience. It's the same old entry-level-with-experience hiring conundrum, just happening again in your career.

Anyone have advice in that regard?

> Anyone have advice in that regard?

Join a company as a senior IC, switch to EM then stay at least 2 years?

Yeah, except that "switch to EM" may not be easy. How many such opportunities you might have depends on the company.

Yeah, I suppose I should have added in my post that I assume that is the normal way, but was hoping for any more potential tips.

My biggest tip would just be to make it abundantly clear in your interview that this is a goal of yours. Some jobs will bounce you for that, but that’s good- you want to filter those out. Others will see it as a positive and you’ll come in with your manager and leadership already understanding the direction you want to grow in.

Managing people is such a wildly different skillset compared to engineering that it still puzzles me the former is the assumed "next step" for an engineer. Managing engineers is a facilitating job and should be viewed (and paid) as such. Companies valuing a principle engineer lower than the person managing the day to day of that engineer is a crazy bit of corporate legacy.

You can definitely be a hands-on manager who builds things, though that's often what's called a team lead instead.

"Team lead" is usually just "the first among equals" IC without any disciplinary power. It's a different role from a manager. It could be a stepping stone to management, though.

Many organizations don't distinguish the two.

And I’ve seen people who can be great team leads not do great at managing because it requires that “people management“ skill. It can be easy (or easier rather) to manage people that are all doing the right thing, managing gets hard when you have deal with people who aren’t meeting expectations.

That said, when you have addressed any issues and rectified them it can feel like a super power to get good work out of your team. Taking an idea, farming it out to the team, then seeing it all come together. It’s very rewarding.

Why did you move to management if you wanted to carryon coding?

2 different personality types, mindsets.

Becoming a better coder while also getting manager pay instead of moving to management is a thing ya know

Reply on news.ycombinator.com