This trope of "growing" from an engineer to a manager needs to die. I grow as an engineer when I learn new stuff or become better at building things. Becoming a manager is changing jobs, not growth in any meaningful way. Not even in salary in many places
If you make it to my comment, please - do not go into management for the money. If you want to build, then remain an IC. If you want to grow other engineers, further THEIR career, make THEM better - go into management.
The friends of mine who ended up in management for the money and complain about their reports make me so angry.
I mean, this has a certain truth to it... but this isn't really a situation unique to management.
A lot of engineers, of all flavors, are at least partially in the field for the money. Maybe they enjoy their work, maybe they're good at it, but for a lot of people it was more of a plan C or D after the things they really wanted to do turned out to be something they couldn't make money at.
Some of them would rather be authors or musicians, some of them chemists or physicists, a number of them are just waiting to buy a goat farm upstate. If you include them people who would rather be engineering something else, but that something else doesn't pay the bills, it may be a majority of engineers who are in it for the money.
Sometimes, people are asked to become managers because their managers think that they have the right combination of skills and attributes to be good at the job.
And sometimes, the people who were asked, due to a combination of stubbornness and a desire not to “sell out”, deny the request for 7-8 years. Eventually, a person might realize that the original requesters may have been correct and that’s how they become a manager.
I think it’s perfectly reasonable to say that many people get into management for the money. My thought is that the motivation, the incentive, is wrong.
I’ve had too many shitty managers in my career to think I’d put other people through similar experiences. So, my switch into management was motivated by, hopefully, making the experiences on my team positive ones
Your point is that managers are more upwardly mobile, which is fair, but that doesn't mean when you make the switch it is a promotion. G9 IC -> M0 will not increase your salary. It does grant you more power, but that is not a promotion per se.
The other thing to watch out for is manager growth over the last 10-15 years was a result of the structural needs of an unprecedented tech bull run. Now that the industry has moved into belt-tightening mode, the heaviest scrutiny is falling on managers. The type of political games a typical 35 year-old EM (5 years coding, 10 years EM) may not be as effective as they were in the previous environment. There are a LOT of EMs getting pipped or knocked back to IC these days, whereas ICs with a bit of product/UX sense, ability to think a bit beyond their silo, and willing to work on "boring" business applications will continue to be highly valued, especially given the amount of dead weight that has found its way in by grinding leetcode.
That's a great insight. I hadn't considered how the bull run led to the current structure, as we switch from "keep this ship together while we grow" to driving operational efficiency.
<quote>
[From 1:49:53] Um, you know, at the beginning of this, we, um, I asked our, our people team, what was the average number of reports that a manager had? And I think it was, it was around three, maybe three to four, but closer to three. I was like, wow, like a manager can, you know, best practices that person can, can manage, you know, seven or eight people. Um, but there was a reason why it was closer to three. It was because we were growing so quickly, right? And when you're hiring so many people so quickly, then that means that you need managers who have capacity to onboard new people. Um, and also if you have a new manager, you may not want to have them have seven direct reports immediately because you want them to ramp up. But the thing is going forward, I don't want us to actually hire that many people that quickly, right? So I actually think we'll just do better work if we have more constraints and we're, um, you know, leaner as an organization. So in a world where we're not adding so many people as quickly, is it as valuable to have a lot of managers who have extra capacity waiting for new people? No, right? So, um, so now we can, we could sort of defragment the organization and get to a place where the average is closer to that seven or eight.
It’s true but for most people in practice they won’t make it to L8 either as IC or manager so it’s really more a question or do you want to finish your career as an L6 IC or manager.
Most people can get to L7 by mid 40s if not sooner. People who don't progress seem to do it based on choice (want less responsibility, unwilling to change teams to find more opportunities, etc). Careers don't end in people's 30s.
I’m sorry, but that comment is absurd. MOST people can make it to L7 in their mid 40s? Most people can’t even get in the door at entry-level trying their very hardest, hard-stop-period.
If there is any random variability in promotion guidelines or policies or even process, then the probability of advancing from level N to level N+1 approaches one over time. For many typical corporations, the policies change often enough that you will get promoted quite a bit higher than you intended, assuming of course you do your job, ensure that your work is useful, and get along with people reasonably well.
Is this the "if you type randomly type stuff you'll write Shakespeare given enough time" thing?
It might be true (though I doubt it), but the original claim is "by mid 40s". You also need to look at the overall statistics (i.e. percentage of people who made the promotion vs those who haven't), and while the projected ratio based on the previous company growth rates may still support the claim, it's quite clear double digit percentage growth YoY isn't infinitely sustainable...
It really depends. Our company (FAANG equivalent) has a lots of high ICs. There are lots of high level ICs because there are far fewer Techlead Managers who covers both sides. But tl managers are way too hard so most ppl pick one track to stick with.
High level ICs have LOTs of weights on the technical directions. They are not replaceable by the managers.
I would also say that being an engineer at L8 is a meaningfully different set of skills than L7. The whole ‘what got you here won’t get you there idea’ starts at L7 for either track…
I don't think what you described is a promotion? M1 = IC6, M2 = IC7, etc as you said. As far as the number of directors and VPs, sure there are probably more but I would describe that more as "it is easier to get promoted as a manager than as an individual contributer past IC6"
However... This is starting to change. We now have engineers reporting to higher levels, so basically each manager has an equivalent IC reporting directly to them. In theory this means the numbers are more equivalent.
Converting from manager to engineer at the same level requires a special test in at least one FAANG company. Doesn't that mean going from manager to IC is a promotion? And then obviously the other way around must be a demotion?
It's not a good point though, because one of the important traits of a good engineering manager is that they understand the work of the ICs they are managing (at least to a reasonable depth).
I’ve had many good engineering managers over the decades. None were technical. But they were good because they did have skills in things like running interference for us. In my experience, people skills are far more important than technical skills for good engineering managers.
I’ve also had a handful of good non-technical managers over the decades, and they succeeded by having trust in the right technical people (for whatever reason, sometimes it may have been luck). What I’ve seen more often is non-technical managers place trust in the wrong people, get taken for a ride, and generally fail to pinpoint problems correctly.
You’re right that people skills are more important but they are often necessary but insufficient depending on the specific team and business situation.
An astonishing number of debates are between one group of people saying “Foo needs A” and another saying “Foo needs B” when really... Foo needs a good helping of A and B.
... same as bakery manager? And in both cases it helps understanding underlying work, unless you don't just fill forms, organize meetings and chase/yell at people (then you can be easily cut&pasted elsewhere with same great results)
I think it is growth or at least growth opportunity.
Acquiring incremental engineering skills is great and we should all do it. But let's admit that it's just that - incremental. You go from being a good engineer to slightly better engineer- something you already are.
When you pivot to management or something else that's more different to you - you are taking on a bigger challenge and there's no guarantee of success. In order to succeed you need to hone a whole different set of skills - and if you manage to do that, you will certainly have grown in a real way.
I totally get the sentiment that going into management isn't the only way to advance a career and I agree. I am just saying that those who take that path indeed open themselves up to a challenge and evolution.
You are taking on a different challenge, not a bigger challenge. Almost all of your comment could equally describe going from being an engineer to being a dog walker, or a sous chef, or a roofer. Entirely different, and in your new career your prior skills will rapidly atrophy and become marginal.
In my closing on 30-year career in this industry, "managers" have been the least important part of any team, and had the least impact on success or failure. I'm not anti-manager at all (although I have spent my entire career trying to stop people who think they are rewarding me or giving me a promotion by giving me more "manager" duties. I have zero interest in deciding compensation or going to more meetings), it just truly is a position that is the closest to fungible. Everyone fear mongers about AI replacing engineers, but in the real world it could far more easily replace manager level resources.
I spent ten years in my 20s grinding to become great at engineering. I don’t regret it at all. And then when I did get those skills, many people in my life around me didn’t give a fuck, because I was leaving money on the table by not chasing status and management promotions.
It’s allowed me to get to a really good position at an advanced R&D company.
But I still hear the acclaim afforded to those who continue to ascend the ladder, and it stings a bit.
I suppose that is just people needing to believe in those things, and I should let it go.
> "managers" have been the least important part of any team, and had the least impact on success or failure
I'd disagree...I think it can be difficult to see what the manager brings in when a team is good and runs well enough. It's a lot more obvious when you get a bad manager: the team stagnates, loses focus, valuable members will quit (there's the saying "employees don't quit their jobs, they quit their bosses"), recruiting also becomes harder.
There's too much to discuss in one comment, but managers that don't seem to be doing much while the team members are killing it are a precious breed and worth their weight in gold. An alternative way to look at it: they don't need to brag about being important, and have at least enough grasp of what their team does to not be standing in the way.
Great teams self-manage. Managers and management generally exist to ensure a baseline, but they can’t really do much more. In a strong team, everyone displays leadership properties, and they typically don’t listen to non-technical management.
Great teams manage their productiviry themselves, but don't work in a vacuum. Whether their output is properly evaluated and rewarded entirely depends on their manager.
If they increased their product KPI by 150% but their manager had the goal at 200%, your team's suddenly underperforming. If they need 2 more engineers to fill specific spots, the manager will be the one pitching it to HR and convincing upper management to green light the expense. Same for the team budget in general, same for company-wise deadlines, resource allocations, what growth opportunity the memebers get. And so on, and so on.
There's a myriad of super critical things that members take for granted but go through their mamager and get screwed when the manager is bad at its job.
Those teams seem pretty rare though. It also requires an org that lets the team not listen. Also what exactly is non-technical management? In most tech companies most managers are with a technical background. The problem is that they naturally drift further away from technology when not practicing it.
No. If I somehow start as someone who can "only" be a manager (say, mba route) and then learn engineering, I've stretched my capacity more than double.
Because I am not then gonna go down to a junior eng role, but I may flex into eng when it makes sense.
I just don't like how often it's implied that management is the inevitable next rung on the ladder after staff or lead engineer. As if I'm not ambitious enough because I just want to be a good engineer. Employers sometimes dangle the management carrot in front of me, and some people have been outright confused when I tell them I don't covet a management role.
What needs to die is this trope. Few places cut salaries when people move to EM role. This might be true for some big tech companies, but even then it's only in the beginning. If you look at companies that have unified levels for SDEs and EMs (Google, Amazon), you can see that on the same level EMs have slightly higher TC.
Not to mention that there's a whole world outside of big tech where moving to management is considered a promotion (and often the only way to grow, because dual career ladder is not implemented everywhere). The cases where EMs make more than SDEs are really way more common than the reverse situation.
I don't get this comment. I guess because I think we are not aligned on what a manager is or maybe our engineering styles are very different. For me a manager is someone who leads through influence, in engineering managers lead towards an engineering solution. To me it just feels like a different way to solve the same class of problems, just bigger. I absolutely feel like I am doing engineer, the difference being solving bigger problems and a lot fewer problems are being directly solved by me. How do you see a management position?
IMHO engineers should also (and should be expected to) lead through influence. In my mind, as engineers grow they should be expected to tackle problems and influence solutions of increased scope, complexity and ambiguity.
Junior engineers should be able to drive smaller, well scoped projects.
Senior+ engineers should be expected to tackle complex, cross-org, ill-defined technical challenges, examples include technical mergers of company acquisitions, large scale migrations of business critical systems, technical design of big bets (also analysis on which big bets to take), evaluate new technologies/platforms, dev tooling to multiply productivity, etc
A lot of this requires buy-in and stakeholder management to succeed.
Overall I agree, but it's important to realize how easily the impact metrics are gamed. Sometimes the hard parts are in the technical details of programming a specific problem, and doing large scale cross-org collaboration is far more well defined. Or even worse, cross-org collab can just be pure noise by people with no technical understanding defining goals and projects and promoting each other.
So much damage is done by the wrong people being constantly rewarded and promoted for creating noise by "leading" large pointless projects instead of doing the real work. Sometimes I've seen the new hire engineer solving the critical issues like problems in a data pipeline by collaborating across teams is actually having more impact that any of the senior engineers or management bsers.
Right, and in my company that is a manager. An engineer who is good at leading through influence. I am confused as to what other kind of management there is. I guess there is people management, hiring and firing kind of things, but I think that is not what we are talking about on HN.
- Alignment / priority management / keeping team focused
- Saying yes/no to projects
- Medium term planning, resource balancing
- Helping to set team vision and mission
- Reporting to upper management (up)
- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)
- People management (career, performance, strengths/weaknesses etc)
- Spotting and creating opportunities for the team
- Often acting as a tie breaker for decisions (including technical)
- Often involved in steering technical design and solutions
- Help keep the team productive and happy
- Probably a ton more I’m forgetting
Tons of finesse and strong communication skills required for this as well as strong technical experience.
And then there’s project management which I haven’t touched on — either can be done directly by engineers (personally I enjoy it, some don’t which is fine), engineering managers or dedicated technical project/program managers.
The difference from project management I understand, but a lot of what you described regarding keeping the progress going seems to be a SCRUM master's job. Would you say that is also management? Its all a bit fuzzy to me, because for example these are still engineering tasks for me:
>- Saying yes/no to projects
>- Medium term planning, resource balancing
>- Helping to set team vision and mission
>- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)
>- Often acting as a tie breaker for decisions (including technical)
>- Often involved in steering technical design and solutions
I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.
> The difference from project management I understand, but a lot of what you described regarding keeping the progress going seems to be a SCRUM master's job. Would you say that is also management?
These are my rough notes on project management (from an engineer’s lens):
Lots of blanks to fill still, but I am a proponent of engineers owning their own project management.
> I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.
100% agree, lots of overlap between responsibilities and often a good thing! Roles from all parts of the org coming together to solve problems is the ideal situation.
My first approximation is that engineering managers are responsible for the team health, whereas engineers are responsible for project health, or at least raising issues when things aren’t so healthy.
> An engineer who is good at leading through influence.
That's rare. In most companies managers aren't engineers, don't understand the craft and are picked by their buddies. They also have completely different incentives which allows them to throw engineers who spent ages to master the craft under the bus without any regards/regrets.
My hot take on this is craft is not the most important thing in engineering. Especially if you are making anything remotely significant in size. As soon as more than one person is involved in the work, ability to actually collaborate becomes more important than how brilliant each individual contributor is. The myth of genius asshole is my biggest pet peeve, if you are an asshole on purpose (like because you dont care how the other person feels) your genius is not useful and doesn't belong in any decently sized organization.
The point of my comment was that in most companies the managers are the jerks, not engineers. As a VP I had to shield individual developers from some insane managers that got kicks from the tiny power they had.
On some it might be an architect level engineer who also manages the team. In others it'll be nothing more than a middle manager that only will see code on their spare time. And it can be everything in between.
So depending on the kind of move it will not have anything to do with engineering and everything to do with managing. And that's HARD. Changing your whole set of skills for another overnight it's not pleasant.
I am beginning to think all the management posts are bullshit to some degree. Management is nor an easily definable skillset, and neither is it a well-defined role.
Yes and no. It's a common trope at many tech companies that these are two completely separate tracks, with no special upside to either.
But then, here's the reality: any large company will have a new for an army of directors and VPs, compared to only a handful of ultra-senior, visionary engineers. Take Google and compare the ratio of Jeff Dean-type folks to senior managerial staff collecting similar paychecks.
So yeah, if your goal is to retire early without depending too much on luck or on being exceptional, management is your career growth path. For better or worse.
> I grow as an engineer when I learn new stuff or become better at building things. Becoming a manager is changing jobs, not growth in any meaningful way.
That's a very linear outlook. One can also grow be expanding the base of skills one has, and that often comes by shifted to adjacent jobs where you can capitalize on your first skill. There's some benefit in engineers who want to grow by transitioning to manager: nobody wants a non-engineer as your manager/leader - how would they understand your work or attract fantastic talent?
Now, don't get me wrong: I'm not saying for an engineer to grow one has to become a manager, but it is a legitimate strategy.
in a lot of places they refuse to let engineers become managers. Technical experts, distinguished engineers, CTOs, etc, but management is distinctly different then writing code. Human beings are not computer programs. Being good at one doesn't mean you'd be good at the other whatsoever.
Sure, but what I meant is that they might (and I could be wrong) having the old school mindset where your manager is your boss. I worked at Ericsson and I can confirm that's the case over there. Instead, manager should be someone on your "level", just doing different things. We like to say: engineer leads craft and influences people, manager leads people and influences craft.
It's a different set of tasks and skulls but having a background in the relevant domain is in my opinion required. Working in ML, having a manager that doesn't understand statistical significance, or even key metrics like precision and recall is a recipe for unhappy employees and bad decisions.
I think that this has been somewhat nullified by the changes over the last few years where managers are supposed to be people managers exclusively, while high level ICs supposed to create direction and evaluate technical merit.
Agreed. I’ve done both, and while a good Engineering Manager has to be a good engineer (how is one supposed to supervise something they don’t understand), mastering one skill set more or adding a second one isn’t more or less “growth”.
While you can absolutely be a manager without extensive IC experience, most people will benefit greatly from having deep IC experience before becoming a manager.
Nobody goes from engineer to CEO with a million dollar golden parachute for doing a terrible job. As an engineer you work your ass off for someone else to take all the credit and leave you homeless.
It’s growing - hell it’s escaping Getting as far away from working constantly for no reward and more goddam leatcode Interviews where 25yo who know nothing gatekeep your career - maybe you live in a different reality than I do, but I can always just build for myself at home.
People do not go from an engineer to CEO full stop. And also, plenty of CEOs with a million dollar golden parachutes do terrible jobs. So does large parts of management.
The CEO of SABRE (biggest airline res company) went in 15 years from Software Engineer to CEO. He was then forced out when he objected to the company becoming public again (owned by Hedge Fund). I am sure its not common though.
When I gradually became a manager, I continued to be better at building things, not only with my hands, but also by aligning and enabling other engineers and entire teams. So in a grand scheme of things it is the same way, with greater impact and responsibility.
I think of it as horizontal vs vertical. An IC grows horizontally over their career as they learn new technical things. A manager grows vertically as they move up the chain and are managing more and more people.
To put it politely I have a distaste for being referred to as an ‘individual contributor’ (or even worse a ‘resource’). I also don’t like being ‘managed’ and have gained little from ‘line management’ over 20+ years developing software systems.
I do however find it extremely motivating to help a true leader solve their problems in a self-organising team of collaborative peers.
I can’t fathom why so many software organisations are still structured for hierarchical command and control, with the trend of good engineers being ‘promoted’ to management?
Yes I think we need more leadership: with organisations cultivating a culture of leadership, communication, openness and trust. Everyone can display leadership skills depending on the context/task within a team. It is not something reserved for the ‘manager’ (appointed leader).
Do we really need more ‘management’? I don’t think so. Management != Leadership.
Would be keen to see some more articles along the lines of ‘Growing leadership skills for engineers’.
It's hard to convince the people with the power and money that they should get out of the way. If you're lucky, they are mostly unaffected by the structures of power and believe in "servant leadership". If you're unlucky, well, good luck.
I don't think you can make an existing company change it's stripes; you can only start a new one that believes in collective power and try to find a way to make that stick.
Maybe B Corps help? At least you can prioritize something other than maximizing shareholder value. But even then, I'm not sure how you deal with bad actors without some degree of strong power.
The professional managerial class have completely taken over most tech companies now. 'Technologists' trading buzz words, peddling 'influence' and crowding out the people that actually build things.
There is a massive difference in maturity crossing from individual contributor to manager between the military and corporate world. Never in the corporate world have I seen a junior manager tell their boss ”no” and pushback as I have in the military.
In the corporate world it’s all about hiring/firing versus the military where it’s all about developing people and liability at all levels. The key consequence of that is that in the corporate world people are eager to play it safe and follow trends versus the military where its generally considered a safe environment for learning more tolerant of controlled failure. Tolerance of controlled failure is how I learned to become a developer while working at Travelocity a billion years ago and I have not seen that since (in the corporate world).
Another possibly related difference is the training managers get. There are military careers where you know on day one which leadership responsibilities you will take several years down the line. That’s a stark contrast to starting out as an engineer and then transitioning as described in the blog post.
This. The state of leadership training in our industry is abysmal. Most managers I've met get little to no training when they transition to leadership roles. It's slightly better in larger companies, but as you say - a stark contract with military
There’s the little issue that most formation are cargo cult crap. They’re teaching you some kind of method or canvas, but not much more - and cost a lot.
Good formations exists, somewhere. But they’re well hidden.
FWIW IC training is also bad.
You can have a career just winging it (having done so myself) and any standards of competency are left to individual teams/companies or simply who you chose to imitate
I disagree, however I never served in the military. There are companies which provide a safe environment for mistakes to be learning opportunities, its the culture that defines that. Rarely will an actual mistake lead to someone being fired where I work, usually if it does its because of attitude and someone believing they can do no wrong.
If you bring down the production system with a change that is a learning opportunity and your team should be supportive (i.e. help you recover it) when these things occur. Thats why its important to be constantly deploying code and knowing how to roll back, etc.
I’ve worked at a company that did releases months apart and everything was supposed to be perfect, it never was. In that culture it was all about posturing, covering up mistakes and blame-game which is utterly frustrating to work in.
The problem with management roles today is they are watered down to the point of being basically pointless. Product people determine the shape of things and priorities. Tech leads determine how things should be done.
The manager is supposed to shepherd career growth and decide how much people should get paid. In my view this is a really part time job at best.
I think we need to go back to coupling more of these roles together, similar to what would happen in a startup. A strong leader should be able to fill product, tech lead and management roles.
Like a team ceo. I strongly believe this person should be responsible for a teams success or failure. Grant this person the right to hire/fire members of various disciplines. Tell this person to chase certain revenue numbers or another mission. Give this person the bonus money/product dividends to share with the team. I believe all this will drive this person to really build a team, instead of just managing it.
But demote them to smaller projects when they fail to deliver. And allow team members to apply to work for a different team if they trust the team ceo there more. Like an internal startup environment but teams. This is how I would try relentlessly to structure my company.
Managers have to manage up, down and outward. Most ICs will generally see downward management, but not the hours put in reporting up to executives, aligning and planning initiatives, resource/ allocations/PI’s, budgeting, procurement, audits, client/product demos/presentations, hiring and sometimes firing.
Managing down tends to be the easy part, career planning, 1:1’s, performance/development and running rituals is a cake walk. The only real hard part of managing down is when you have an employee that’s poisoning the well or is on a PIP.
Oh, and some managers also have to still pick up cards and push code in some orgs.
Most posts here are from those who have never walked in a manager's shoes so only know what they see (or hear/read).
Think about it, minus a few exceptions, most managers are paid better than the engineers they manage. Now why would exec/sr mgmt. do pay more unless they are getting their money's value?
I'm on the journey back too and can't wait to find a role where I actually have some creative input and decision making again.
This obviously varies from role to role but I was told I would be highly involved in deciding what the team does and how they go about it. The reality is that I am responsible for arbitrating the delivery of decisions from more senior managers to the teams and the decisions from the teams on how they execute on those decisions back to the managers.
Facilitating the growth of other engineers is wonderful but, frankly, I can do that (and was doing that) as an IC.
If I'm honest I don't think the exact role I want exists out there but I think I'll make a far better "lieutenant" to a manager who actually likes the job than I make a manager who is becoming increasingly unengaged with their own role.
> The reality is that I am responsible for arbitrating the delivery of decisions from more senior managers to the teams and the decisions from the teams on how they execute on those decisions back to the managers.
If it were only that simple. Often one needs to be at least a team lead to set the technical direction. As an IC, I sometimes found myself being asked to implement a solution in a form that I did not agree with.
With the right team/leader, there'd be room for your inputs on the matter. Even if you find yourself in a not-so-good team setup, I'd argue there's still merit in letting your opinion be known, regardless of whether you end up implementing said solution in the way you were told or not.
I don't think that changes much. To oversimplify; by telling you how to do it, the team lead is taking responsibility for the outcome of your output. You are just responsible for doing it how they said.
As others here have said, you don't grow from engineer to manager, you grow from engineer to lead engineer, or architect, or another similarly technical role.
I was recently promoted from Principal Engineer to Director of Technology in $JOB, and the difference has been striking, mostly in the ability to influence things so we can build the right technology before we start. That feels like a much more natural step for an engineer than throwing away their entire skillset and moving them to a position that requires an entirely different one.
If you want to grow your engineers, give them more (and higher-level, higher-impact technical stuff to do. If they want to become managers, great, but there's not as much overlap between engineering and engineering management as most people seem to think.
A coworker and friend is both an engineer and a manager, and he happens to be great at both of those. Instead of losing one of the skillsets, he has a role where he both manages his team and sets the technical direction for them. This means he manages a much smaller team than he would otherwise, but he loves doing both, so this a natural fit for him.
All this is to say, build your roles according to your people, don't shoehorn them into labels that other companies have told you is "how to do things".
I'm trying to say my Director of Technology role isn't a management role (our Director of Engineering is). I'm responsible for the technologies that we use, develop, maintain, etc, but not the people or teams that do it, and it works very well for us.
Director of technology is usually not. There is no direct reports. What I've seen is this role existing alongside a director of engineering role which does deal with management.
Engineer to manager isn't "growth", it's a complete career shift. Fine if you want it, torture if you don't.
"Dear Engineer, you are so good at your job we've decided to have you stop doing it and do a different job with an almost completely disjoint skill set. You get to do something that you will most likely hate and be bad at. Plus you can never go back to your old life."
I mean, you can definitely go back, there's just friction to doing so and it won't happen unless you are intentional about it. Might be more accurate to say you can go back, but it will never be the same now that you've had the veil pulled back on how things are being coordinated behind the scenes.
Interested in moving from Engineer to Manager because I hope to do less work. Happy to do a few meetings, send a few emails, rather than actually having to build stuff that i don't care about.
It's even better if as you say the success is determined by the team, because then also the failure can be pushed on the team.
Edit: FWIW not that I want to be a bad manager. The environment is what shapes your incentives and behaviours.
I've done both and I can assure you that management is not less work.
In fact, you are more likely to work longer hours, and attend meetings at stupid times because that's the only slot you can get the more senior managers to meet at.
However, you sound disillusioned with your work, and maybe you do need to transition into something else. A new challenge can revitalise you, and it doesn't have to be forever.
I've met plenty of engineers who seem to believe that everyone else's non technical role is easy. Keep an open mind, and don't approach new opportunities with a negative attitude, or you will probably remain discontented.
> I've met plenty of engineers who seem to believe that everyone else's non technical role is easy.
Not easy. But it's the difference between being the one who is approving and the one who is doing the work.
The one who has some autonomy and the one who doesn't. The one who is valued and the one who isn't.
Having to attend OOH meeting is less stress for me, then having to build something OOH and make it work. One requires communication, politics, the other one actual tangible deliverables.
Many years ago I did some great courses on team building and management. Also some negotiation skills and assertiveness training. They were really useful to me. Maybe that is something which might help you move into a role with more autonomy.
> I've met plenty of engineers who seem to believe that everyone else's non technical role is easy.
In my experience it’s like that (I’m talking about engineers vs eng. managers). Another significant difference is the amount of work, I believe: as an engineer I work 4h/day but those 4h are “hard” hours (fully focused) and my brain ends up a bit exhausted after. But that’s all I do in the day for work. On the other hand, eng. managers do more lightweight work, but work longer hours.
I have to say that in my experience, what my eng. managers were doing all day was: 1:1s, meetings with other managers to decide how to shift around people, interviews, being present at some sprint plannings without saying much, being present at some daily meetings without saying much.
To offer a counter datapoint: I moved from engineer to manager while tracking my hours fairly accurately.
I can pull off 50 hours of development, including late night emergencies, some client pressure, etc., and still feel energized the weekend, while after 40 hours of management, meetings and firefighting, I become mostly useless and have to take some serious breaks. I enjoy both.
However, there are so many parameters affecting this result that I wouldn't dare to make a call on which role is more tiring in general at a regular company.
- I'm less experienced as a manager, I have to continuously learn a lot and grow fast.
- This is in a young start-up context.
- This is with a very broad scope of responsibilities.
- I'm me.
- etc.
YMMV
The largest fatigue factor to me seems the amount of context switch I have to do as a manager.
People always say that managers work more hours, but I feel like it’d be quite possible to do the job in the time I spend doing my work now. We don’t think it’s normal if programmers work extra hours to get their work done. Why should we for managers?
I think the problem is that eng. managers have not much control regarding how many meetings they have (and at what time they are scheduled). Being meetings the big chunk if their day to day work, that restricts the amount of freedom eng. managers usually have.
For engineers it’s different: we have complete control regarding when to work, and we don’t have as many meetings as eng. managers have. So there’s more freedom in my opinion.
I think it’s not very realistic for a manager to say: I’ll work extra today so tomorrow I’ll work only 1h (because you probably have meetings to attend that you cannot postpone). As engineer, I work whenever I want and rest whenever I need it (as long as I meet deadlines and the like)
Nah, but this ‘meetings to attend that you cannot postpone’ is almost always bullshit. I see a lot of managers in meetings where their presence is more hindrance than help. If they drop those they suddenly have 50% of their day free.
Of course I won’t actually know until I am one myself, but it certainly feels doable if I’m willing to sort of trust my team.
It's not typically the meetings with the team that are the ones you cannot postpone. It's the ones with key people from the business, senior managers, partners, vendors...
If you do become one and find you can control your schedule, please write it up and share!
Quite right! In my experience, it is a combination of people who are ambitious to climb the hierarchy, the difficulty of scheduling meetings when people are actually available, and just quite a lot of fire fighting, where urgent issues have to be resolved quickly.
Obviously, it depends on the organisation you work at.
God’s truth. I do find debugging/getting to compile with green tests mostly written code combines well with meetings. I can go to next error or failure and keep an ear out for interesting stuff but don’t have some big mental plan that can be wiped out by an important chat.
> In fact, you are more likely to work longer hours, and attend meetings at stupid times because that's the only slot you can get the more senior managers to meet at.
Unless you work with someone internationally and the only time both teams are awake is at ungodly hours for both, so you never get any meetings at normal times.
In my experience engineers have more “free time” than eng. managers. As a senior engineer I have not many meetings per week, and the tasks I need to accomplish I can arrange time for them the best way that fits me. So, on Monday I could work fully focused, let’s say, 4h, and call it a day. On Tuesday spend 2h in meetings and another 2h to do PR reviewing… I have almost absolute control over my day, and that feeling is great.
On the other hand, even though eng. managers mostly do meetings, their calendars are usually packed with them. Even worse, they may have one meeting at 8am, another at 12, and another at 4pm… that kills your day completely since you have to stay available during the whole day. Definitely something I would hate.
Meetings filled with endless bike shedding about trivialities, bickering about specs, push and shove over changes in scope and delivery dates… and then every waking moment outside of those meetings, you’re either following up the above from previous meetings or scheduling new ones. Not a fun time.
Maybe it’s just that I’m no longer in my 20s (or that I have only worked for european companies) but I do not work extra hours. If the project is going to “fail” because we are not willing to do crunch time (spoiler: the project is not going to fail because of that) then let it be. Mismanagement of time is on managers not on engineers. I can help sure in a punctual situation, but I’ve never done it so far.
If it is a project I strongly believe in and mostly said we should do, and it is more fun than frustrating, I will get into big focus and work or think about it continually until it is finished, then I slump and relax for a while, going around and bragging to my friends and writing docs and maybe tech talks.
But if it a project without intrinsic motivation or large and clearly present business value (like fixing an incident or saving a $10M client contract but not some hopeful!thing that might pay off in two years), then I keep my weekends to maintain myself as a human being (which ironically also happens to benefit the company on that two year time scale).
That's an extremely myopic and immature view of what management is. You have probably only worked with incompetent managers and your experiences reduce a role that can be both stressful and complex to nothingness.
Ironically, competent managers also make it look easy. Because they must understand that their mood, behavior and what they say can really impact the morale of their reports and their relationships in the organization, many display a calm and professional demeanor. To the untrained, this outward apperance obscures the fact that they work very hard to position their team for success; and navigate, mitigate or repel shitstorms.
Exactly, what merit is there to putting a manager that pushes failure onto the team? Might as well have the team itself report to senior management if one is too eager to get out of the way.
That’s what’s difficult about leadership: success and observable, effusive credit flows down the org chart through the manager to the team. Failure is intercepted and sticks more with the leader.
Neither is 100%, but if you try to push failure 100% onto the team, you’re going to have a really bad time personally and be rightly reviled as a weak leader by your team, your peers, and your senior leaders.
> effusive credit flows down the org chart through the manager to the team
not in my experience tbh.
i worked 16 years as an Engineer across 6 orgs including Fang. What I saw is that the closer you are to management the more valued and rewarded you are.
Simply because you are doing the management's dirty work (your influence is direct) and you have more insight into finances, so it's more difficult for them to underpay you.
Credit very rarely flows down and when it does, in very generalistic way "thanks to X and Y and also the team for their efforts".
I transitioned to EM and I assure you it’s a lot more work. If you don’t want to fight with your company’s trash IDE, then maybe. But if you think you’ll have less on your plate as an EM then either
1. You’re wrong and you’ll find yourself working more
2. You’re right and you are screwing over your team.
In a similar boat and have tried this recently, but I can't say it worked. The only real solution seems to be to go elsewhere.
There is something supremely disgusting in being forced to work on projects ("hey client X needs this Y thing done asap") that you don't care about, know they have a close to zero chance of working to an acceptable degree and also know you'll be blamed for their failure. Over and over and over.
Not how it works. You now are responsible for making other people complete work you don’t care about. If they fail, you also fail. Way more risk, way less control over the outcome. Plus your tech skills atrophy the whole time, making you less valuable outside your org leading to a kind of employer lock in.
You must have some very good managers who make their work seem effortless. Perhaps get them to be a mentor when you make the shift so when reality strikes you won't have to deal with it by yourself.
You don't "grow" into a manager, you just delegate problems to other people. The manager is a meta problem solver, the individual contributor are the real problem solvers.
Understanding the meta problem is not the same as understanding the problem and vice-versa.
Michael Jordan's supervisor is not Michael Jordan. They're people with valuable, non trivial skills that take time and effort to cultivate, but people don't buy tickets to go see a manager, just like customers don't buy manager deliverables, they buy individual contributor deliverables.
The customer doesn't buy issue tracker tickets, or speeches, or gantt charts, or burndown charts, or diagrams, or whatever manager deliverable of your choosing. They buy working software that is stable, performant and that has an ergonomic and polished interface. The manager's job is to facilitate an environment where that can happen. They are not the neurons of the team, they're more like the glia of the team.
That is, if you build a team consisting solely of managers and ask them to solve a problem, and designate one of them as the manager, they won't be an effective team. Did they really "grow"? Or they pursued a different track?
MJ was a great player but there is no way the Bulls would've won all those championships without his team mates (who themselves were of great caliber). It takes a great coach to harness talent and manage it in a team.
Software engineering is a team sport in that same regard. If we're lucky we have a MJ on the team but still needs to be managed for their own (and the team's) good.
I always like to think of EMs as engineers who rely on other people to write code, instead of writing code directly themselves. As anyone who has played a game of telephone can attest, writing code through people is a lot harder than writing it yourself.
One should be very wary of any blanket assumptions of management roles implying any kind of more seniority than engineering roles. They are different activities, different jobs. That's it. Not every engineer must be made a manager at some point to grow. An engineer can grow in engineering, becoming more specialist in various areas. I wish people stopped to conflate these things.
I know engineering manager can be loads of work. I wouldn't want to do the job my engineering manager is currently doing. I would probably die of boredom in meetings or completely fail, as my brain shuts off during the meetings or something. I want to build things. With code. That does not make me any less of a senior.
Some companies just don't have a full career track outside of people management. It's not really a matter of company size or age. I suspect most developers are okay with stunted career tracks for office management, system administration, or customer support. In some companies (including organizations that view themselves as software companies), the same attitude simply extends to software development as well.
I wish these different organizational choices would be more widely known. My current employer nowadays has these non-management career tracks, but I'm not sure if we communicate them clearly as one of the reasons to join the company.
In my experience, IC tracks in general tend to cap out based on the complexity and value of the skillset/domain to the business.
A major accounting firm may have some senior engineers, marketers, etc. but since their work isn’t “core” to the business, the top tiers of the technology and marketing tracks will tend to be exclusively management roles — whereas accountants will be allowed to… account… up to a much higher seniority level before they get forced into management.
I don't see managers who grow and the reason is because they often weren't growing as engineers...
The most common reason I see people become managers is because they weren't cut out for engineering work or it burnt them out over time. Many couldn't keep up with the ocean of new technologies and philosophies software has gained in the last few decades and so they are relegated to being a machine that checks email for twice a starting engineers salary.
Some managers really have done so to steward a company or team through a problem but so many more of them just want to "check out" essentially and in just a few short years loose most of the engineering context value they had and become some degree of roadblock to progress because sadly they want their cake and they want to engineer it too...they often create tasks and conversations they don't make sense or deliverables that are missing the point because they are no longer engineers no matter how badly they still want to identify as one after leaving a organic growing codebase.
I get it they have families and they are getting older and the kids coming out of college are honestly intimidating sometimes but that's a problem with the absolute lack of upward mobility within engineering and they unhealthy standards of modern corporate culture.
It's sad really. Very intelligent opinionated people slowly go from talking about solutions in concrete terms to a mix of language about deliverables, burn charts, agile, circling wagons, getting on the same page, and determining a funnel for Q4 while the software they are talking about has no unit tests and they themselves have determined that it's not part of the MVP...
If they could go back 10 years and hear themselves I wonder what they would think of the people they've become...
The subject of seniority and progression to management pops up from time to time here in HN, and we usually see the same tired arguments. Managers are useless, it's not real work, seniority is an illusion, etc etc.
There's nothing wrong with being good at your job and not wanting to change your role. But it's obvious that in most situations, progressing to other roles is necessary if you want to have more influence and control over your product - and usually higher compensation as well. In a professional kitchen, obviously the person actually cooking has to be really good. That doesn't mean this person gets to choose the menu of the restaurant, and their name also won't be displayed outside. They are more easily replaceable than a chef, even if they are very competent technically. As most things in life, it's all about trade-offs, I just think that ignoring what the actual pros and cons are will lead you to bad decisions down the line.
They definitely are. But the metrics looks different. For example, if managers start losing a significant amount of people (because they can’t do a good job retaining and developing talent) it will be obvious to higher ups that the person has to go.
I’ve seen FAANG managers with atrocious 360 reviews have their entire teams quit (the company) and hit director 5 years later. It usually takes breaking a law or total role/team/project/program/org elimination to oust a manager.
I'm building a game about engineering management at FAANG that shows the spectrum of managerial role. Might be good to stop reading about managers but try it out, not sure everyone has opportunity to try it at work - https://store.steampowered.com/app/2436030?utm_campaign=hn1
It is not "growing". It is changing the work which can be good or bad. I "grew" to a manager (CTO in this particular case) in 100 person company some 20+ years ago and this got me to the point that I said fuck it, went on my own and am still happily doing creative work designing and implementing (including programming) products for clients and for my own company.
Managing people is the last thing I want to do professionally as a software developer. If I wanted to manage people, I would've gone that route a long time ago. Now sadly this is also the only way for me to "rank up" further in the company I've been working for the last 10 years. I guess I'm either stuck for now or I'll need to leave.
I don't understand this view point that is so common on HN. I can only assume that most engineers on here are quite junior.
Of course you grow as a manager. But you're right you're not growing as a technical expert - that's not the goal of managing. Managing becomes more about the business and less about the technical details.
It's a very different job and an important one if you know anything about running a larger company. The technical work you do as a IC is one part of many that drives the business forward.
I think there's a difference in how visible these skills are.
As an engineer it's easy to practice many new skills and also to see improvement. I might be interested in orchestration, I pick up Kubernetes course. I want to build iOS app, I start learning Swift. After a month or two I can see a difference in my skills. Others can see it too - I contributed to iOS app at work which I haven't done before, it's a new skill I learned.
As a manager, I need to be better at negotiating with stakeholders, or recognizing underperformance, or interviewing candidates. I can read books, take courses, but I can only see my improvement over longer period of time. What's more, most of people around me won't see that I'm a better interviewer now, or that I'm better at helping to improve individual performance. It doesn't mean I stopped growing, it doesn't mean I don't cultivate new skills. They're just different skills.
Got the advice from several senior architects / managers to never "grow" to manager of you deeply enjoy engineering. The skills for management and engineering are orthogonal it seems.
Apparently this is a junior person's blog promotion and hence the controversial (or plain wrong for me) title which has raised several discussions here.
Since we are talking about it though, let's apply the 5 whys:
1. Why do companies need managers? Because they need they're employees to be managed
2. Why do companies need their employees to be managed? Because they are not certain that they will follow the company's short/long-term strategy and vision
3. Why are they not certain? Because they're having trust issues
4. Why are they having trust issues? Because they are not investing in proper hiring
5. Why are they not investing in proper hiring? Because it's expensive and requires tremendous multidisciplinary skills, time and effort
We are dealing with one night stands masked as serious dates ladies and gentlemen. Managers are just pawns which patch the original issue. Solving hiring would make them redundant.
I see what you mean and you're not wrong. However given that you hire good senior engineers and that you trust them, most companies can resolve these issues. Coordinating activities is a project manager's thing which should have to do with gantt diagrams and not with micro-managing engineers. Very few companies are having complex software similar to OS, therefore being in need of the management that you're referring to. It's astonishing how managers responsible for building a button are reading the mythical man month and think they are the same.
One issue is that people can agree on a general vision but differ completely on what problems exist, how they could be resolved, and what series of decisions support each other. It becomes overwhelming for people to think about.
Focus on writing down your thoughts and supporting them. Build a case for something and then make decisions and execute. If you can put together a cogent argument, even people who disagree can often stomach working hard on it as long as you acknowledge their criticism and occasionally reevaluate past decisions.
Alternatively, when an organisation reaches a certain size, there becomes enough high level coordination needs for it to be a full time job, and also some HR-type functions work better when distributed to the edges rather than the central org.
