[ilyanep]

I realize this isn't really the main point of the article, but it's something I've been thinking about a lot recently: Can someone explain to me why I should want to become good at management? I think most people on here (but sadly few company structures) would agree that engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter.

As someone with about five years of experience as a professional software engineer, I'm really still looking to level up my IC chops, along with a healthy dose of mentorship (mentoring interns or new hires on my team) and what I'd call "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things). I would basically worry about stunting my development as an engineer if I switched to focusing on management, and I'm not even convinced my role models for career development are really in primarily "managerial" roles (I'm thinking of both famously very good backend devs both at my company and at the big SV companies).

Separately, I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this. If anything, it kind of feels random: at an equivalent level of my unblocking the team and being a good manager, if I have an amazing 10x engineer on my team then the output is just going to be higher than if I have an average engineer. So in less clear-cut cases, how can I tell if I just did a good job at unblocking or if my engineers are really good? (This is not to say that I don't feel satisfied doing mentorship-style things or architectural advising-style things, but that feels separate to me. I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing).

I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies?

EDIT: I'd also just appreciate being told if I'm thinking about everything entirely wrong or something here.

EDIT2: This also isn't to knock people who _do_ enjoy doing these things, but it's not for me and I imagine it's not definitionally for every good engineer.

-----

Unrelated to the above, point 8 feels a little bit in contradiction to point 1. How does one keep learning their craft without direct experience?

[ryandrake]

What I've seen a lot is lots of companies do not have a meaningful Individual Contributor technical career track. You join as a junior developer, then 5 years later you are a "Senior Software Engineer" and that's it. Your salary flatlines, your project responsibility/impact is capped, with no further opportunities to grow career-wise. Join another company? Fine you get a 5-10% pay bump but you're still at the highest level: The dreaded "Senior Software Engineer". OK, so some places have a "Staff Software Engineer" or "Principal Software Engineer" or whatever they call it. It's still basically the end of the road for a non-manager. So few places offer anywhere to grow after reaching this level, besides management.

These companies then say, "Hey, engineer XYZ, you seem to be smarter than the average bear. We would like to reward you with career growth, but we are not imaginative enough to come up with something beyond Senior Software Engineer. How about instead we make you a manager? Go, here is a team of people, go off and learn this entirely different skill set and manage people! What could go wrong?" That's pretty much how most places make engineering managers, and it's tragic. Here we have some of the smartest, technically competent people. I mean they rock as individual contributors and should be thriving. But they're not because they don't want to be managers, they just want a software development career!

To me the solution is to simply let coders code and hire managers to manage, and provide equal career and salary growth to each group!

[purplezooey]

I wish more companies did this. We have such a hard time with this in our culture. Even at a company that has a good IC track, it's usually fake. The person eventually gets perceived as expensive and is laid off.

[tlarkworthy]

How can a lone engineer scale their impact after senior? I literally think the career ladder flatlines there because business value flatlines there too. It be nice if companies had work above it but I think it's hard.

[theshadowknows]

A friend of mine quit his job when they essentially forced him into management. To your point it would have been a slight increase in salary. But much more work that he didn’t enjoy and considerably less flexible work environment. You’re right these things should be obvious to companies. The things most good programmers enjoy and value are rarely the same things that managers, even good ones, are looking for.

[SatvikBeri]

> I think most people on here (but sadly few company structures) would agree that engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter.

I don't think they're orthogonal skillsets. A major part of management (arguably the most important part) is helping your team improve their skills, which works much better if you're a skilled engineer yourself.

> I would basically worry about stunting my development as an engineer if I switched to focusing on management, and I'm not even convinced my role models for career development are really in primarily "managerial" roles (I'm thinking of both famously very good backend devs both at my company and at the big SV companies).

Yes, becoming a manager will stunt your growth as a developer.

> Separately, I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this.

You probably wouldn't enjoy managing then.

> I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies?

Definitely not. Most big companies have separate technical and management tracks, and most developers shouldn't go into management.

> Can someone explain to me why I should want to become good at management?

The major reasons to become a manager are: (1) you can have a much greater impact on the business as an Xth percentile manager than an Xth percentile engineer, or even an (X-20)th percentile manager; (2) you enjoy teaching and watching people grow; (3) you're more interested in causing good software to happen than you are in building it personally.

[indemnity]

Great summary.

Only reason I’m in a half technical role instead of still in SW dev track is my company and the industry in my location does not generally have good career paths while staying an IC, so for sake of my family I’m doing this for the doubled pay check to put us into financial independence.

But I’d much rather be coding.

[alain94040]

Why would you want to move to management? The answer is scale and impact.

As an individual contributor, there is just so much you can add to the product. If you find a product that you deeply care about, and want to build great, large features for it, at some point it's easier to lead a team than to code by yourself.

In your case, with only 5 years of experience, I'd say it's typical to work as an individual contributor for at least another 5 years (10 in total). No rush to move into management yet.

[ambicapter]

It depends on the size of what you want to accomplish. If you're happy only accomplishing what one (even superhuman) individual can do, then you're all set. Necessarily, if you want to accomplish things that only a team can do (larger or more complex projects), you're going to have be able to manage people other than yourself.

[jonas21]

On the other hand, there are many projects where an average team of engineers will fail, regardless of how good their manager is, but that one talented individual contributor (or a handful of them) can successfully deliver. Managing more people doesn't necessarily mean having a larger impact (even indirectly).

[geomark]

Successes as an individual contributor are a great feeling, but not to the level of the amazing feeling you get when you successfully execute a strategy that requires coordination of a large number of people to perform a complex task.

I'm all about the feels.

[ilyanep]

But...am I accomplishing those things, or am I going to a lot of meetings about how to make the customer feel good about the things we accomplished?

[peterkelly]

I'm in the same boat as you. I'm a senior developer - it's what I love doing, and it's what I'm best at. I have absolutely no desire to move into a purely managerial role, but am happy to act as a tech lead where necessary. You're not alone.

[bonniemuffin]

You, personally, sound like you should probably not move into management; you should find a company that has big technical projects that need technical project leadership (e.g. architect, principal, tech lead IC roles).

For me, my goal is to optimize my career for impact, and I noticed what a huge impact good vs bad managers made on my life & on the whole team, so I decided management was a niche where I could really make a big contribution. I'm not sure if I can be a 10X IC, but I think I can be a 2X manager for a team of 5.

[mmirate]

> Can someone explain to me why I should want to become good at management?

You said half of it yourself: because transitioning from engineering to management entails a promotion.

(The other half: because at most companies, a promotion in turn entails a raise.)

[solatic]

> engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter.

Good management isn't just people skills, it's the ability to judge the output of your team so that you can keep quality high. Non-technical managers can't judge quality, only measure the team's self-reported progress against external requests for which they serve as gatekeeper. Non-technical managers lack a sense of how long requests will take to fulfill, which results in either a) agile-style workflows where ICs need to have daily meetings to explain to non-technical management why tasks take as long as they do, instead of technically-competent managers being able to reason estimated for themselves, b) unrealistic deadlines where non-technical management presses ICs to do the impossible, which inevitably results in sacrifices to quality, or c) continually slipping deadlines and an inability to ship. Companies promote ICs to management because you can teach people skills to engineers, but you can't teach the love of engineering (continually honing your skillsets) to professional management.

> "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things).

Otherwise known as a software architect, who spends his time diagramming up larger designs and communicating them to engineers, not writing code. Because of the inordinate amount of time needed to get people in your organization to align with your technical vision, as a software architect you will need many of those same "orthogonal" soft skills which management needs. If you want to spend your career being left alone to write code, then you don't want to be a software architect.

> I would basically worry about stunting my development as an engineer if I switched to focusing on management

Try to imagine the job of a head chef in a Michelin-starred restaurant. Would you say that his job is more managerial, or more culinary? Most people would say culinary, and few would assume that you could take somebody with a high school diploma, take a course in "Agile Kitchen Operations", and be qualified. Yet the job of a chef is very much more managerial. The chef spends little if any time chopping vegetables or stirring pots, instead the chef's job is to make sure that orders are moving smoothly through the kitchen and being made to the highest quality. That is a culinary profession, and engineering management is just the same, it is an engineering profession.

> I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this. If anything, it kind of feels random: at an equivalent level of my unblocking the team and being a good manager, if I have an amazing 10x engineer on my team then the output is just going to be higher than if I have an average engineer. So in less clear-cut cases, how can I tell if I just did a good job at unblocking or if my engineers are really good?

This is the fear of somebody who has served on a team with teammates who were incompetent (as have we all...), and not wishing to be in the position of their manager, who needs to live with the output of incompetent engineers. The reality is this: if you are a manager, and you think the people on your team are incompetent, and that no amount of mentorship or training will lead to the professional growth of said poor excuse for an engineer, then you should have the ability to fire them and replace them. The way that you can feel good about your output being determined by the people on your team, is either by handpicking them when you hire them, or putting enough of yourself and your experience into the individual members of your team that you start to see yourself in their output.

> I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing)

Platforms, tools, and APIs don't do nearly as much as "organizational empowering" or "unblocking" does. For whatever engineering output metric you choose, giving engineers good management will do a much better job of improving those metrics than giving them Yet Another Tool. Good management is hard, Yet Another Tool is just another magic pill sold to executives as a way of shortcutting their way to engineering greatness. When have you ever seen that happen?

> I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies?

Just like there are different types of engineers, there are different types of managers. You don't have to be the kind of manager who's in back-to-back meetings and sees her team only for morning stand-ups and weekly planning meetings; you can instead decide to be the type of manager who's much more hands on. You can choose which type of manager you want to be.

> How does one keep learning their craft without direct experience?

Eventually you get to a point in your career where you understand that there's rarely anything truly new under the sun. If you understand the discipline well enough - you understand how things fit together, how much time things are supposed to take, what good code and design looks like, how to react when production blows up, how to keep it all secure, etc. - then you understand that you don't need to have deep experiential knowledge of whatever newest tool your team is using to solve business problems. You understand further, that if that lack of knowledge really does bother you, you can decide to be the kind of manager who dedicates some time to reading documentation and code instead of going to back-to-back meetings every day of the work week.

[ilyanep]

Thank you for taking the time to write up this long response. That's definitely a lot to think about!