I agree with this generally for TPM and project managers. Even then it’s not that they truly do no work, but that the core coordination work they do (which requires very few, but no 0, man hours) could be done with higher fidelity and context by an EM without it really adding much more work to an EM’s job.
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.
> 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.
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.
In the past 10 years I only worked with one manager who had staff level IC skills. It’s much more common to have a mediocre EM that doesn’t even look at the code. If you’re “managing” a 4 person team and not at least looking at PRs, seeing the actual work product, you are out of touch.
A four person team would typically have a "team lead" who is rarely responsible for providing feedback to their engineering manager with performance reviews, goal setting, and so on.
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.
I'm mostly talking about smaller companies where the EM is the team lead.
A lot of these companies have bloated managerial structures, even in smaller orgs... You didn't see this 10 to 15 years ago. It disgusts me when I go to a meeting, and there's literally 10 people on the call, only 3 of which actually do any direct work on the project.
> I'm mostly talking about smaller companies where the EM is the team lead. A lot of these companies have bloated managerial structures, even in smaller orgs... You didn't see this 10 to 15 years ago.
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.
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.