https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_...
The managers at my company are some of the most technically skilled. Several of the directors have committed code recently on stuff I wouldn't touch with a ten foot pole.
Engineering managers are responsible for their team’s output; they are often held responsible when their team fails to deliver. Product Managers are responsible for setting and prioritizing the product roadmap across a lot of stakeholders, often with specific business goals to achieve, and spending a lot of time doing stuff like talking to customers and helping with marketing/sales/planning/etc; they are also often held responsible when they don’t deliver on these tasks.
It is a very junior engineer perspective to consider it not actual work or for them to have no real responsibilities just because they are not coding. In my experience it has also been common for EMs to be at least staff level ICs skill-wise and PMs to have enough software skills (often having previously been SWEs) that they could be SWEs if they preferred that.
I however wouldn't expect the EM to do more than glance at PRs and see if they are moving along and the comments are constructive. But it is very rare that someone who is not working regularly with the code would be able to maintain a useful mental model of the code. Thus the glance might just be at a dashboard to determine if PRs are "too big" or are having unexpected amounts of time being ignored.
This has been my experience as well. What are all these non-technical EMs doing in an engineering org? Why are they spending so much time on HR work or org structure work?
The problem with EMs spending so much time on non-technical stuff is that they lose sight of what they are managing - the services and the team building the services. They start focusing only on org structure, perf reviews, promos etc. all of which have nothing to do with the job of managing services.
Then they start imposing non-technical workload on their reports because that non-technical stuff will improve their own ratings e.g. boosting PR counts, JIRA story points etc. - once again, these have nothing to do with the actual services they are responsible for.
The whole org turns upside down with far too many managers on the management track asking for work that has got nothing to do with actual services - and yet the burden is imposed only on engineers.
This leads to disgruntled engineers because engineers don't want to follow a HR leader. They want to follow technical leaders.
The EM solution for this is to hire a staff engineer. But once again - they are imposing the same non-tech burden of PR counts, JIRA points on this staff engineer and all other engineers.
The problem is management itself. But they will never recognize that.
While this is not wrong, ask yourself as a thought experiment, what happens to the engineers if an EM over promises due to incorrect scoping or a PM leads engineers down a rabbit hole that the company doesn't care about? Hint: The engineers still toiled for that wild goose chase.
In my experience, there are far too many stakeholders (EM, PM etc.) who want work to be done by engineers but none of the stakeholders want to listen when engineering points out some fallacy, or incorrect scoping, or unknown unknowns.
Engineers don't get heard even though they are the ones doing the work. Instead, they often get blamed for speaking the truth. As simple as that.
No they aren't. But, in that image, they are the only ones without whom the work will not be done.
In other words, everyone else in that image is even less special than developers. Anyone unable to acknowledge the mediocrity of other job roles is a massive red flag imo.
They do overlap, but to me there is a clear line between their responsibilities and authority. Things get blurry in smaller orgs, but in larger ones with multiple product streams, budgets and stakeholders - they're usually pretty clearly defined roles.