A separate QA role makes developers slack

We noticed this pattern at customers long before I had a clean explanation for it. The teams with a dedicated QA person, or a whole QA stage, were not the teams that shipped the fewest bugs. Often it was the other way around. As soon as there was somebody whose job was to find the problems, the developers relaxed. Why think hard about the edge cases of this change when there is a gate downstream that is supposed to catch them?

People will tell you that quality is then a shared responsibility between development and QA. In practice shared responsibility, when it is this fuzzy, is no responsibility. The developer assumes QA will catch it. QA assumes the developer thought about it. The gap between those two assumptions is where the incidents live. A team has to know, without any ambiguity, that it is fully in charge of what it delivers. The moment you add a role that implies otherwise, you have taken that ownership away, and you will not get the quality back that you lost.

The author knows the dangerous cases

There is a second problem, and it is more practical. The person who wrote the code knows where the bodies are buried. They know which branch they were unsure about, which external call they did not fully trust, which state transition was awkward to get right. That knowledge is the most valuable input you have for testing, and a separate QA function throws most of it away by design, because it tests from the outside.

External testing finds the obvious things. The dangerous cases, the ones that take down production at the worst possible moment, usually sit in the parts of the code the author already felt uneasy about. If you want those covered, the person to cover them is the one who felt the unease, while they still feel it, not a tester reconstructing intent from the outside weeks later.

But who owns the business perspective?

The strongest objection I hear is about perspective, not mechanics. The claim goes: developers think about code, and QA brings the perspective of the user and the business. Somebody has to ask whether the feature actually solves the customer's problem, not just whether it is technically correct.

I agree that this perspective matters. I disagree about who owns it. A developer taking responsibility for the business usefulness of what they build has always been non-negotiable for me. If a developer on my teams could not explain what business problem a change solved, that was a gap to close, not a reason to add a gate behind them. You close it by pairing them with a product person, or by letting the team work the problem together, until they understand the use case well enough to own it.

There is a kind of QA-minded person who is genuinely good at this: someone who enjoys mapping out every way a complex workflow can be misused, every input a user might throw at it, every order in which steps might happen. That is real skill and you want it on the team. But a good product person has the same instinct and brings the business context with it. So hire that thinking into the team. Do not build a department around it and call it a checkpoint.

You still have to catch what you miss

None of this means you ship and hope. Dropping the QA gate only works if you are honest that your team, like every team, will let things through. The difference is where you spend the effort: not on a person re-checking work before release, but on being able to detect a problem in production fast and react to it fast.

At Frontastic we had no QA team. Developers owned quality end to end. What made that safe was not heroics, it was the boring machinery around it: automated checks that ran on every change, enough observability to see when something started behaving badly, and an on-call setup that let us react in minutes rather than the next morning. Quality assurance, in the sense that mattered, was the team plus that machinery, not a separate stage.

This matters more now, not less. With developers generating large amounts of code through LLMs, the temptation to insert a human gate that "checks the AI's work" is strong, and it is the same mistake in new clothing. The team still owns what it ships, whether a person or a model wrote the line. The answer is the same: ownership in the team, automated checks, fast detection, fast reaction.

Summary

Do not set up quality assurance as a separate activity. A dedicated QA role takes ownership away from the people who write the code, and ownership is the thing that actually produces quality. Keep the perspective a good tester brings, but keep it inside the team, alongside the business context a product person carries. Then spend your effort on detecting and reacting to production problems quickly, because that is honest about how software really fails. The same argument applies, almost word for word, to code reviews. I'll get to that next.