>The developers MUST care for the quality, not outsource it to some external team. The desire of large corps to spend huge amount of $$$ to create artificial roles to water down ownership can never cease to astonish me.

As a former quality-focused dev, I can tell you that the industry beats it out of you with a club. There is always somebody above you who cares only about their own career ambitions and has more leverage than you do. This leads to a horde of devs who just do what they're told and not much else.

Businesses are all about risk management. The safest way to de-risk a business is to water down ownership, at the cost of injuring quality-focused devs. You're only a cog. You need to only be a cog to them. They must to be able to replace you with another cog when you leave for greener pastures.

  > I can tell you that the industry beats it out of you with a club.

yep, i can say i've seen this over and over; more than anything incentives are for the next okr or whatever to be completed so they can move on to the next one asap.

i've seen pr's sent out for review that literally didn't work or crashed immediately on use... as if the expectation is qa will report whatever needs fixing but thats fine cause its "in qa now" so development is "done".

That’s just Goodhart’s law.

"When a measure becomes a target, it ceases to be a good measure".

I don't disagree with you, I've seen the same (a lot) but you can still go to another company that prioritizes quality a little more.

Definitely can take a while to find one though, that much is true.

> advocating for better <topic of choice> is money much better spent

That seems like a very Bay Area mindset - advocacy is more lauded than doing something.

Fair enough!

I used "advocating" loosely here. I hate the "advocate a lot, build nothing" mindset myself, and I am not a fan of the Bay Area and its practices (to put it mildly), so I edited my post.

What I mean is devs making tools for devs, resulting in better overall quality.

Sorry, that was a bit to snarky. While I don’t agree with not having dedicated QA, I completely agree with devs being responsible for the quality of their area and adjacent areas.

In my experience good test engineering teams can focus on having a more global view of systems while not being biased by implementation details.

You are so right on the QA thing and so wrong on the PM thing. If you have a PM that just came out of uni, your company has no idea what they are doing. Good PM's are really really good at communicating at multiple abstraction levels within multiple levels of the organizational hierarchy. Why? Because they have to build consensus and coalitions to get the things ( money, people, buy-in, details, information ) required to build really good software and build all the ancillary things to sell and support that software. I think what you are calling a PM is what I call a jr. project manager.