The Cargo Cult of Eliminating QA

I recently learned what a “cargo cult” was. Apparently, there’s a story from World War II that goes something like this.

When American forces set up military bases on remote South Pacific islands, they brought everything with them — jeeps, radios, canned food, medicine, aircraft. To the indigenous islanders watching from the treeline, the goods seemed to appear almost magically. Planes landed. Supplies materialized.

When the military left after the war, some islanders wanted those goods to return. So they did the logical thing based on what they’d observed: they built wooden airstrips, lit fires along the runways, carved wooden headsets, constructed mock control towers, and performed the rituals they’d seen soldiers do.

They replicated every visible behavior perfectly. And waited.

The planes never came back.

Anthropologists called it a cargo cult. The islanders had copied the form without understanding the function. The ritual looked identical. The outcome was completely different.

I came across this word because my manager teased about getting rid of QA and I was researching companies that announce they’ve “eliminated QA.” Microsoft is the clearest documented example of what I found.

I should say upfront: I haven’t worked in big tech. What I have done is read what people inside big tech wrote about eliminating QA and noticed what they didn’t notice about their own story.

What Microsoft Actually Did

Gergely Orosz wrote a detailed breakdown of how big tech handles QA (The Pragmatic Engineer). The Microsoft section is publicly available, and it’s worth reading carefully for the details he includes along the way — not for the conclusion he reaches.

Microsoft pioneered the SDET role. These were software engineers focused entirely on testing — catching edge cases developers missed, building testing infrastructure, thinking about quality independently from the people writing the production code. For years, a 2:1 developer to SDET ratio was standard.

By most accounts, it worked. Gergely himself describes pairing with an SDET and being surprised by their resourcefulness. He notes that SDETs were good at catching edge cases developers hadn’t considered.

Then he describes why it got eliminated.

Developers found the back-and-forth annoying. A bug would come back from the SDET, get fixed, go back to test, come back again. It created an “us and them” dynamic. Some developers looked down on the SDET role as less technically challenging. The friction felt like inefficiency. This is the typical dev vs. QA story — for unhealthy, immature quality orgs.

So Microsoft quietly started merging the roles. SDETs became developers. Developers owned their own testing. The independent check disappeared.

Gergely frames this as a productivity win. And I’m sure by certain metrics it was. But read what he’s actually describing: a team that was uncomfortable being held accountable by a separate function, and had enough organizational power to remove that function and call it an engineering decision.

I’ve seen this dynamic from the outside. When I was working as a testing vendor, I experienced it firsthand with a Netflix engineer. On the surface he worked with us fine — his manager wanted the team to use our manual testing. But whenever we sent bugs over, he was consistently dismissive and would try to justify why it wasn’t a bug. Just one person, just one example. But it lines up exactly with what Gergely describes at Microsoft.

This Is Happening Closer to Home Than You Think

I have never seen QA get eliminated in the companies I worked at, fortunately. But my manager has teased it and even raised concerns about it around our job security. He’s always looking to professionalize our team and looking at the big companies like Google, Microsoft, Spotify, and how they build their QA teams. And it’s scary.

This is why I’m writing this post. Because we’re a small startup of 30 engineers and yet here we are trying to replicate how other large orgs do it. I’ve written before about how QA is risk management and how there is no “perfect” QA process. It’s scary to hear we’re trying to replicate companies that may not actually understand QA well — and that we place them on a pedestal just because they’re big, and perhaps have the maturity and infrastructure to make it look like it works without dedicated QA functions.

Ego and Ignorance Aren’t the Same Thing — But They’re Related

Here’s what I think happened at Microsoft, and what I think keeps happening across the industry.

The ego part is obvious. Developers didn’t like having their work sent back. Nobody likes that. But ego alone doesn’t explain why smart, thoughtful engineers concluded that the solution was to eliminate the independent check rather than improve how it worked.

The ignorance is what made the ego possible.

I’m tempted to call the SDETs QA, because that’s what they are and should be proud of that. Their job wasn’t just “finding bugs I missed” — it was maintaining an independent view of the system that structurally cannot exist inside the head of the person who built it. If developers had truly understood that, they couldn’t have rationalized the decision. The value would have been too clear. You can be annoyed at something and still recognize you need it.

But they thought QA was testing. And testing is something a smart developer can do themselves. So the friction felt like pure overhead, the independent thinking felt like redundancy, and the bugs coming back felt like inefficiency rather than the system working correctly.

That last part is the thing I can’t get past. The bugs coming back to developers was not a flaw in the model. It was the model working. An independent function caught something the developer missed and surfaced it before it reached a customer. That’s the entire point. Perhaps, they could have improved the process by shifting left and prevented the bug from leaking in the first place — and I don’t mean add more automated tests, I mean thinking about the risk so it never gets introduced.

They mistook accountability for inefficiency. And because they never understood why the independence mattered, they had no framework to recognize what they were actually eliminating.

One developer who lived through the Microsoft SDET elimination later wrote that the message the company sent to QA practitioners was essentially that their core professional skills weren’t useful anymore. He found that harder to receive than a normal layoff. At least a normal layoff is about money. This was a statement about value. (The Slaughter of QA)

What Google Actually Did

Google is the company most often cited as proof that you don’t need dedicated QA. But Google’s own testing blog tells a more complicated story.

Google didn’t eliminate QA thinking. They renamed it and distributed it. They maintained two distinct roles — Test Engineers with deep product knowledge who focused on what should be tested, and Software Engineers in Test who built the automation infrastructure. The title of that blog post says it all: From QA to Engineering Productivity (Google Testing Blog). They didn’t eliminate the function. They rebranded it.

What looks like “no QA” from the org chart is actually QA everywhere, unlabeled. The work didn’t go away. The job title did. I don’t know why people are so afraid of the “QA” label and try to distance from it.

And even then, the broader pattern across big tech is well documented. Facebook had no dedicated QA team as early as 2011. Microsoft eliminated the SDET role in 2014, bundled into an 18,000-person layoff. Yahoo made headlines the same year with a viral story celebrating engineers shipping with no safety net. The “traditional QA is dead” narrative has been cycling through the industry ever since — every few years with a new villain, whether automation, Agile, shift-left, or now AI. (QA Is Dead: 2005 vs 2015 vs 2025)

The script is always the same, but the outcome is rarely what gets reported.

What Actually Got Copied

When companies today say they’re doing what Google did, what Microsoft did, what Netflix did, they’re copying the org chart. No dedicated QA. Developers own quality. Ship fast.

Absolutely. Developers should own the quality of their code. Product managers should own the quality of their requirements. QA should own the quality of the risk information we provide. We should all take ownership of quality. But owning quality and being equipped to do it are two different things.

What they’re not copying: the tooling investment that took years and significant resources to build. The scale that absorbs quality failures before users notice. The specialized engineers — accessibility, reliability, performance, security, internationalization — who each carry a piece of what QA does under different job titles.

Netflix didn’t just remove QA and hope for the best. They built Spinnaker for continuous delivery, Atlas for monitoring, ran real engineering bootcamps, and built a culture of accountability where if your service breaks production, you fix it. Google’s culture treats quality as an engineering responsibility from day one, with code reviews that check test coverage. Both companies share two things most companies don’t have: mature engineering culture and massive investment in tooling built before anyone was let go. (The QA Team Debate: When Elimination Works and When It Destroys Everything)

Most companies copying this model don’t build any of that. They just stop doing the work.

Nobody is doing the independent analysis of a built feature — approaching it without the curse of knowledge that makes developers blind to their own work. Nobody is maintaining the system-wide view of what’s working, what’s fragile, where recent changes might ripple in ways the feature team didn’t consider. Nobody is thinking about what the user actually experiences versus what the spec said they should experience.

The consequences are real and documented. When Indeed eliminated its QA function entirely in 2023 as part of layoffs, engineers who remained reported that test quality immediately nosedived. That’s not a rumor from a QA community forum — it’s the account of people who were inside the building. (Where Have All the QA Gone?)

Years Later

There’s a version of this story that developers who lived through it have started to admit, quietly, years later.

One put it this way: those of us who remember working with a high-functioning QA team can impersonate some of those behaviors. But newer engineers and managers have no idea what any of it was about, and aren’t able to tell what’s missing. (Maybe Getting Rid of Your QA Team Was Bad, Actually)

That’s an obvious conclusion that a lot of QAs can assert when a company contemplates getting rid of QA. But for others outside of QA, they don’t realize it until later. The damage is invisible to the people who made the decision, because they don’t know what they’re not seeing. They can’t feel the absence of something they never fully understood.

The gap left by QA doesn’t show up cleanly on a dashboard. Bugs get blamed on individual developers. Churn gets attributed to product-market fit. Eroded user trust gets called a competitive problem. The decision to eliminate QA is rarely the named cause, because the people who made it don’t have the framework to connect it to the consequences.

For a company with a billion users and world-class incident response infrastructure, some of that might genuinely be fine. The scale absorbs the damage. The feedback loops are tight enough that things get caught and fixed before they compound.

For a 30-person engineering team at a company where teachers and students depend on the product working every day? The math is completely different. You don’t have the infrastructure. You don’t have the scale. You don’t have the tooling that makes the model work. Maybe that’s why the developers on my team appreciate our QA so much — because they don’t have the maturity and infrastructure to hide the collapse that would happen without us.

What your small company that still has a QA team has is an in-house group of real users, a dedicated team that knows your system, catches what developers miss, and maintains the independent view that nobody else in the building is structurally positioned to hold.

Copying the org chart of companies that don’t need that — because they built everything else first — is building the wooden airstrip.

The headsets look exactly right. The planes still don’t come.