From engineer to manager: what I love, what I hate | Hacker News Reader

From engineer to manager: what I love, what I hate

thoughtspile.github.io

292 pointssigna11200 comments

I have been a manager four times, twice at FAANGs. I disagree with a lot that the author says:

- The ladder isn’t really taller. Most EMs end up clustered at the equivalent of L6/staff engineer. Promotions to senior manager and beyond are situational and rare. Meanwhile, my peers on the engineering ladder get promoted when ready, without needing to wait for the stars to align. (I made it to senior manager, but I was lucky to be in a growth area.)

- The skills feel transferrable, but every pure EM I know who got laid off is still looking for work and ready to give up. Meanwhile, those of us happy to go back to IC roles have no trouble finding work. Corporate management cultures are actually incredibly variable across companies and not directly transferable. The single most transferable skill I know in this industry is Linux internals.

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

IMO the best thing about being a manager is that you get to spend a lot of your time thinking about the future, and you are more likely to be “in the room where it happens,” talking to and hearing from C-levels. It’s also the worst thing, because you see how the sausage gets made.

I do agree with the things the author dislikes, but they get better. As a new manager, the author possibly hasn’t yet run into the thing you come to hate the most: senior management in many companies is basically a high school clique. Behavioral problems that would get normal people fired are sometimes tolerated in VP, C-levels, even directors sometimes, and working in such environments is trying.

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

a) the roles are fewer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There are many different ways to grow beyond staff engineer:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> The ladder isn’t really taller.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It mostly masquerades as performance curves.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks

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

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

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

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

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

Thanks for this :)

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

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

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

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

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

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

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

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

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

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

This guy gets it.

Senior management often seems like a popularity contest.

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

I’m a problem solver and big picture thinker. I like working out the solution and helping solve the obstacles. The role that has always fit the best is “architect”, but it seems to be going away as a title. No matter, the need for the work remains.

But I’ve done a few of the other roles over the years. Team Lead/manager, Scrum Master, Product Manager (without the title). Here’s my take. A good manager requires a very different skill set to an engineer. The primary skill is to have extremely low neuroticism. The ability to make good decisions and present a calm and rational exterior under prolonged stress. 90% of lower level managers do not possess these attributes, and under stress, damage the team and company. If you want to be a manager, honestly assess how you respond to stress (particularly prolonged). Do you lash out at those around you? Hide or freeze up, unable to make a decision? Blame others and seek to protect yourself or reputation? These things, as boring as they sound, are the real differences between effective managers and everyone else.

I've noticed the most effective managers I've worked with came from calm low-stress countries with similar work cultures - maybe the key to solving crunch and burnout is to create a regulatory environment where a worker's entire livelihood (health, rent, loan payments towards public universities etc.) is not solely dependent on keeping their job?

"But of people aren't mortally afraid, they won't work hard enough!" - American capitalism

I once had a manager (not my direct manager) tell me "maybe some fear is good?" No, it's not. Fear is useful for outrunning predators, but it is a useless emotion for programming computers. Unfortunately that particular phrase had come to that manager from the CEO, so, yeah. That company is a mess of short termism and hasty irrational decision-making and constant thrashing / "why can't we execute on big projects". It's because everyone is so scared that they're just trying to survive, and rule number 1 of surviving is to avoid large unpredictable projects.

I detest this whole line of thought because it's completely at odds with the reality - that people, and especially programmers, are creative and inventive by nature and are the last people who would "do nothing" if not afraid.

Our CEO flew from USA to tell us that if we land that defence contract we'll be set. Of course the USA might ask the company to get rid of all the foreign workers (100% of the developers).

So he came to tell us to not worry, for now the company has money problems but soon™ the company will be doing fine and we'll all be fired!

How emotionally incompetent do you have to be to think this is good news?

I'm similar to you - jack-of-all-trades big picture problem solver - and have arrived at the same conclusion after managing for a bit over a year: stress resilience is the key skill. If you're an IC you can develop your career by learning new skills, domains etc. If you're a manager, career development becomes increasingly about personal development - maturity, perspective, emotional resilience etc. I suspect this in why seniority and interest in things like mindfulness meditation tend to coincide. HN will hate this, and I say this as a confirmed bachelor myself, but I wonder if parents make better managers because they are less likely to lose perspective and become stressed over things that don't matter in the grand scheme of things? Weirdly I seem to do my best managing when I've become emotionally checked out.

Turns out I'm pretty temperamental, and I privately worry that I'm just constitutionally ill-suited to management. I also struggle with the sometimes disingenuous nature of management - I'm not manipulating you, I'm motivating you! I wish I could just float around the organisation fixing problems, streamlining processes and re-jigging work systems...

> HN will hate this, and I say this as a confirmed bachelor myself, but I wonder if parents make better managers because they are less likely to lose perspective and become stressed over things that don't matter in the grand scheme of things?

Maybe! I've had good managers who were and weren't parents. I'm a parent, but don't enjoy managing.

> Weirdly I seem to do my best managing when I've become emotionally checked out.

A perspective approximating objectivity is exactly what techniques like CBT try to teach you: seeing things as they really are, without your emotions coloring it.

> I wish I could just float around the organisation fixing problems, streamlining processes and re-jigging work systems

That exists. See the solver staff engineer archetype. I suspect it exists more at larger orgs who can support the role effectively, though. But, I think that is me as well. I enjoy being dropped on stalled projects/difficult technical tasks, unblocking it, and moving to the next thing.

In my experience most "big picture thinkers" are actually just saying things with no idea of what they mean, what the consequences are, how to actually do them, and why their idea is bad.

> A good manager requires a very different skill set to an engineer. The primary skill is to have extremely low neuroticism. The ability to make good decisions and present a calm and rational exterior under prolonged stress.

This is one of the best summaries I have seen. It is also why it feels so similar to parenting: a good manager needs the ability to be the grown-up. This usually involves unfun things like calling out the elephant in the room, letting people air grievances about your decisions in a group, and staying engaged with people even when they're disengaging and pushing you away.

To me, management always felt like it was something that required all my spoons, and it wanted more, no matter how much I gave. I feel this more a lack of fit than something intrinsic to management, though. FWIW I have moderate neuroticism (according to rando Internet surveys). I suspect I'm not good at simply letting things be good enough, and the broadened responsibilities of management present an emotional scaling issue.

> I suspect I'm not good at simply letting things be good enough

You might be overly hard on yourself here. Everything is a spectrum. My usual failure mode seems to be excessive patience when folks aren’t delivering. It is extremely bad when you let it fester. Lots of stuff doesn’t matter, but when important things aren’t happening, you really need to jump on it fast and insist on the high bar.

this. this right here.

And here I am, 12 years into my career as a software engineer, never, ever, wanting to be a manager. I just want to build things, I don't want to manage them. I see what it is like to be a manager as I work closely with them, and I just don't find it appealing at all.

As a senior engineer, my words also often matter, but I don't have the huge amount of responsibility that comes with being a manager, which is nice. I want less stress in my life, not more.

I guess my next 30 years in this career will be the same position I am in currently.

Senior engineer is fairly low. At some point you may get tired of stagnating salary and being told what to do all the time.

They are higher technical positions that have no or very little management responsibilities (up to senior principal engineer, architect, etc). It depends also on the company and how much they value you.

Best I have seen is engineer with PhD and decades of experience be the research/architecture guru, no team, no direct reports, a lot of Matlab, and be "VP of technology" in a company of several hundreds.

Stagnating salary? Every job change comes with around 20-30% raise usually, so I would not call it stagnant. Managers are also being told what to do, by those above them.

Since I do not work for FAANG companies, but rather small-to-medium (regular?) tech companies, they mostly never have principal/architect roles. My current role, in most cases, is actually the highest IC role there is.

If you remain 'senior software engineer' your salary will be constrained by the market range for that position.

When you get to the top of the range your salary will only increase in line with inflation/market forces whatever you do. It's not possible to get 20-30% more every time you change job unless you've stayed a long time in your current job and they were taking advantage of you (in which case those 20-30% represent what you were actually losing).

As for titles, obviously what I meant relates to what the actual role entails. 'Senior software engineer' is usually not very senior, in my experience this often means a dev who can be left alone to deliver the specific feature they were tasked to code. As for "highest IC role there is" again, if the job description is very senior you can also negotiate commensurate title and pay.

So what? Chasing money in life is utterly stupid long term strategy, if somebody told you this they were lying to you (or deeply unhappy people who went that way and instead of admitting the mistake they just drag others in same pit). Literally everybody who achieved anything serious in life says so. Yes it sucks when you don't have them at all, but once over that they should never be the top priority.

Do what you like, and for most normal humans (TM) moving to managerial position is moving to worse job while paid marginally better. More stress, far less interesting creative work and more baby-sitting/micro-managing incompetent folks, chasing other teams, processes, politics etc (if you don't do that you are not really a manager in any bigger company).

I am software dev for 20 years, my current full time employment net salary is over 20x compared to my first full time employment while doing largely the same job. You don't get good increases by moving up the ladder, you get it by switching companies and negotiating hard. That's it for the money part.

My point is that if you want to remain IC then why limit yourself to stay close to the bottom of the pile when you could aim for better pay and more impactful and interesting work?

It's not about chasing money for the sake of it but in the real world more money always helps if you can get it. In this case this also goes with better job satisfaction.

A 20x salary increase in 20 years means either fantastic career growth up the ladder or so-called "developing country". No-one gets that kind of increase in a developed country just by moving company, or at all, really.

Yeah. There’s no way I’m going to hit 1.6M annually when my first job was $80k/year.

I’d have to live somewhere with hyper inflation to do it on paper, but that’s just being dishonest with the numbers.

20x increase happened to me as well. My first full-time coding job paid around 2.5k PLN after taxes, while my highest paying job so far paid around 50k PLN after taxes. That was over the span of a bit over 15 years, with low inflation over entire timespan.

Poland falls into the "developing country" category over the time period.

It started out with salaries much lower than in Western Europe and has been catching up since.

For 20 years ago the job market for software was a lot different.

It was right after the dotcom bust and before the FANG world.

30-40k was a fairly common starting salary for a software engineer (mine first job was 44k in 2003).

20x would still mean you're on the high end of engineer pay now, but it's not totally crazy.

but yeah unlikely we see that again.

20x over the last 20 years is pretty exceptional but 10x would be fairly easy.

You started out at non-tech company at $35k in 2004 (right after the dot com bust) then ended up at a big (non FAANG) tech company in 2024 for $350k.

I’m in that ballpark. Granted I’m staff, but I know seniors making just a little less.

> If you remain 'senior software engineer' your salary will be constrained by the market range for that position.

The salary range is somewhere from $100k to $600k in the US depending on the company. So if you hit the cap at your current company just move to one that pays more. If you've hit that limit at a top tier company then you can start moving to higher IC roles such as Staff.

"you start moving to higher IC roles such as Staff"

QED.

I don't understand the nitpicking. It is factually impossible to get 20-30% salary increase forever if you move every 2-3 years while remaining at the same level. You'll get to the top end fairly quickly.

The person I replied to who said this has happened to them has only been in the industry 12 years. So, yes, they started as junior, then eng, now senior engineer, they moved maybe 3-4 times. But now if they stay at "senior software engineer" level then things will taper off.

The only senior (L5) engineer making 600k TC is one that has been at senior for several years and stock appreciation brought their RSU value way up.

The high end for L5 is like half that.

Netflix would disagree.

Netflix is indeed an outlier and has always paid higher than the rest of the market since it's such a shitty toxic place to work and in a terrible location to boot.

Even they aren't hiring someone looking at L5 at one of the other big companies at 600k. They'll be much higher than the other companies though.

/All/ the current and former Netflix engineers I've talked to talked glowingly about working Netflix. I'm supposing there's a lot of self-selection. And they've recently started hiring remote.

Netflix is in a great location. Obviously it might not fit your preferences but don’t act like it’s in a war zone or something.

> Senior engineer is fairly low. At some point you may get tired of stagnating salary and being what to do all the time

Or not. While I acknowledge that the mindset of chasing eternal growth and riches professionally is very common, is not hard to imagine a subset of people that are happy with staying in one rung of the ladder and get meaning from things outside their career.

Senior engineer is a "terminal" position at most companies, and certainly is not a bad spot. Only around 15-18% of engineers were above that at my last big tech company if I remember correctly.

Senior is the last IC level where you can pretty much exclusively focus on the technical work, in most cases. You can be very successful doing this! Staff and above roles can vary widely, but most of the time you're expected to have a multiplying effect on the team, which requires a lot more soft skills.

If a company has too many engineers above senior you run into a problem where everyone is looking for impact, but no one is doing the actual work!

>Best I have seen is engineer with phD and decades of experience be the research/architecture guru, no team, no direct reports

While we're at it, does anyone recommend going for PhD in EECS fields for someone who doesn't like at all to be in academia or do "research" (aka read pdfs, write proposal/papers, code up and run simulations)?

> does anyone recommend going for PhD in EECS fields for someone who doesn't like at all to be in academia

Feels like you're answering your own question. No.

Agreed. It's nice to be "Senior engineer" when you are 28. Not when you are 38 and being lorded over and over-ridden by "Staff Engineers" with half your experience.

Frankly I don’t care. If they want to take the responsibility then go for it

Not everybody wants to get promoted to their level of incompetence. Some of us want to stay at a level that we are good at, and not endlessly climb a ladder.

That's true but it also implies that you are led / bossed over by people are typically incompetent.

Nothing of the sort has been written or suggested in this discussion. This is bizarre.

> At some point you may get tired of stagnating salary and being told what to do all the time

Managers don't get told what to do all the time? Since when? Managers just get it from both sides. If you don't know about all the stuff your manager is dealing with from people above them, or from other managers in the organization: good! That means they're doing their job shielding you from that. The manager is telling their reports what to do—okay, I guess so, sometimes. But just as often they're adapting their plans to what their teams tell them can or should or has been done. And they're also being told what to do by people to whom they are direct reports. People who are, in my experience, much more demanding and much less collaborative than most managers themselves are with their teams.

I've been a manager, and I stopped all that because it felt like I had more bosses and less agency than when I was an IC.

I don't think the good takeaway is to "never be a manager", more of don't be a corpo manager of stuff that's someone else's vision. It's not the difficulty of the learning or necessarily the people but the circumstances that surround it.

I think having management perspective is excellent to understand the contexts behind what is being built and why things are seemingly inefficient and broken. Gives more insight into solutions and what may not be effectively communicated. Memes as usual.

In my opinion you don't have to be a manager to know all these things. In fact, every good senior engineer should be aware of what the leadership is trying to accomplish anyway, as we're not just code monkeys, but rather problem solvers. If this isn't actively communicated to you by managers themselves (it often isn't), then you should proactively ask questions yourself, as like you said, it would give more insight into solutions.

A manager does build things! It’s just that their tools are engineers :)

I already have daydreams about doing carpeting, as that would be something I'd actually do with my bare hands, so being a manager is 1 level even further removed from doing something with your hands. Manager building things is like saying politicians build countries. Technically not wrong, but not the kind of building I'm interested in doing.

I assume you mean carpentry, as installing carpet seems like a rough career, especially on the knees!

But even carpentry is hard on the body. Endless sawdust in your lungs, nonstop splinters, and of course spinning blades everywhere. We are very lucky that the biggest physical risk in software development is sitting down too long.

Carpentry yes, my bad! Oh yeah, it's less about carpentry in particular, more about the desire to do something tangible, with hands. Something that actually gets finished at one point. But yeah, software development is a very safe job, and we're lucky to get to do this.

What do you think the guy doing carpeting daydreams about doing? It’s not digging ditches, I’ll guarantee you that.

You can start carpentry any day! It doesn't have to be your job, and you might enjoy it less if it was. A hammer, a saw, some scrap wood, some nails, and pretty soon you've got yourself a birdhouse!

In a large tech company not really. The Product Manager or Staff engineers build things using other engineers. The Engineering Manager uses their blood and sweat to lubricate the corporate cogs to make that process a bit more efficient.

It really depends on the company. Google and Meta are horrible places to be an EM/ED (apart from the cash obviously)

How much your words matter as a senior engineer depend on your management. You’re in a good situation right now, but that can change. I was in a similar situation several years back. My boss liked me and had a lot of connections. He would make sure I was in the loop on everything, make sure I had a seat at the table when decisions were being made, and seek out my opinion on what direction we should go, and told me point blank I could speak for him or any other manager and he’d back it up if needed.

We have a whole new management structure now and they are very top down, have big egos, and aren’t willing to even entertain feedback. Vocal low level managers or engineers have been getting pushed out of the company left and right, so all the autonomy and the voice I had are pretty much gone. Even things that I thought were engineering decisions have been largely removed. I will need X to build what I’m building, so I make it and it worked. Then, months later, I’m told there is a different plan for X, I did it wrong, and I’m told to remove my solution (fully automated and hands off) in favor of a corporate process and manual work by other team, which is often missed, which makes my service less reliable.

I’m glad I’m not a manager who needs to fight with these people, as I’d probably be out of a job by now so they can replace me with one of their friends. That being said, I’ve found the influence of a senior level engineer to be highly variable, even within the same company/team, on a longer timeline.

I try to stay in the small-to-medium company bracket, and in this bracket, my opinion has been decently taken into consideration. Companies that have grown large enough where endless processes start to be introduced, layers of bs jobs get added between engineers and C-levels, I've just left for smaller companies. I don't make FAANG salaries, but I'm pretty happy.

I was the manager for my team for 6 months. It’s not that bad in the end but it’s a completely different job. I’m going back to IC next month. This was my first and probably last stint in my 15 year career

I’m a senior dev currently interviewing for a team lead position at a startup. While I consider myself highly technical, the things that frustrate me the most day-to-day are teamwork related. Lack of trust. Teammates who don’t want to talk to each other. Other seniors getting away with subpar work. Lack of clear team purpose and product vision. Lack of buy in on common engineering practices.

As a people manager these issues I care so much about would be within my sphere of influence and responsibility. For better or worse.

how do you think they will get more into your influence of work?

I felt this - a lot of the problems I've experienced with teams before could have been solved by the management.

In practise now I find that I am a Team Lead and yet I have far less ability to influence things than I thought. There are a host of people including my boss who want to run everything and expect me to be a rubber stamp.

In fact I get into shit more because I have to speak up for people in the team who are (unfortunately) rightly afraid to. Like "for a story to be ready we need the API defined" - how can QA work in parallel on automated tests when they don't know what to test? Scrum masters, POs, my manager, architects......they just talk whichever shit suits them today as if it was all self evident truth and tomorrow they're moaning about why the tests are late.

Basically you get into the politics of who is to blame for the state of affairs and the people who chose those directions and strategies are well connected and good at shifting blame.

I don’t fully agree with all points but there are many words of caution to be spoken about the expectation that by moving to a manager role you get more agency on the things that frustrate you as a sw eng. “The managers path” is a good resource to expand on that. https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

Sounds like you need to be a pain sponge, like Tom said in Succession.

> how can QA work in parallel on automated tests when they don't know what to test?

They can write the test cases based on the feature requirements with some boiler plate code in those tests

e.g TestUserSignUpIsSuccesful() {

   User.SignUp(email)
   User.Login(email)

   user_record = GetUserDetailFromDB(email)

   Assert.NotEmpty(user_record)
}

> how can QA work in parallel on automated tests

The real question is: why aren't they in the same team?

Man, people have a hard time talking to each other indeed. I might have to resort to some silly kindergarten games to make that happen

> Your words have weight. If you, an IC, say "guys, we really should write tests", everybody goes "oh, crazy old Vladimir, all grumpy again, haha, where do you see tests fit here?". If you, an EM, casually say "guys, we really should write tests", you might be surprised to find the tests unexpectedly growing in different places. Pleasant.

Many years ago, I was standing in my then-boss’s office while he got off the phone from an apparently successful request to have somebody in another department do something for him. He looked up at me from his desk, grinned slightly, and said in a bemused tone, “Well, I didn’t get any prettier when they changed my title to ‘Manager’ [from ‘Specialist,’ before I was in his team], but it sure helps me get things done.”

> guys, we really should write tests

Oh sure thing, assign another task to an understaffed inadequetly skilled team with a roadmap due yesterday.

As the senior IC on my team it’s my manager that asks me to bring things up with the team since they actually listen to me. Managers just get ignored unless they actually threaten you with consequences and you have to use that sparingly.

Senior here too. It's a mix - usually my manager pushes hard on the less in the weeds-type topics, and I push on those in addition to the lower level topics. I can say with certainty that neither my manager nor I are ignored.

I started as an engineering manager (CTO of a small startup) a few years ago; my life has changed a lot, and for every aspect you love and hate, I share the same feelings.

My additional advice here is to meditate. For real. Sit quietly long enough for your brain to switch off before making essential and impactful decisions that could harm your people.

In the beginning, you become a kind of parent-to-child genius. You have to accept them and also understand their ways. The more controls you put in place, the less control you will have, as they will attempt to jump around and oppose the unnecessary bureaucracy (I'll do the same, honestly).

My second advice is to always behave as if you are going to leave tomorrow. This will prepare your team and your peers and even improve your lifestyle.

> My second advice is to always behave as if you are going to leave tomorrow. This will prepare your team and your peers and even improve your lifestyle.

This is very good advice.

> My second advice is to always behave as if you are going to leave tomorrow.

In a similar vein, my ultimate management technique is to take leave and have my subordinates act in my position (for at least 2 weeks). It really accelerates their development and it's oddly reassuring to discover that I'm not indispensable. At the same time, I do wonder if it indicates that I'm doing something wrong given they seem to develop faster when I'm not there...

> you become a kind of parent-to-child genius.

Ha! I just recently became a parent, and the skills are highly transferable between EM to parent.

Some days I feel like I am employing skills learned on the job to managing my family.

My background is the opposite; I'm a mediocre software engineer but have quite good people skills. I'm experienced enough to know what takes time and which parts of the system are more critical than others. I have a few senior engineers whom I really listen to carefully and to whom I give a lot of trust and empowerment. I don't make design decisions, they do and I give input. I take responsibility when we fail (and learn from it) and give the team credit when we succeed. In my humble opinion, being a manager is more about people than anything else.

I think that's the optimal EM career path TBH. It's a shame many companies don't have an official middle-to- manager switch mechanism.

I like to think I'm a good fit, but of course, I need to improve my skills, like anyone else. At the end of the day, we are working with people, and there's no one-size-fits-all solution. Sometimes the most skillful engineer is the best fit for the EM position. However, I truly believe that to get the best output, you want team members to commit as a group and to feel that it's rewarding to achieve goals and have personal development. Unfortunately, not everyone has the luxury of a long-term perspective.

There’s only one reason (and only one) I would want to move from the coder/IC role to managerial track — and that is the white-boarding interview rounds that is needed every single time I want to switch jobs which needs (almost) excruciating preparation afresh - from scratch. (Yes yes, there are roles without that and that’s incredibly rare). Often, I just stay in the same job thinking of that preparation and saying, “oh god, not again!”.

A bad EM can do so much more damage than a bad IC. I don't think that's talked about enough. In my now very long career I've had 1 great manager, a few good/decent ones, and a lot of lousy ones. The lousy ones just make the job so much harder and sometimes outright miserable. A bad EM coupled with junior ICs can be particularly bad combo. At least as I got older I came to realize I can work with bad managers and help move things towards a better place, or bail if I feel it's hopeless.

How would you define that one great manager? What personality traits, behavior, skills made that person stand out? I'm curious as I'm getting more managerial responsibilities.

The key is to remember your job as a manager is to unblock your ICs and make sure they are working on stuff that matches their skills. It is not to: - Overrule them on technical decisions - Create extra processes to follow because you are insecure

Being a good manager is all about doing the minimum. That’s why you see comments earlier in this thread about leaving your team for a few weeks.

I once led a team of PhD level IC's. I had to find them work, keep away the dreamers and keep them happy. I would no joke spend sometimes six hours at a time talking to them individually, playing guidance counselor, playing the role of comforter. I never thought that would land in my job bucket! One of my guys helped win two separate 10 figure deals so my time payed off!

I have found EM positions (where you lead a team of 4-8 and your reports are ICs) to be way more stressful and don’t really pay much more. VPEngineering is where you get a meaningful pay increase.

In addition you need to keep up with the tech as you need to evaluate the skill level of people in your team plus they turn to you for advice.

And it is way more tiring. Keeping up with what many people are doing, at a technical level, plus all the people related stuff, bureaucracy etc. Needing to attend lots of meetings and sync up.

I agree it has a better career path for most, because technical career paths tend to either require a FAANG or maybe a ThoughtWorks or just massive IQ and effort to learn something like C++ HFT to rake it in. Or maybe be a sales engineer or growth engineer. Or founder.

But then again, c++ hft and payment processing aren't exactly low-stress jobs either

Yes indeed. My point was more that to make more money as a IC there are niches but there is no general track, but as a manager you stay at your crud webapp company and can manage more and more people.

The biggest pain is the people. You'd be surprised how childish grown ups can be. FFS just be adults and get along. 80% of my stress as a manager is basically solving playground squabbles between people old enough and experienced enough to know better.

Then of course the other 20% of the stress are your reports actively trying to undermine you, or publicly question your purpose/existence, or cut you out of decision making processes, going behind your back and contradicting previous agreements, trying to short-circuit or subvert agreed processes etc etc for above childish reasons.

Turns out that a lot of "professionals" are not professional at all and are actually pretty petty, spiteful, grudge-holding argumentative children who go into a strop (or as the article puts it "go lay on the grass thinking about their project") for a day or 5 if they don't get their way.

The rest of being a manager is a breeze though! 10/10 would buy again etc :)

Well, it's well known that to become a team lead you must eat the previous team lead)

To be fair, some managers over-optimize to protect against people undermining them, not sharing knowledge and responsibility and even actively removing top performers with leadership ambitions

Something I’ve noticed in the company I work for is that team leads which still write code is that they will take for themselves the high visibility projects.

I even think this is sometimes in good faith, as in "this is some serious shot, better handle it myself to avoid failure".

My favorite pattern is what I call "code sheriff" lead, who does all code reviews himself to prevent bad code from reaching trunk. Then proceed to complain how you can't go on a vacation because all processes stop.

Or worse, only do shiny and "fun" things that customers don't care about while ignoring all sorts of practical bugs/issues.

Not necessarily! You can just hang in tight and let someone else eat the team lead. In my experience it is often product people wishing to cosplay as tech lead (and they will promptly proceed trying do the same to you), or a middle manager/CTO (ditto).

> Then of course the other 20% of the stress are your reports actively trying to undermine you, or publicly question your purpose/existence, or cut you out of decision making processes, going behind your back and contradicting previous agreements, trying to short-circuit or subvert agreed processes etc etc for above childish reasons.

Frankly, this makes it look like you are indeed a problem that deserves to be questioned and bypassed whenever possible.

This sort of viewpoint is the perfect example - the short-sighted kneejerk "I know better" response that jumps to conclusions without taking into consideration (...or frankly even being aware of) any context or rationale or background info for why things are the way they are.

People like this cause problems and headaches for everyone as they are loose canons causing havoc, confusion, and wasted effort.

Congrats - you are very likely your manager's biggest annoyance.

If you think something is wrong or inefficient or whatever, talk about it with your manager or skip-level. Don't just take matters into your own hands and subsequently screw things up for loads more people by doing stupid things like entering into/cancelling agreements/commitments with other teams/customers etc because you think your manager is a bozo.

My thought as well. My manager loves it when I cut him out of the decision making process. It means less work for him and the whole point of having senior ICs is to let them take on those responsibilities.

> the other 20% of the stress are your reports actively trying to undermine you, or publicly question your purpose/existence, or cut you out of decision making processes, going behind your back and contradicting previous agreements, trying to short-circuit or subvert agreed processes etc etc

The worst part about this? It's just in some people's nature to do this. I'm a manager in the public service so it's basically impossible for even the CEO of my organisation to go "oh, that undermining backstabber guy is way better than spangry, let's fire spangry and replace him with undermining backstabber guy". And yet one of my reports constantly does this kind of thing anyway. It's utterly inexplicable.

As a team lead and manager, I've had SWE friends mention that management shouldn't even exist. Petty arguments, performance issues, termination, even sexual harassment reporting are things I've had to personally deal with.

Well that shouldn't be an issue in a professional workplace and functioning team, is the rationalization. I couldn't agree more! Yet, there's a huge gap between what should and does happen when a bunch of humans (sadly, mostly men) work together.

There are two ways to be a manager

You can think of yourself as a people manager agnostic to the org goals

Or you can think of yourself as the captain of a team leading them to victory

It’s helpful to know what someone means before trying to understand their thoughts on management

I've watched a colleague go from a good engineer, to a great engineering manager, to an awful project manager. I see him hating what his career has become and I feel terrible for him.

I've also seen horrible engineers whose code made entire teams miserable become amazing managers tho

For sure. It's absolutely NOT the expectation, but there definitely exist people whose talent is in people-managing with little to no domain expertise.

IMO, whether one of these individuals can be used is the distinction of whether a role is line supervisor or management. Line supervisors need the subject knowledge to teach fresh hires and know how to identify and fix problems caused by slackers. Management would rely on the senior employees for mentorship and keep their ear to the rumor mill to identify suspect underperformers.

That’s a shame, he can always try changing it up again.

I’m the opposite - engineer to manager, didn’t like people management side of it, changed to project management and loving it.

I do miss technical work though.

I really hope they do, but I'd hate to lose him as a colleague. Unfortunately it's likely to be one or the other.

> Suffering from front-end fatigue? Can't keep up with the newest shiniest frameworks and tools? Management's got you covered! The "hot new" agile / kanban / scrum methodologies are 20–30 years old. The basic meeting types (demos, dailies, 1-on-1s) have been developing for centuries.

> Frankly, after 4–5 years of working in a particular tech area, you can solve the vast majority of practical problems well enough. If you want some work challenge, you can:

I hate takes like these. "Good technical skills are dime a dozen, but management? that's the hard shit."

There's absolutely no lack of meaningful skills you can expand into if you're plateauing as an engineer. If you're a front-end engineer, go learn some design and product thinking, that'll help you give better input to other teams. Learn some scripting, and automate a bunch of shit. Learn some SQL and learn to query data on your own, instead of relying on others.

The best manager I had had a wide range of technical skills, so was able to make smart decisions since he had a very holistic picture of the codebase. Technical management shouldn't be about following methodologies, doing 1:1s, and being a middleman, it should be about making good practical decisions.

Not saying management is harder than engineering, at all. It's just another nice big area to learn something new.

Big companies tend to be quite prescriptive about role boundaries, so if you're an FE engineer, you can learn design and provide input as much as you want, but you won't likely get to design a new screen from scratch instead of your regular designer.

I mean, over the last few years as an IC I fiddled with CI setups and automated QA, wrote some CLI codegens, but after some time you really notice you start inventing problems to have some fun.

You're mostly right, but: depends on your manager.

I do let my FE engineers do mockups when they want. It is often objected by other people who wanted to do it (but didn't) or wanted someone else to do it (but didn't have time). But whoever is trying to make me and my team's job hell, will get the same treatment from me.

Yeah, and it's horrible advice. If you're an EM or higher, you still wind up making decisions with heavy technical impact, even if it's "this pitch from a Senior Engineer on my team is smart, let's do it."

You don't have to be the best programmer, but you need to be able to have thoughtful technical conversations with the in-the-weeds engineers, and represent their work to the wider org. If your mental model diverges with the day-to-day reality, your judgment breaks down along with it, and you're going to wind up being the problem instead of being an asset to your teams.

Also, ReactJS is 11 years old and going strong. Not exactly the "new JS framework every 2 weeks" world I keep hearing about.

> If you don't have anything urgent, you can go lay on the grass for half a day, thinking about the future of your project or something

Is this something common? I'm working as IC at FAANG for 6+ years in different teams, but I've never really experienced something like this. I've always been working on stuff that should have been finished yesterday.

> stuff that should have been finished yesterday.

I’m sure it depends on your org, but you can often choose how seriously to take that pressure. I’m also a FAANG IC and work is usually pretty relaxed. It’s a marathon, not trying to burn myself out. You really have to do near-zero work for a long time to get fired and it seems like promotions happen on a pretty similar schedule regardless of how hard people work.

Keep your commitments, but commit to less. If you want to get promoted do one good piece of L+1 work instead of trying to cram in more L work than everyone else. If your manager tries to manufacture stress to make you work harder, find a better manager.

> First, you can easily take on a team with a wildly different focus — mobile developers, infrastructure, ML engineers. You'd need some time to get up to speed on the big-picture technical struggles of your new team, but most companies would take this shot. If you don't want to be an EM any more, you're well-positioned to move to a project or product management role.

Have to comment that this is just completely wrong and we need to stop telling ourselves this. I’ve experienced a lot of pain with EMs who have no idea what is really going on in a codebase because they have little domain expertise, no idea what tradeoffs are made by developers, and, crucially, do not ever punch the keys and commit anything. Why? Because frankly, they already have the job.

If you don’t ever interface with the codebase and don’t really understand what it does, but you still feel so inclined to steer the ship, you’re a product manager, not an EM. Possibly worse because there is more credence given to you? This is most likely advice for someone who just wants to issue vague edicts to a team that frankly does not need them.

I've written about the opposite and the motivations behind it. Was hoping to publish it as a book, but after shopping it around briefly, didn't have any takers. I did post a few "chapters" if anyone's interested - https://www.zerolayers.io/p/wonder-ch1-p1

Perhaps the best anecdote I've heard on this topic came from an older COBOL programmer who went from being programmer to manager back to programmer.

I asked him why we went back. He said "The problem is that they nip at you from the top, and they nip at you from the bottom."

Meaning a programmer usually has one primary boss nagging. A manager has a boss above nagging and people below nagging.

> So, if you're tired of keeping up with the latest hot thing in tech, a management role can provide a well-deserved relief. Do keep an eye on what's happening on the tech side of things, but there's no urgency, and no need to get real deep.

This is such a poor advice. In any company that has a dozens customers, your team is likely to face technical problems. When your team faces a problem and you are unable to solve it, your team will notice that and they will stop looking up to you. In fact, any engineer who solves the problem will be the hero everyone admires. The approach mentioned by the author makes you a good "boss", but not necessarily a good "manager" or "supervisor" or "leader".

> Life of an engineer is relatively relaxed. If you don't have anything urgent, you can go lay on the grass for half a day, thinking about the future of your project or something. You can miss a few meetings on short notice, no questions asked.

In which company does this happen, I wonder!

If you want to build a decent team, you really have to relax your grip on the tech part.

You don't fix every problem yourself, but have someone who can fix it available. Otherwise, people don't grow, and you can't take a vacation. You totally need a general (middle / senior level) understanding of technology, but having a separate person with strong technical chops is key.

> In which company does this happen, I wonder!

As a staff engineer on a design system for a top 50 website, roughly half my job was detailing a tech roadmap and identifying what can break across the codebase, something you can do perfectly well on grass.

> When your team faces a problem and you are unable to solve it, your team will notice that and they will stop looking up to you. In fact, any engineer who solves the problem will be the hero everyone admires.

This is quite revealing. Being a hero, or being looked up to, might be some people's goals. But definitely not everyone's.

Somehow I managed to read the title as "From engine to engineer".

I moved from engineer to manager some years ago hoping I would get access to new tools to be able to push forward some necessary innovations, but it seems like I was constrained even more. Currently moving back to engineering and thinking that I should probably start my own thing soon.

>If you, an EM, casually say "guys, we really should write tests", you might be surprised to find the tests unexpectedly growing in different places. Pleasant.

I misread that last word as peasant. I felt simultaneously insulted and ready to write some tests.

Part your experience depends on your organization, as well as your disposition and predilections. My foray into management absolutely fucking sucked.

I was a shock absorber and clutch plate between team members and board/executives/senior leadership. On bad days I was the bearer of bad news or executioner. It was strictly a top-down affair; despite endless bloviating about open doors, open minds, and being empowered to lead and make changes, I was expected to do what they told me, keep myself and my team in line, and if I had any ideas they’d “bring it up in their next leadership meeting” (spoiler: they won’t, or if they do, it will be disregarded). Despite given a mandate, I had very little authority.

You also have to deal with idiosyncrasies with other managers. Lazy ones you have to pick up the slack for lest you become blocked. Bad ones who poison their team and create mistrust that spreads to others. Overeager ones that somehow seem to get their way or maybe have an easier department but who nonetheless get the attention of senior leadership where unfair expectations are placed on you.

The day-to-day was miserable. I’m highly technical and I like to get my hands dirty, being a manager vaporized a significant portion of why I enjoyed working at a tech company and mostly left me with the reasons I don’t. Being a Jira or spreadsheet jockey, filling out PIPs, IDPs, KPIs, budget proposals, expense reports, screening interviewees, managing petty squabbles between people, juggling PTO calendars, scrum bullshit, and endless fucking meetings. I’ve never been so busy doing what felt like so little. Sometimes it felt like I was babysitting people that, as a peer, I enjoyed working with.

I was also utterly repulsed by HR. I don’t know if HR has made a bad turn lately, was always like this, or my experience was just organizational, but these people are Stasi-like agents that seem to want you to spy on every little detail and use it against you and the employee. Yet when I actually needed them, e.g. conflict resolution, they were completely incompetent and insensitive, enraging employees rather than empowering them. They always sided with senior leadership, even when that person violated our own handbook.

Unlike the author, there wasn’t really anywhere else to go. Senior leadership doesn’t have a lot of openings. At best, I just get shifted around to other teams and maybe get dropped in one less fucked.

I enjoyed mentoring a lot, but sometimes reports looked to me like I’m a parent or a therapist and it was too much (and HR useless). I enjoyed strategy and design, but senior leadership was frustrating and frequently didn’t listen or involve me at all. I enjoyed delegating and giving reports opportunity for growth, allowing me to stress about the minute details less, but now my ass was on the line for the entire team which is waaaay more stress than just doing the work.

I generally chalk it up to me being a poor fit for the role in a dysfunctional company, but talking to other managers, it seemed my experience was not uncommon.

During my first year into Engineering Management I would have subscribed nearly 100% of what you said.

Then I began getting good at this job. I learned to delegate and was rewarded with empowered direct reports. I earned the trust of my boss and got more autonomy. I could implement some ideas of mine and see the benefits.

Very useful post for me to refer to in the future when transitioning into engineering management.

Archive link: https://archive.md/HqCSb

It seems OPs opinion is heavily influenced by their personal experience, and it doesn't generalize well. In fact I have the complete opposite opinion on several points

I can't generalize, but in my company engineers trust Staff engineers way more than managers. Everyone has informal authority, and from my experience engineers tend to respect other engineers more. As a manager you can ask people to do things, but there is no guarantee they'll do it. And if you need to resort to your formal authority to resolve something, things probably went wrong somewhere.

> Frankly, after 4–5 years of working in a particular tech area, you can solve the vast majority of practical problems well enough.

If this is the case, then you are certainly not pushing yourself hard enough. Maybe it's company specific, but right now in my team there is a neverending list of ever increasingly bigger and more complex problems. The idea that you can master everything in 5 years sounds extremely naive to me.

> Life of an engineer is relatively relaxed. If you don't have anything urgent, you can go lay on the grass for half a day

Please OP tell me where you work. I'd like to lay in the grass half a day, rather than being constantly pulled into 10 different directions and having to push back on new requests.

Are there companies that would hire you as an engineer for a team lead position without much prior experience? Or is the only way to transition within the same company?

The smaller the company the greater the chance of that IMO. I had to do it within my company and it was all a matter of luck, timing the right manager etc. Today it wouldn't happen again.

I think it's also not easy to do in a static situation where people have a fixed image of you and your talents in their minds. So basically I think you need to move around - if it's not happening for you in one place you need to find another.

I haven't had any luck applying to leadership positions without prior experience. Your best bet is finding a fast-growing product: when the team triples, you'll need some new managers. I got to move around 2 months into my IC job, and now my team has grown to have another 3 leadership slots.

But also make sure you're going to be happy if it doesn't work out. It's actually more likely at a larger company with established tracks IMO - hit the bullet points for next level/sideways move, say you think you've done so and that's what you want to do, be recommended for or apply internally for such thing. If you were considering leaving as an alternative plan then you presumably won't mind if that's in a different part of the org anyway.

“Team lead” can mean practically anything, but if you’re talking about an EM, I think most companies would be _extremely_ reluctant to hire one with no prior experience as an EM. A bad EM can completely ruin a team; it’s not something that you want to take any more chances with than you have to.

EDIT: re-read and saw that you have to find the weakest link every 6 months. That is awful.

As a manager of several years now, you missed one of the absolutely worst parts: "performance management" a.k.a. when one of your reports is repeatedly/consistently unable or unwilling to meet expectations and you have to put them on a Performance Improvement Plan.

Not only are PIPs a slog for you, they're absolutely torturous for your report. If you have a shred of empathy, it's tough. If you have a lot, it's agonizing. Add H1B status to that mix and you're possibly the person responsible for sending this person out of the country.

I had two years across two jobs where I inherited teams where many PIPs were called for. It led to me quitting the second job outright and nearly a year of sabbatical recovering.

Harming others is not why I became a manager—really the opposite.

On a good day, I get to help people grow and be a part of their victories. On a bad day, I'm at least indirectly responsible for their suffering and feeling miserable about it for at least days.

It can be a tough gig.

> As an engineer, I hated bloody corporate BS: individual performance reviews,

Good to have someone acknowledge that individual performance reviews are ineffective nonsense. I have seen little evidence to contradict this in organizations that I am familiar with.

The result seems to be that promotion is largely based on seniority, personal influence, random chance, or changing jobs.

I enjoyed the post and appreciate the author sharing their perspective. It's one of many valuable datapoints for anyone considering such a transition.

I agree with a lot, but like others - disagree with some.

My background: I've worked in tech for ~14 in all kinds of roles - from pure junior IC, through a "team lead" (something between an expert IC, a tech lead, and a manager), "tech lead," company's "technical architect" (highest level tech lead, peer to the technical director, but without any direct reports), and something akin to a tech director. Now I'm back to IC. Companies from small gamedev ones (80 people total, 15 engineers), medium gamedev (30 engineers and coding technical artists), huge gamedev (Ubisoft where you can have 100+ engineers and 1500 people total on a project), and for the last 7y "big tech".

The idea I would like to push back the most is that "your words have more weight". I have never had trouble getting my opinions heard, even if I didn't push them. Being the expert IC and "problem solver" sometimes I'd have even CEO asking me directly for advice and how to solve some issues (both technical and non-technical!). Not always following them, but I didn't expect that. Having an official title, in theory, you can use some "authority" to formally push those ideas. But... in practice, it does not work better. People will still go directly to the most technical experts. And if you abuse the position/authority/title (I hope I never did that, but that's not for me to judge...), it can cause resentment, pushback, and more disagreements. You will also hear less of gossip and honest feedback, to some engineers you becomes "not one of us anymore".

It can also destroy friendships. I had a great friend (meeting socially with our wives once a week, sharing interests) who was my peer and was then promoted to my lead. I still really liked them and wanted to stay friends. We always had technical disagreements (which were fine for peer ICs). Later, some of those technical disagreements and my bringing up issues publicly caused him to get bitter with me (as the upper management saw those and took my side on some occasions), and eventually stopped the friendship completely; after I left the company, they started ghosting me. :(

Similarly, on a few occasions, I agreed to lead/manage formally (in one case, it came from me - in other cases, I was asked to). I agreed because I thought, "Things are f-d up; I can solve them by being closer to the upper leadership and helping the team succeed." Man, I was so naive. :( I didn't have any more authority or power with the higher-ups, and there were more disagreements. They expected me to enforce policies I disagreed with. As you can imagine, this didn't last long, and I always ended up leaving the team/company and being super burnt out.

So now I'm happy to be a staff-level IC, an expert, and a "hacker," playing with problems hands-on and building my expertise further. The field grows so quickly that there is always something exciting and new to learn and do. I would happily be a tech lead of some project close to me (luckily, at Google and similar, it's flexible, per-project, and not formal), but I probably do not want to manage again. Maybe it will change, depends.

Reply on news.ycombinator.com