>I mean sure, but that's not evidence of best practice with any sort of rigor around measurable outcomes.

Of course, it is not. I doubt that there exist many management practices that were measurably proven to be effective. It's just an explanation why I perceive those as best practices. They have worked for me and my peers in a reproducible way.

>my suggestion that there's other successful ways to run a team >Learn to deal with dissenting opinion

Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?

> Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?

Killing shitty meetings, including the standup, was one of those dissenting opinions, obviously.

Here's another.

PMs, or any other role that abstracts the developers from value, serve to infantilise the developer. Instead of owning the most expedient way service a customer or generate revenue, they're instead owning the minutia of frameworks, architecture, or tooling.

Of course, you can still make an argument for the PM via efficiencies and skill specialization, but when you effectively give a non-technical person control of what the team works on, you in many circumstances no longer have a person with a view across both commercial and technical realities.

And whilst there are many ways to try and plug this gap, like Engineering Managers or arguments like you're holding it wrong, where exactly are these tech leaders learning those skills when in the vast majority of teams the PM keeps them in the dark? Thus, propagates the cycle where the technical are not commercially mature enough to make business decisions, which necessitates the need for adults in the room.

Point being, it's a trade-off and there's circumstances where the trade-off makes sense, and others where it doesn't.