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.
However, there were too many cases that things were delivered as “ready” when they were not. PR review was not enough as everyone were checking diffs from GitHub only.
I implemented an intermediate step where the responsible engineer must post a screenshot or a short video of the ticket before passing to the PM and that alone resolved a lot of issues before they materialized on customers screens, just because you must take the extra effort to work on a proof of work.
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.
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.
This so much - but most of the places I've worked at have insisted that manual testers with zero programming experience should build and maintain the test frameworks. Talk about trying to push a square peg into a round hole. Granted some of the testers have embraced it and not done a terrible job but by and large most of the testers have had no idea and done very little.
Hold up... We saw it at the same place :D
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
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.