I think there is such a position. If there are multiple teams, then it's important for someone (a good programmer, but whether they're called "manager" or "lead" or "architect" isn't the point) to have a good understanding of what's going on in all of the teams simultaneously. That person can notice problems that the programmers down in the weeds (even if they're called "senior developer" or "lead") might not be able to see, or might not even think of as being a solvable problem.

Doing this properly for 3-8 teams might well leave that person with little time to contribute meaningfully to any given project, but the bird's-eye view can be very much worth it.

So what you're describing is a 'senior developer' or 'lead developer', who is noticing that the build system is an issue, and reporting it up and suggesting issues.

Whereas I said "If you have good devs, the other teams will have communicated that up".

The only difference I'm seeing is you're positing someone who is aware of developer issues, and 'with little time to contribute meaningfully'. How, if the person isn't developing, is he/she going to be able to tell what the development issues are? He/she can't just ask the developers; if they're aware of it they're not 'down in the weeds', and just communicating it upwards is enough.

I'm pretty sure this issue is best served with a retrospective.