Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with:
1. Be caviling and pedantic, so you can reinforce your position of petty power.
2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch.
3. Put at least a couple meetings on the calendar every day of every engineer that they don't need to be at to remind them you rule over their time.
4. Push nebulous "goals", then have very set goals when it comes time to promote/give a pay raise an engineer and then insist they aren't quite there.
5. Put engineers on-call instead of hiring support staff, again to remind the engineer that you own their time, even when they're not at work.
6. Constantly seek updates from engineers, so many in fact that they can't complete the work on time, then promptly blame the engineers for not delivering.
"Managers" are people with business degrees who failed out of anything technical. Real managers are architects and PMs who actually understand the product and the technical lift it takes to actually make things happen. They don't concern themselves with your comings-and-goings, but whether you can get things done or not.
For some reason they downvote you, but your post has some truth.
I really wish EM wasn’t only about people management, hiring and goals but actual technical leadership. I want my manager to care for my wellbeing, be empathetic etc. as the post and common sense suggest, but i prefer he could provide some technical direction to the team (not let the team leads figure it out themselves), collaborate closely with product and leadership, make time for engineering to solve hard problems and tech debt and not just deliver d2d features and so on. I would expect EMs coming from IC roles to have this mindset, but most of the time they are stuck to non technical responsibilities and i really cannot understand why this role has become like this.
I was a data engineering em for a while, but it’s super tough to find open roles on the field. I just don’t understand how most em roles demand zero technical contribution.
I think it's helpful to consider these points, and try not to be put off by the bitter tone.
As an employee you have to consider the workplace culture, and your manager's attitude towards his/her "resources" (employees). This is a list of danger signs. You want to be watch for dysfunctional behaviors like this creeping into your work environment, and either combat them if you can, or find a new position. Or, you can accommodate/enable and try to insulate yourself, which is OK in the short-term, as you work towards a longer-term solution.
The culture of the organization and the management chain above you greatly affects your satisfaction and mental well-being. I assure you that, although no workplace is perfect, a few are pretty darn good. And sometimes it's possible to exert influence. Try not to sink too far into cynicism because there is a lot of incompetence and selfish self-interest out there. Use your skills of observation and writing to make things better, or find a place where that's possible.
As much as I disagree with the article, this is just the engineer's version of it.
I think you would find it really interesting to try running a company or even a team. I think it would help you see your prior managers in a different light.
Everywhere I've worked has had on call rotations. Literally everywhere. Nowhere have devs been the first line of support (i.e., not "instead of" per the parent post, but "as well as"), but they've been in the mix.
Quite frankly, I wouldn't want to work somewhere that didn't. I have a huge problem with the idea of "my team wrote the code, and now isn't responsible for it". I intentionally optimize against "avoid 2 AM pages", and that ensures I push for enough testing and such to avoid them. If it was "someone else's problem", the only pressure I'd be under is to deliver ASAP, and that's unhealthy.
Well...I also have not worked anywhere that you personally got paged more than maybe once or twice a year, and that any after hour pages led to the expectation you'd take twice that amount of time off the next day, and if it was more than a couple hours, or interrupted your sleep, you'd take the full day off.
And those were not FAANG. So I think it's also the culture and expectations, and it's not ludicrously impossible to get. It just requires, getting back to the topic, a reasonable manager who understands the negative effects of getting paged.
I didn't say you can't put engineers on-call. But if you do that there are labor laws you need to comply with regarding overtime and suchlike. You can't just pay someone a salary then say "oh yeah you need to wear this pager at the weekend".
I also acknowledge that failure to comply with labor laws and other regulations is widespread in the US, whether knowingly or though ignorance.
> You can't just pay someone a salary then say "oh yeah you need to wear this pager at the weekend".
It seems to be the case in every job I've had. Maybe they ARE adhering to some laws but at the end of the day I get paid a salary, and I have on-call evenings+weekends which I don't select. I can swap shifts, but it's my responsibility to find a substitute. I average 4-5 shifts/months.
As far as I know, all of FANGetc is like this. It may be the case that labor laws permit this. Still miserable.
Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with:
1. Be caviling and pedantic, so you can reinforce your position of petty power.
2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch.
3. Put at least a couple meetings on the calendar every day of every engineer that they don't need to be at to remind them you rule over their time.
4. Push nebulous "goals", then have very set goals when it comes time to promote/give a pay raise an engineer and then insist they aren't quite there.
5. Put engineers on-call instead of hiring support staff, again to remind the engineer that you own their time, even when they're not at work.
6. Constantly seek updates from engineers, so many in fact that they can't complete the work on time, then promptly blame the engineers for not delivering.
"Managers" are people with business degrees who failed out of anything technical. Real managers are architects and PMs who actually understand the product and the technical lift it takes to actually make things happen. They don't concern themselves with your comings-and-goings, but whether you can get things done or not.