They're the experts on engineering practices. They don't have to be great managers. They don't even have to be scrum masters and such. But they're part of the feedback loop to make sure the management stuff makes sense.

They make sure the bonus structure is logical, i.e. not based on story points or something. They make sure that it's logical to have 3 Android devs and 1 iOS dev, vs just hiring 4 hybrids. They make sure the tech recruiting makes sense.

They measure productivity in a way that makes sense for this team. Sure, LOC works for some teams, but it makes no sense with LLMs. Sure, test coverage matters, but what's a reasonable number? How do you know you haven't just hired a team of engineers who are working together to bullshit you? There's that guy making 1 commit a week, is he just being super efficient or is he quiet quitting? Are all these refactoring weeks really making sense? Is this market rate making sense? How do we replace the asshole who's holding the whole product hostage?

IMO, they should actually not be given scrum master or product tasks and such. Their value is architecting the team not really being in it, though being hands on may give him better insight. A company should not have too many of them either; one can maybe handle 30 engineers. The low level managing can be done by other managers. A proper Product Manager should be dealing with customers and understand products better than the engineers, and as she's a manager, she can do the sprint stuff too.

There are a lot of variations of EM.

Think of an EM role as being like a moldable puzzle piece.

In your case, it sounds like EMs are molded to be project managers.

It's hard to know if that's right or wrong from your reply because we're missing the context of why the EM does spring planning.

If the EM needs to fill a project management void for reasons then that's what the EM needs to do.

Pods or verticle teams could work if they could work in your team or company. I know that sounds like a tautology, but it's true. There is no universally better team, process, or culture structure as it's all contextual to the people, team, company, and product you're creating.

I’m not sure how to put this nicely, but your managers don’t seem to have had good management training. The first clue is that they assign work. Your shop works in sprints, so I presume they’re trying to do agile. Management assigning tasks is the opposite of how it’s supposed to go.

Ideally, an engineering manager makes sure the team has what they need to be successful. Resources, processes, goals, training, etc. Is all of that taken care of and they want to be more involved?

the "manager" part should answer your question...they basically are expected to have meetings...what they gather in one meeting they parrot out in the next one...biweekly meetings with the subordinates? oh im sure their trying hard to minimise those with all sorts of reporting, timesheets, jiras, and whatnots

The most succinct, but not necessarily most useful, description I have heard of a good engineering manager is that they identify and remove obstacles in the way of engineers getting things done.

In practice, my experience has been that a typical engineering manager has to work in varying degrees across several dimensions of management:

- People management: performance evaluation; career development; keeping people happy; being a "first responder" to deal with issues before HR needs to get involved; resolving interpersonal issues to prevent them from affecting team performance; managing team morale.

- Project management: figuring out (by negotiating with non-technical staff and within the technical team) who should do what when; and making sure it gets done.

- Technical leadership: guiding design and architecture of the system; deciding / influencing the tech stack; setting and maintaining standards and best practices. Staying reasonably close to hands-on work, avoiding the critical path but staying informed enough to make the high-level decisions effectively.

- Product management: If the dedicated PM staff are not effective at defining the requirements, or are not technical enough to properly communicate them in a way the engineers can act on, an engineering manager often has to step in and fill the gap.

- Managing up / sideways: keeping higher-ups apprised of status and roadblocks, and feeding relevant information back to the team; depending on the manager's level and the size / structure of the organization, working with other functions in the company (sales, marketing, accounting, legal, ...) to the extent that these functions interact with engineering.

- Hiring: identifying what the team needs; working with HR/recruiting to find the right talent; being the first line of screening so that the engineers don't waste their time interviewing bad candidates.

All that is to say: yes, your sense that something is off with engineering management in your organization might be correct. "Might", because you might not actually be seeing all the activities they are doing. One thing I would say is that if your manager does not do a regular 1:1 meeting with you, focused on the people management aspect, that is a red flag.

Your comments about ineffective sprint planning and the siloing of backend vs. frontend teams ring true. I have seen "agile" processes done well and done badly. Having cross-functional / "vertical" teams generally works better. But it can be harder to organize things that way in large companies where there is a perception that functional specialization (e.g. grouping all the backend engineers under a backend manager) is more efficient.

Absolutely nothing. (In best case scenarios.) They’re the lowest IQ people in the org, so let’s put them in charge. “Which company do you work for? A major one.”

Sadly this seems universal in Big Tech.