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.