The way I look at it is: Software companies which lean-into rather than fight against an engineer-centric corporate architecture will be better-setup to be more productive and ship higher quality product than any other architecture. They won't always be, every company is different, but its the best starting place because at the end of the day your engineers are your bottleneck. The engineers implement asks from Product Managers, Owners, Designers, Leadership, Marketing, Sales, Customers, Vendors, other Engineers/Themselves, all of these sources of work flow downhill to engineering and need to be triaged and prioritized.

So, at least for the roles engineers work most closely with (PM/PO/Designer/etc), it is productive and good that these roles are framed in the perspective that they're a service & asset role for engineering; that when engineering needs designs, they go to a designer, that when engineers need an answer to some product behavior question, they go to the PM, who would reasonably be if not the source of truth at least the authority of that domain, etc. That's only subtly different, but definitely meaningfully, than what the GP poster was saying about running the sprint board and controlling what work gets taken on; PMs/POs shouldn't have that authority, that authority lies with the EM and their discussions with the priorities of leadership.

And, by the way: calling back to my previous comment, I've worked in roles where the EMs were less-technical more-product, call these companies "product led companies", and each team had almost a bi-archy of an Engineering Manager + Engineering Lead representing two sides of this coin. This works really well. If you want a product-biased company, hire product-minded managers, but give engineers a 10-20 year title track that doesn't involve management. If you want an engineering-biased company, promote or hire engineers; this can work for more hard-tech infrastructural companies. If you struggle to find great talent, hire dedicated PMs but have them report to your product or engineering-minded EMs. That's it.

I don’t think I made that argument. I’m advocating for focus from the engineers. Focus on architecture, code quality, tech debt, etc.

Focus on that stuff also means NOT having engineers doing other things, like sitting in a booth at a conference, playing with color schemes in Figma, creating financial projections for a new feature, etc, etc.

Engineers should do what they’re good at, and POs should do what they’re good at. Side quests are fun, but don’t help the business work efficiently.