Comment by etothet
7 hours ago
If you are reading this and you are thinking you want to become an engineering manager, I urge you to think long term what you want that to look like. I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role.
And, as you move up to Director and beyond, those higher often have much less to do with actual engineering than tasks that sort of surround the world of engineering - lots of organizing information and attending meetings.
I've seen too many developers who though they wanted to manage become victim to the Peter Principle [1].
There is nothing wrong with staying a developer, even if you're not "moving up" to some idealized title. If you like the work and you can tolerate the place you work, you're probably ahead of most people in our field.
On the contrary, my manager doesn't do much outside of the perf evaluation season, and takes home a higher salary than me. He also gets to take credit for pretty much everything that his team does, despite not contributing to it much. Sounds like a fairly easy job most of the time.
Here's how I see it: Ideally a manager / reportee relationship is a symbiotic relationship. A manager becomes more successful by making their reportees more successful, and both roles grow together. And repeating this across teams, the whole company grows as well.
There's a lot of nuance but here's a simplistic overview: a manager tries to land a big project for their team, which lets the team stretch their abilities and grow, which over multiple successful deliveries results in promotions / raises for everyone involved AND the cachet to ask for bigger projects (and more headcount!)
The manager's role is the hustling and jockeying in landing the project, ensuring their team is executing and getting any mentorship needed (directly or indirectly) and protecting them from disruptions ("shit umbrella") -- which includes managing everything around the team including stakeholders and dependencies and escalations -- and then making the case for promotions / raises / PIPs based on their performance.
I've never been a manager, but having been involved in all these aspects, I can tell you none of this is easy. All of these can get very contentious, even in the best-run of companies; in the rest, a lot of pathologies spring up (like politics and empire-building) that cause even more nastiness.
So it may seem like they're taking credit for your work, but that's literally part of the arrangement, and it's only unfair if you're not seeing any upside. If you feel that way, this is 100% something you should bring up (very tactfully!) in a 1:1 or (even more tactfully!!!) a skip-level.
Until you are dealing with a difficult employee or struggling with whether to put someone on a PIP or being asked to deliver things you don't have direct control over or dealing with penny-pinching edicts from above etc. etc.
Engineering Manager can be a social role with some tech aspects.
You attend meetings, negotiate deadlines, evaluate people, navigate project minefields, take decisions or force people to take them,... and the technical aspects are quite minimised.
Depending on the company this is not an upgrade, it's a lateral move. I have people under me who earn more than me, and I agree with that.
The job it's not easy, it's different. Spending 5 hours on meetings it's easy, but exhausting. Giving credit to your people but taking the blame (which is what should be done) it's easy, but demoralising. Not having a peer group of people with whom easily socialise makes the job feels lonely, when you talk with other managers it's 99% work related, and you can't make your people like you as a person.
Most days I'd love to have a clear objective.
One of the worst is the strange feeling that you have because you've studied for a long time some skills, and worked using them, and now those are hardly used. You need to use a set of skills that you haven't trained for, and haven't used as much (depending on your personality/skillset, of course).
Being a manager is not for everyone.
I've jumped back and forth between IC and Management. The roles are measured on completely different things. Most of IC is about through put. Most of management is about building/doing the right thing (aka making money).
Sometimes, it can look like management is doing very little because you only see the tail end of their outputs to the team.
He doesn't get much say about what thing gets done. He's just kind of there.
On the front of it he's not a very good manager for the team then.
Once you get to leadership you're giving credit where it's due and soaking up the loss.
Sorry to hear that. From that description this person does not sound like a good manager.
I've had worse!
In my experience, I kind of think that The Dilbert Principle [1] holds more than the Peter Principle.
With the Peter Principle, it's implied that they were good at their previous job and are bad at their current one, but having had to debug awful, awful, broken code at Apple by people who had been promoted into managers or directors, I'm not convinced that they were ever good at their job. I remember some code we had in iTunes, my manager would say "that was written by X. Don't worry, he's been safely promoted out of danger".
I think management, especially higher management, is often about how much you can make it look like you're doing important things. It requires zero effort or skill to book a dozen meetings in Outlook or Google Calendar, and it only requires a fairly small amount of effort to make slide shows to talk about how "important" the work is that you're doing. Instead of getting good at engineering and writing good software, it's much easier and more effective to tell people how good at engineering and writing software you are instead. Most of the higher-level managers are pretty removed from the low-level work so when promotions come along, they remember the person who kept booking all the meetings with them and assume what they were doing is important.
I'm admittedly more than a little cynical about this stuff; I have been routinely negative about big corporations (and particularly Apple) and I think that the Peter Principle is assuming a level of rationality and intelligence that I really haven't observed.
[1] https://en.wikipedia.org/wiki/Dilbert_principle#Definition Not saying I'm a huge fan of Scott Adams, but I don't know any other name for this principle.
> I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role
As an IC, this is baffling to me because that seems like the biggest and most obvious part of the job. I never want to be approving people's leave requests or telling someone they're being a jerk on slack.
Everybody wants a manager that has engineering experience, but nobody wants to be that manager.
I'm a freelance interim EM and I do it for the same reason the article explains: I genuinely enjoy it.
I love engineers and I love tech. I still code daily but I'm not the guy that delivers at the pace of some of the amazing engineers that I had the privilege to work with. I love putting others ahead of myself wherever I can and it's never cost me anything, so I'm not afraid to do it again. I love telling the engineers how what they do actually matters because they're too focused on the work to sometimes see why changing goals doesn't mean their work and efforts were wasted and I also love shielding them from the corporate mess upstairs (that I somewhat masochistically don't even dread being part of)...
So, yeah, I really love my job and if one of my guys (or gals) wants that too, the more of a joy it is to me to mentor them into that process.
This.
EM is a terminal position that does not own the product roadmap (Product Management) nor the underlying implementation (Staff/Principal Engineers).
They primarily own delivery and execution because orgs can't be bothered to hire program managers anymore.
If you are great at managing upwards and ensuring delivery by hook or by crook, you will make a great EM. But the next jump after EM is extremely difficult because you are competing with Principal Engineers and technical-minded PMs making a lateral move and cofounders who are being managed out by the board; and dealing with micromanaging CTOs or CPTOs.
Are you saying principal engineers and tech minded PMs make lateral moves into director level manager without going through being entry level EMs first?
I've never heard of something like that. Usually the requirement for being director level manager of engineers is to at least have managed people as an EM for several years before.
At my company it’s lateral.
Lead -> EM
Sr. Lead -> Sr. EM
Principal -> Director
Sr. Principal -> Sr. Director
The pay is aligned with the level whether or not you’re a people leader. To your point though, it may be difficult to go from Principal to Director. I see the lateral moves happen more at the Lead/Sr. Lead levels. They might do a Principal to a Sr. Manager as a trial period with the expectation that you’d be Director after a short time if you perform well. I’ve definitely seen directors become principals as well, so it goes both ways.