Also as commented, the OP makes too many implicit generalized assumptions about the org: that PM and developers report to a similar management chain (that's often not the case, depends on the org) or at least is aligned with compatible incentives. Their throwaway remark "if the engineering team is much less tenured than the PM" and the lack of inquiring about why that scenario might have arisen makes you wonder, too.
The link to that exact article is literally the first sentence of this one.
Conversely in this article the OP makes cryptic hand-waves towards "As always with power balances, just be gracious... Know that there are implicit power dynamics that should be managed graciously... So, be a good partner...", but what they write feels like they only view it as a one-way partnership, and makes it sound like they don't care if the developers are getting the short end of the stick. Or, they're trying to make a faulty generalization from their personal experience to other orgs where developers and PMs report to different chains and have very different incentives, as again other people here had already commented [1] before your post.
Your comment isn't constructive, and it intentionally misrepresents what I had clearly already written above half a day before you posted it. Please don't do that again. [2]
And I didn't make a "suggestion", I critiqued the OP's absence of having actually written something genuinely reciprocal like they said they had.
[0]: https://news.ycombinator.com/item?id=36466224
The OP claims:
> A common area for things to get messy is QA. In many agile teams, PMs end up doing UAT or requirements checking before tickets go live... A common way this happens is if the engineering team is much less tenured than the PM, and the PM knows how to test better than the engineers. In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP.
Well that's one possibility, but I've never seen it in reality, let alone call it common. Another strong possibility is that the team (PM in particular) didn't spend enough time thinking through use-cases and writing acceptance tickets. And/or that whoever's supposed to be communicating with the customer isn't doing that well. Or that the customer themselves doesn't understand their needs well (in which case quickly getting them an MVP without much acceptance testing is entirely the right thing to do, then iterating). So, less blamespreading, more the team rolling their sleeves up. Especially if the PM really aspires to be a "partner" to developers (as they say elsewhere).
And btw if the "engineering team is much less tenured than the PM", then that suggests trying to scale too fast, or antipatterns in hiring/ development/ budget/ management/ retention/ compensation (for example any developer with half a clue in that org would eventually either quit or try to jump ship into PM). The solution isn't always to whip the developers harder.