Oh man do I have opinions.

First of all, I've seen all type of teams be successful, ranging from zero QA at all, to massive QA teams with incredible power (eg. Format QA at Sony in Europe). I have absolutely seen teams with no QA deliver high quality full stop, the title is nonsense.

My firm belief is that QA can raise the ceiling of quality significantly if you know what you're doing, but there is also huge moral hazard of engineers dropping the ball on quality at implementation time and creating a situation where adding more QA resources doesn't actually improve quality, just communication churn and ticket activity. By the way the same phenomenon can happen with product people as well (and I've also seen teams without product managers do better than teams with them in certain circumstantes).

The most important anchor point for me is that engineering must fundamentally own quality. This is because we are closer to the implementation and can anticipate more failure modes than anyone else. That doesn't mean other roles don't contribute significantly to quality (product, design, QA, ops absolutely do), but it means we can't abdicate our responsibility to deliver high quality code and systems by leaning on some other function and getting lazy about how we ensure we are building right.

What level of testing is appropriate for engineers to do is quite project and product specific, but it is definitely greater than zero. This goes double in the age of AI.

> The most important anchor point for me is that engineering must fundamentally own quality.

This is huge. I was selling software to help QA. I saw a CEO demand a Head of QA guarantee their super buggy app be free of bugs by a certain date.

This is terrible. She didn’t write the thing. Total responsibility without authority trap. She was, not at all to my surprise, fired.

I think the deal fell through and I don’t know how else things ended up with them.

QA’s job is signal. If you’re getting clear signal, they’re doing their job.