Everyone owns quality. Nobody knows what that means
When organisations cut QA headcount, they redistribute the work without redistributing the definition — and most of the time, nobody notices until production does.
There's a genuine argument for developers owning quality. When a team is responsible for what it ships — end to end — quality stops being a handoff problem. It gets built in rather than bolted on. Feedback loops tighten. Defects get caught earlier, by the people with the most context to fix them. It's less rework, not more.
Most QA headcount reductions just aren't that argument in practice.
What is the work?
Before asking who owns quality, it's worth asking whether anyone has agreed on what quality work actually is.
Is it writing tests? Reviewing acceptance criteria before dev picks up a ticket? Running exploratory sessions? Tracking defect patterns over time? Flagging when the test environment is unreliable? Someone has to answer that — and the answer has to be shared, not assumed.
Most organisations skip this step. They remove the function, point at the developers, and call it ownership. What they've actually done is distribute responsibility without distributing definition. The work isn't transferred. It's orphaned.
Do people have capacity to do it?
Even when the work is named, the people now responsible for it already have full jobs.
Developers absorb quality work imperfectly and inconsistently — not because they can't do it, but because capability is different from capacity, and both are different from the habits and systems that make quality reliable at scale. Quality work done in the gaps looks different from quality work done with focus.
That gap doesn't show up in the sprint. It shows up in production.
I've been writing about quality for 30 years. Now you can ask that body of knowledge a question — free.
Try the free taster →The delayed bill
Defects found in production cost significantly more to fix than defects found during development. The exact multiplier varies, but the direction doesn't. Catching something before it ships is cheap. Catching it after isn't.
A headcount reduction in QA is a bet that the redistribution will work — that developers will absorb the work at sufficient depth, consistently, without specialist support. More often than not, it becomes a risk transfer: from this quarter's budget to future engineering time, customer trust, and incident response.
By the time the bill arrives, the causal chain is hard to see. The reduction looks like it worked.
Two questions before you decide
Should developers own quality? Yes — and the organisations that make it work are worth learning from.
But has anyone named what the work actually is? And does the person now carrying it have the time and tools to do it?
If not, the work hasn't moved. It's just no longer visible enough to manage.
Quality Coach Assistant
Welcome! Ask about quality coaching, leadership, and engineering culture.
Comments ()