This question comes up in every leadership room eventually, and it came up at one of our recent events.
It’s usually asked after a painful release. Or maybe a production incident, or a period where things technically “ship”, but don’t quite hold up.
Then, the question is almost always framed as a motivation problem. When that often isn’t the issue at all.
Teams rarely fail to own quality because they don’t care, they fail to own it because the system around them makes ownership irrational.
One of the clearest patterns we’ve seen in our work and amongst our teams is this: quality improves the moment engineers feel accountable for what happens after deployment.
Not symbolically accountable, or the “we all own it” accountable, actually accountable. It can be tricky to make this happen without feeling like you’re piling on undue pressure, but it is possible.
When engineers are on-call for their own systems, behaviour changes. Decisions get simpler, trade-offs get clearer, shortcuts become less appealing because there’s an awareness of the issues these can cause later and a knowledge that they’ll be the one dealing with remedying them.
Again, this shouldn’t be framed or thought of in the vein of ‘punishment’, you can think of it in terms of feedback loops.
If one engineer builds it but someone else carries the operational cost at 3am, quality is theoretical. If that same engineer builds it and they’re the one staring at logs when it breaks, quality becomes practical.
That sense of accountability changes behaviour more reliably than review comments ever will
But, this only works if ‘on-call’ is treated as learning, not blame. Otherwise, you can end up creating fear, which is a far greater problem to tackle.
Fundamentally, “everyone owns quality” is not a strategy. You can say this for the purpose of camaraderie, but you can’t implement structures that way. It’s a recipe for disaster.
Another problem that occurs when leadership say that quality is everyone’s responsibility, is knowing who needs to look at what and how to raise specific issues. If quality belongs to everyone on an even and spread out keel, then people don’t know how to act. No one knows who can stop a release. No one knows what the quality bar actually is. No one knows when escalation is appropriate.
Shared responsibility without guardrails creates ambiguity. Ambiguity can lead to mistakes, or even inaction altogether.
The strongest teams we’ve seen combine three things:
Quality gates that can’t just be negotiated away in Slack. Thresholds that are explicit, designated team members with the authority to say ‘stop’ when something fails.
Without this, “everyone owns quality” quickly becomes “whoever shouts loudest wins”.
There’s another uncomfortable truth that we felt was important to mention here. Simplicity drives quality, even if you want a big, fancy product.
Over-engineered systems are just harder to work and reason with. Harder to onboard into, and harder still to work with at scale (and, ultimately, a lot of people have the goal to scale).
The best engineering cultures we’ve seen value simplicity over elegance, and that’s not because they lack skill. It’s because they understand where quality lies, and that an emphasis on complex tech will leave the next team that works with it a bit in the lurch.
When simplicity is rewarded, quality becomes sustainable.
So, how can you encourage your teams to own quality? Try the above, and see how you get on.