Whatever you do, don't seek to join a management track because you think it's the "next logical step" or some reward for being good at coding. It's not that. It's a different job.
Gather some evidence about whether you're good at helping people solve their problems. All sorts of problems. Problems not even having to do with work. Ask whether you're good at communicating up and down, high level and low level. Do you enjoy answering dumb questions and explaining things over and over again? Are you good at switching between topics that you didn't want to switch to, hour by hour? Do you like writing reports and managing projects and Gantt charts? Are you "a people person, I'm good with people dammit"?
Would you take the job if there were no pay increase? If the answer is no, then that's likely not what it's going to bring you -- it's probably going to bring you stress and dissatisfaction more than any potential pay difference. Of course, it may vary a bit by company, but this is often a reasonable caution.
Think hard before just jumping in. Managing people isn't what many think it is!
> Whatever you do, don't seek to join a management track because you think it's the "next logical step" or some reward for being good at coding. It's not that. It's a different job.
It is certainly a different job, but the reality of today's corporations is that outside of a few niches, it certainly is the the next logical step. It is also easier to move down to IC than the opposite (by changing jobs), and getting back in management if you have a good resume.
Yes, some companies have technical tracks where you can grow your career well, but the reality is those are few, and moreover, even when you have them, growing in technical track is actually much harder than the management track. And technical track involves a lot of meetings/discussions as well. E.g. there was recently a post on HN about principal engineer, and their job overlaps with what I do as EM quite a bit.
I have met many engineers who are around 50 years old, did not want to go into management, and they are fairly miserable. If you're a kernel hacker, sure, you will likely be able to get paid working on enjoying it until you retire. But otherwise... It ends up being consulting, 'architects', and other jobs that are not that much more challenging technically speaking than engineering management. They get paid much less, and have fewer opportunities.
Also, honestly, the whole thing about "management is a role, not a rank/title" feels like another trick by companies to low ball salaries.
While all that may be true, it's also true that in many companies once you become a manager you are empowered to take actual technical decision. It's the manager that chose technology, high-level architecture, development methodology, project management technology, evaluate feature vs quality, ... and most important, actually protect him and his team from the constant bullshit coming down and sideways.
Right before Corona hit us all there was a chance for me to grab a new minor management position in my group at work, where it was decided that we should create official ~5 person teams with a leader out of the whole group. I applied but ultimately didn't get the job (my colleague who did get it was more qualified ultimately for this specific task). And boy was that a good thing... now that I see everything that he had to take on in addition to what he did before, or rather what he is doing instead of what he did before, I am so glad I do not have to do that.
But I still worry that my (bigger) boss wants to push me in that direction as I now have to get certified in project/team lead management work, which will a. make it harder to avoid that kind of tasks in the future and b. makes me wonder how he sees the workforce and how he values people not doing that. In addition to that I feel that a lot of our IT projects, while they are often interesting to work on, tend to be dysfunctionally organized: they are almost always planned by calendar dates well in advance, then staffed, then the scope is decided on, then everybody scrambles to try to get it done in time.
Writing that I might need to look for a new team Anybody hiring SAP Consultants / ABAP developers with 10+ years of experience interested in a CRM-to-S/4 migration? :D
It IS that, money wise, in all the places where even the best employed developer does not even make close to 100k, e.g. all of Europe. Which is why a lot of managers in IT suck. They are previous developers that reached the developer salary ceiling. Then you can only become architect or some kind of manager.
One of my first development supervisor tasks was to talk to a developer about their body odor (there were complains from other staff). A few days later, after some super fun HR consultations, I had to send him home to shower -- and then repeat the same thing every few months.
> Gather some evidence about whether you're good at helping people solve their problems.
I mean following 100%: that is not what managers do. That is feel good theory of ... something. But, it is not what managerial work entails. Managers also dont explain dumb questions all that much nor explain things over and over again.
What you've listed resonates with me yet 10 years in I just can't break into management. I'm a high performer and am compensated super well. I've been told by others to "shut up and do your job, your pay is fantastic" but there is an inner yearning to help others be the best they can be and also compound the skills of a group to accomplish greater business goals, many of which I'm suffering to complete now under the tremendous stresses that seem unfair for one person.
This isn't the first time I've been in this or seen this situation play out. Businesses stacking an impossible list of responsibilities on one person until they burn out and leave, then get replaced by a manager and 2-3 others.
So I ask, for those of you who have intentionally made the move, how did you do it? I feel like I can't be any more transparent with the business that it's the direction I'm looking for and that I will leave soon if it doesn't happen. But then what, do I keep playing this game into perpetuity until my luck changes?
Management is a different job but a job with more power, authority and information. Managers will decide the compensation of ICs not the other way around. They will be the first to know of major decisions that company is taking.
As you grow experienced as an IC you want to say in the product roadmap. Usually that only happens at the management level.
Completely agree. The first time I tried it was a disaster - hated what I was doing and missed what I did before. A second attempt a few years later when I was ready and I thrived.
Same statement can be made for every career step. If your pay did not change, would you do the work of E6 at an E3 wage?
If I am moving to a position where I deliver more value to the company, then I should be paid accordingly. We need to move off this work for free trope.
I was a long time developer who became a manager. I chose to become a manager because I enjoy the people aspect of it. I see my primary responsibility to help my teammates be successful and deliver high quality products.
I considered taking a path through architecture but chose management because I felt like I could have a larger positive influence. As an architect I could design a few good software solutions but as a manager I can help coach a group of people who each go on to make great designs.
I do miss coding but I try and make up for it by setting aside time to pair program with teammates and perform “shadow PRs” (PRs that I review but don’t approve that I follow up with to see if there are things I missed that the team picked up on or vice-versa. I also set aside 2-4 hour per week of personal time to keep my skills sharp. I’m a firm believer that a software development manager should retain some technical chops.
Here are the values I try and live by as a manager:
1. Take less than your fair share of the credit and more than your fair share of the blame.
2. Commit yourself to the success of your team and your own success will follow.
3. Be transparent and honest.
4. Don’t be afraid to admit when you’re wrong.
5. Be decisive.
I've never really understood the "architect" role, maybe because I've always stumbled across poor architects, but I generally don't agree it is a good practice for someone to make decisions (architecture) and not deal with consequences (actually code within this architecture). Those decisions should be left for team to make and, yes, opinion of more experienced devs should be weighted more, but everyone should have a right to speak.
Something that connects with above statement: most architects are involved only at the beginning, which is so unimaginably stupid considering the fundamental truth about software development which is: "requirements will change".
Personally, if I hear from recruiter that they havea an architect in team I always say "thank you, but no thank you".
Oddly, I just went from a director level position to staff engineer at a new company, and am getting paid 50% more. I feel like I won the lotto. Management was stressful and full of nepotism. The only positives were being a bit upstream in the decision making process. I do think its good to for ICs to get out of their comfort zone and take on some management tasks though. Its important as you become a senior engineer, to not just contribute to the code but to also help mentor the team, sell a technical vision and take responsibility for delivering the product as a whole.
What type of process did you go through for this transition? I recently stepped into a director level position and have been loving the management and vision-crafting process, but have been curious that if I ever choose to step back toward an IC role, what that looks like in terms of interviewing/retraining/etc.
I find this hard to relate to in SV. I can't imagine a director ever getting paid 50% (or 1/3 - whatever the math is) less than a staff software engineer at the same company. Sounds more like you were going from a "director" level position at startup to staff at FAANG...
I would agree, it's awful I hate it. I used to produce high quality work all day and have fun. I thought it was the next logical step because my boss knew I was intelligent and I did big projects all on my own. Managing people especially older people has been awful, I'm not trying to be rude it is just what I've experienced. There are so many more things you have to care about and when I became a software developer I did it because I did not want to put on a smile for customers at a cash register all day. It's awful don't do it and don't get tricked by your boss when he calls it "tech leader."
> Managing people especially older people has been awful
I am really curious about this. What did you find awful about managing older people?
Generalising perhaps too much, I find older people generally easier to work with than younger people. They seem more sensible, like they have become comfortable with themselves.
At least in "corporate America", middle managers are often the first to go in layoffs because it's harder to directly attribute their work to the end product. And a higher salary puts a target on your back. It's harder to let go of the folk who are actually building your product without having an immediate impact.
> A team of talented ICs ships high quality work, but they have one or two very senior brilliant jerks. Other teams do not like engaging with these brilliant jerks so they avoid interacting with the team. Consequently the high quality work of this team does not have organizational impact.
Uuuugh that resonates so much with me. I've seen teams build stuff using evidently wrong infrastructure, just because the team responsible for the right infrastructure was dominated by a few pretentious bureaucratic assholes.
What sucks is that if you want to stay developer, people think you are not motivated. In other professions like doctors or lawyers, you can stay IC and no one says anything.
Even IC track is not exactly software development. As a tech lead, I do a lot less technical work, and spend a lot of time doing business processes. I wish we were a lot more like doctors, and focused on what we are good at doing instead of always going for next title on corporate ladder.
As a doctor, your are part of a big team managing people's health. Whether you are primary care or a specialist, you know that others are just as important to patient outcomes as you are. If you take that same attitude as a software developer, you'll realize that "management" is everybody's job. Those developers who don't are like little small town family doctors with no network. You'll probably do a decent job at keeping a small number of people alive as long as nothing goes wrong.
Post really resonated with me which is perhaps ironic given I’m looking to switch back to being an IC after 3 years. I think I got pretty good managing in that time (at least, got much better than I was). But at the end of the day, I feel the IC tracks pays roughly the same for much less stress. And it’s much more intuitively rewarding. Yes, coaching up someone and seeing them get a promotion is great. But it takes so long to get that payoff. Ultimately, for me it’s a question of happiness.
Plus, if you’re a good leader you don’t really need the title to affect change.
Total aside but the comment about joking “you’re fired”— does that actually happen? It’s just so...unfunny. In any context. Never mind being super inappropriate. I ask because this is the second post on software eng. mgmt that’s mentioned that exact point.
From my experience, I can say there are 3 types of managers:
- with little or no programming knowledge
- with moderate programming knowledge (they used to be developers long time ago)
- with excellent programming knowledge (they recently switched to management or they still develop)
...and it is really PITA to work with that group in the middle - they assume they know some technical stuff (but they don't or it is highly outdated), they underestimate complexity and they are always relating to the times when they used to write code with that passive aggressive narrative like he thinks he would do better.
Obviously I've made some generalization here, I bet there are exceptions.
It is pleasure to work with the first and the last group because the first one needs to trust development team and the last one just does.
Makes you wonder why some (too many, really) companies are putting SE managers through the same coding interviews that they do with junior engineers.
As it turns out, when you've been a manager for years and years, coding hasn't been part of your daily work for about just as long. And when you decide to join another company, to continue to work in a managerial position, there's gonna be just as little coding there.
But still they insist you to do the same cookie-cutter DS and Algo questions.
(Note: this obviously doesn't apply for every company - but there seems to be a lot of cargo-culting going on, and trying to generalize the interview process for everyone in the industry)
Was at a very fast growing tech company until a couple of months ago on one of the core teams and while we did put engineering managers through coding and design interviews, they were not held to the same standard as a staff or sr staff level engineer.
The main goal was to understand how they approached problem solving and handled things they may not know since that was a key ability we wanted in our managers. Managers still need to be technical, even if they aren't coding on a day to day.
So while the questions may be the same, the way they are graded/evaluated may not have been the same.
having the ability to code on a basic level is actually a desirable trait in a SE manager. It helps when communicating the day-to-day. It also makes it easier to have conversations surrounding technical debt
Many technical people end up in management simply because management is usually paid more for fewer hours. In some cases it's impossible to increase your salary unless you become a manager.
Moreover, it's a lot easier to see where you are in the management hierarchy, so the career "ladder" actually exists in a way that it doesn't on the technical side.
Two important observations not found in the article:
1) Top-notch programming talent is often paid more than their manager.
2) "They nip at you from the top, and they nip at you from the bottom."
Programmers have to deal with a manager.
A manager has to deal with subordinates AND a manager.
I've known several friends that tried both and preferred programming.
I've changed to the management track about a year ago, and this post resonates a lot with me. It has been one of the hardest jobs I've done.
On top of all this, the thing that gets me is that the feedback cycles get much longer, and you're never sure if changes are having the right effect until much later.
Hard and enjoyable sometimes don't go hand in hand. When you say hard, does it mean it's not also rewarding or enjoyable? I ask because I have been pushed to start working towards the management track by my managers but have always rejected it. I still don't feel the want/need to manage.
If you slightly shift your perspective and think backwards from "what does it take to get _products to market_" then the the question of management track vs. IC track goes away completely.
It would be impossible to pull off creating _any_ product, say an iPhone, unless you're willing to manage people at _some level_.
Most of the folks who drive innovations today have some form of management experience. They could end up _promoting_ themselves to being ICs again or stick to being managers. Some managers at big tech co.'s have come via acquisitions. Some others are ones who've been around long enough at places like Google or Apple and are capable of venturing out on their own. Examples abound: Tailscale, Humane etc etc.
How do engineering managers actually measure the productivity of their teams? This seems like a crucial issue for an engineering manager but it rarely seems like people are happy with how this is done or it's all just subjective.
If you're not very close to the money, that's very hard. You can measure the team's productivity, but going down to the individual level is difficult. The process is also fundamentally political in the sense that it is a zero-sum game: there is almost always a certain budget available, independently of how individual people perform. The best short description I know about the constraints of performance reviews was written by Sinofsky: https://medium.learningbyshipping.com/performance-of-perform...
This is something that has to be done, but I know very few managers who enjoy the formal evaluation periods. That's certainly the part I myself enjoy the least.
I was almost hesitant to click on this because of some of the not-so-helpful stuff I’ve read in the past on this topic. But I think the author really hit the nail on the head here.
If you’re someone who’s thinking about making the move into management.. I strongly recommend giving this a read. It’ll give you a sense of some of the responsibilities, dynamics, and challenges you’ll be likely to face. They all ring very true from my experience.
“Welp, you broke production. Pack your things, you’re fired.” Ugh, when was this humour ever funny? I'm a manager, I like to joke around with my team. There's a lot of comedic ground to cover before you start joking about people being fired.
You'd be surprised. I've seen a number of times where new managers used to just being one of the team don't realize that joking about performance, compensation or someone's job takes on a very different tone when they have some actual or perceived power over these things.
It can be funny when coming from one IC to another IC. Which I think is the point of that sentence. Jokes that may have been funny and have hit home when you were co-workers suddenly have very different connotations now that you might actually have the power to fire someone.
[+] [-] supernova87a|5 years ago|reply
Gather some evidence about whether you're good at helping people solve their problems. All sorts of problems. Problems not even having to do with work. Ask whether you're good at communicating up and down, high level and low level. Do you enjoy answering dumb questions and explaining things over and over again? Are you good at switching between topics that you didn't want to switch to, hour by hour? Do you like writing reports and managing projects and Gantt charts? Are you "a people person, I'm good with people dammit"?
Would you take the job if there were no pay increase? If the answer is no, then that's likely not what it's going to bring you -- it's probably going to bring you stress and dissatisfaction more than any potential pay difference. Of course, it may vary a bit by company, but this is often a reasonable caution.
Think hard before just jumping in. Managing people isn't what many think it is!
[+] [-] cdavid|5 years ago|reply
It is certainly a different job, but the reality of today's corporations is that outside of a few niches, it certainly is the the next logical step. It is also easier to move down to IC than the opposite (by changing jobs), and getting back in management if you have a good resume.
Yes, some companies have technical tracks where you can grow your career well, but the reality is those are few, and moreover, even when you have them, growing in technical track is actually much harder than the management track. And technical track involves a lot of meetings/discussions as well. E.g. there was recently a post on HN about principal engineer, and their job overlaps with what I do as EM quite a bit.
I have met many engineers who are around 50 years old, did not want to go into management, and they are fairly miserable. If you're a kernel hacker, sure, you will likely be able to get paid working on enjoying it until you retire. But otherwise... It ends up being consulting, 'architects', and other jobs that are not that much more challenging technically speaking than engineering management. They get paid much less, and have fewer opportunities.
Also, honestly, the whole thing about "management is a role, not a rank/title" feels like another trick by companies to low ball salaries.
[+] [-] levosmetalo|5 years ago|reply
[+] [-] cyxxon|5 years ago|reply
Writing that I might need to look for a new team Anybody hiring SAP Consultants / ABAP developers with 10+ years of experience interested in a CRM-to-S/4 migration? :D
[+] [-] Traubenfuchs|5 years ago|reply
It IS that, money wise, in all the places where even the best employed developer does not even make close to 100k, e.g. all of Europe. Which is why a lot of managers in IT suck. They are previous developers that reached the developer salary ceiling. Then you can only become architect or some kind of manager.
[+] [-] GartzenDeHaes|5 years ago|reply
[+] [-] watwut|5 years ago|reply
I mean following 100%: that is not what managers do. That is feel good theory of ... something. But, it is not what managerial work entails. Managers also dont explain dumb questions all that much nor explain things over and over again.
[+] [-] schoolornot|5 years ago|reply
This isn't the first time I've been in this or seen this situation play out. Businesses stacking an impossible list of responsibilities on one person until they burn out and leave, then get replaced by a manager and 2-3 others.
So I ask, for those of you who have intentionally made the move, how did you do it? I feel like I can't be any more transparent with the business that it's the direction I'm looking for and that I will leave soon if it doesn't happen. But then what, do I keep playing this game into perpetuity until my luck changes?
[+] [-] mlboss|5 years ago|reply
As you grow experienced as an IC you want to say in the product roadmap. Usually that only happens at the management level.
[+] [-] asplake|5 years ago|reply
[+] [-] PretzelFisch|5 years ago|reply
Same statement can be made for every career step. If your pay did not change, would you do the work of E6 at an E3 wage? If I am moving to a position where I deliver more value to the company, then I should be paid accordingly. We need to move off this work for free trope.
[+] [-] helmsb|5 years ago|reply
I considered taking a path through architecture but chose management because I felt like I could have a larger positive influence. As an architect I could design a few good software solutions but as a manager I can help coach a group of people who each go on to make great designs.
I do miss coding but I try and make up for it by setting aside time to pair program with teammates and perform “shadow PRs” (PRs that I review but don’t approve that I follow up with to see if there are things I missed that the team picked up on or vice-versa. I also set aside 2-4 hour per week of personal time to keep my skills sharp. I’m a firm believer that a software development manager should retain some technical chops.
Here are the values I try and live by as a manager:
1. Take less than your fair share of the credit and more than your fair share of the blame. 2. Commit yourself to the success of your team and your own success will follow. 3. Be transparent and honest. 4. Don’t be afraid to admit when you’re wrong. 5. Be decisive.
[+] [-] bladelessninja2|5 years ago|reply
Something that connects with above statement: most architects are involved only at the beginning, which is so unimaginably stupid considering the fundamental truth about software development which is: "requirements will change".
Personally, if I hear from recruiter that they havea an architect in team I always say "thank you, but no thank you".
[+] [-] jy2947|5 years ago|reply
[+] [-] eweise|5 years ago|reply
[+] [-] jwondrusch|5 years ago|reply
[+] [-] bradlys|5 years ago|reply
I find this hard to relate to in SV. I can't imagine a director ever getting paid 50% (or 1/3 - whatever the math is) less than a staff software engineer at the same company. Sounds more like you were going from a "director" level position at startup to staff at FAANG...
[+] [-] jcon321|5 years ago|reply
[+] [-] jlokier|5 years ago|reply
I am really curious about this. What did you find awful about managing older people?
Generalising perhaps too much, I find older people generally easier to work with than younger people. They seem more sensible, like they have become comfortable with themselves.
[+] [-] momokoko|5 years ago|reply
[+] [-] mprovost|5 years ago|reply
[+] [-] leokennis|5 years ago|reply
> A team of talented ICs ships high quality work, but they have one or two very senior brilliant jerks. Other teams do not like engaging with these brilliant jerks so they avoid interacting with the team. Consequently the high quality work of this team does not have organizational impact.
Uuuugh that resonates so much with me. I've seen teams build stuff using evidently wrong infrastructure, just because the team responsible for the right infrastructure was dominated by a few pretentious bureaucratic assholes.
[+] [-] zby|5 years ago|reply
[+] [-] jgeada|5 years ago|reply
[+] [-] amerkhalid|5 years ago|reply
Even IC track is not exactly software development. As a tech lead, I do a lot less technical work, and spend a lot of time doing business processes. I wish we were a lot more like doctors, and focused on what we are good at doing instead of always going for next title on corporate ladder.
[+] [-] darkerside|5 years ago|reply
[+] [-] khalilravanna|5 years ago|reply
Plus, if you’re a good leader you don’t really need the title to affect change.
Total aside but the comment about joking “you’re fired”— does that actually happen? It’s just so...unfunny. In any context. Never mind being super inappropriate. I ask because this is the second post on software eng. mgmt that’s mentioned that exact point.
[+] [-] bladelessninja2|5 years ago|reply
- with little or no programming knowledge
- with moderate programming knowledge (they used to be developers long time ago)
- with excellent programming knowledge (they recently switched to management or they still develop)
...and it is really PITA to work with that group in the middle - they assume they know some technical stuff (but they don't or it is highly outdated), they underestimate complexity and they are always relating to the times when they used to write code with that passive aggressive narrative like he thinks he would do better.
Obviously I've made some generalization here, I bet there are exceptions.
It is pleasure to work with the first and the last group because the first one needs to trust development team and the last one just does.
[+] [-] TrackerFF|5 years ago|reply
Makes you wonder why some (too many, really) companies are putting SE managers through the same coding interviews that they do with junior engineers.
As it turns out, when you've been a manager for years and years, coding hasn't been part of your daily work for about just as long. And when you decide to join another company, to continue to work in a managerial position, there's gonna be just as little coding there.
But still they insist you to do the same cookie-cutter DS and Algo questions.
(Note: this obviously doesn't apply for every company - but there seems to be a lot of cargo-culting going on, and trying to generalize the interview process for everyone in the industry)
[+] [-] SystemOut|5 years ago|reply
The main goal was to understand how they approached problem solving and handled things they may not know since that was a key ability we wanted in our managers. Managers still need to be technical, even if they aren't coding on a day to day.
So while the questions may be the same, the way they are graded/evaluated may not have been the same.
[+] [-] whoomp12342|5 years ago|reply
[+] [-] musicale|5 years ago|reply
Moreover, it's a lot easier to see where you are in the management hierarchy, so the career "ladder" actually exists in a way that it doesn't on the technical side.
[+] [-] RickJWagner|5 years ago|reply
1) Top-notch programming talent is often paid more than their manager.
2) "They nip at you from the top, and they nip at you from the bottom." Programmers have to deal with a manager. A manager has to deal with subordinates AND a manager.
I've known several friends that tried both and preferred programming.
[+] [-] mattchamb|5 years ago|reply
[+] [-] Jcampuzano2|5 years ago|reply
[+] [-] cafed00d|5 years ago|reply
It would be impossible to pull off creating _any_ product, say an iPhone, unless you're willing to manage people at _some level_.
Most of the folks who drive innovations today have some form of management experience. They could end up _promoting_ themselves to being ICs again or stick to being managers. Some managers at big tech co.'s have come via acquisitions. Some others are ones who've been around long enough at places like Google or Apple and are capable of venturing out on their own. Examples abound: Tailscale, Humane etc etc.
[+] [-] Jefro118|5 years ago|reply
[+] [-] cdavid|5 years ago|reply
This is something that has to be done, but I know very few managers who enjoy the formal evaluation periods. That's certainly the part I myself enjoy the least.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] mtc010170|5 years ago|reply
If you’re someone who’s thinking about making the move into management.. I strongly recommend giving this a read. It’ll give you a sense of some of the responsibilities, dynamics, and challenges you’ll be likely to face. They all ring very true from my experience.
[+] [-] jgeada|5 years ago|reply
https://news.ycombinator.com/item?id=24444644
also provides another perspective why choosing the management track has value beyond purely a salary motive.
[+] [-] hitekker|5 years ago|reply
[+] [-] te_chris|5 years ago|reply
[+] [-] huntsman|5 years ago|reply
[+] [-] anon98356|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]