It's hard to believe something when I saw the opposite work in practice. Removing QA makes developers care about production. You can say now they are wasting part of their time doing what QA did but to me it's not wasted time. Incidents went down both times I saw it happen, and stayed down.

Just to offer a different perspective, my last job removed QA and it was a nightmare. Feature delivery slowed way down and incidents and bugs went way up to the point where we started losing customers.

In theory, I agree with what you're saying, but I think a codebase needs to be in a certain state and a company's leadership needs to be in a certain mindset to make it work. Our codebase was far too large and interconnected for any developer to fully understand all of it because of years of building with unclear boundaries between teams. QA's value wasn't really the testing they did. The value was that we had a dedicated team who's job it was to see the big picture and keep up with the changes 15 different teams were making on the same product. Management wanted the benefits of removing QA without the pain of paying down all the organizational and tech debt that made them valuable.

Again, I agree with your sentiment, but also, I think that most large organizations are not willing to do the necessary work to get a place where QA can be removed.

> Removing QA makes developers care about production

And removing Product Managers makes devs care about the product. Therefore, we should strip away all roles apart from devs..?

These roles exist because the skill set is sufficiently large to justify a dedicated role. If you're a startup, sure - maybe it's better to be lean - but in a larger org, QA folks are worth the investment and can definitely help to spot things that devs may not otherwise catch themselves since they know the product intimately and likely learn of common pitfalls. The few QA folks I've worked with have been worth their weight in gold.

People are good at different things. Usually they like the things they are good at and vice versa. Different tasks require different mind sets and dev, QA and ops are vastly different in that regard. That is why we have assembly line production in basically every industry except software.

Really depends on what you're having QA folks do.

Writing automated end-to-end tests? Those are very often best done by those writing the software, with assistance from experts who know how to effectively build test infrastructure. I've very rarely seen them done effectively by QA or "test engineering" folks.

Running manual test scripts and torture testing the UI to break it in new and unusual ways? Definitely get dedicated testing / QA folks. It's very easy to be blind to how others might use the software, especially if you wrote it.

I agree. I saw the same.

Hold up... We saw it at the same place :D

Entirely dependent on what you're shipping.

If there is a significant amount of user interaction to test, QA is going to do a better job than devs.

If there's a lot of integration behind the scenes with a ton of edge cases, devs will do a better job.

If you have both (probably), you need both teams to pitch in more than upper management wants to believe and they'll just cut you instead! :D

I struggle with this question a lot: when does specialization make a team better, and when does it start to erode ownership?

When I first joined Amazon, my team had no dedicated QA, Product Manager, Technical Program Manager, or frontline support team. I had come from a startup where none of those roles existed either, so it felt normal. Engineers also carried the pager and dealt directly with the operational consequences of what they built.

Since then, I have worked with teams of very different sizes and levels of product complexity: internal and external products, Tier 1 services and much less critical systems. Some had every specialization—QA, PM, TPM, and a dedicated support organization.

On a few of those teams, I encountered a very different engineering culture. Product understanding was the PM’s job. Quality was QA’s job. Delivery coordination was the TPM’s job. Customer problems were support’s job. Collectively they had created enough distance that engineers no longer felt accountable for the whole outcome.

For me it is less about whether a team has QA, PM, TPM, or support line, and more about whether those roles increase the team’s capability or partition its accountability.

The litmus test I use is the 3 a.m. page: does the engineer have enough situational awareness to understand the customer impact, navigate the system, make a credible mitigation, and help drive the permanent fix? They do not need to be experts in every discipline, but they should understand the product and system well enough to own the outcome.

Specializations are necessary as systems, products, and organizations grow. But it has gone too far when engineers can no longer operate effectively without every specialist standing beside them.

I am also exposing my own bias here: I believe engineers should carry pagers. That is how I grew up professionally, and I think direct exposure to production consequences produces materially better engineers.