Building a Quality Culture
You can’t mandate quality into existence. You can’t assign someone to be the “quality person” and expect magic to happen. Quality culture grows organically - but only in the right conditions.
I’ve seen teams with impressive quality processes produce absolute garbage. And I’ve seen teams with barely any formal processes consistently deliver excellent work. The difference isn’t in the procedures. It’s in the culture.
What Quality Culture Actually Looks Like
A real quality culture has some telltale signs:
People ask “why” before “how”. When someone proposes a solution, the first questions are about the problem they’re solving, not the implementation details.
Failures are learning opportunities, not blame targets. When something goes wrong, the conversation focuses on “how do we prevent this” rather than “who screwed up.”
Everyone feels ownership of quality. It’s not just the testers or the tech leads who care about doing things right - it’s everyone.
Trade-offs are discussed openly. Teams don’t pretend they can have it all. They explicitly discuss what they’re optimising for and what they’re willing to sacrifice.
Standards are defended collectively. When someone suggests cutting a corner, others push back not because they’re rule-followers, but because they understand the long-term cost.
The Building Blocks of Quality Culture
Creating this kind of environment isn’t about grand gestures. It’s about consistently reinforcing the right behaviors and making it safe for people to care about quality.
1. Make Quality Everyone’s Job (And Define What That Means)
The phrase “quality is everyone’s responsibility” is thrown around constantly, but what does it actually mean in practice?
For different roles, it might look like: Developers writing tests, considering edge cases, thinking about maintainability. Product managers understanding user needs deeply, being honest about trade-offs. Designers testing usability with real users, considering accessibility. Support providing detailed feedback on common user issues.
Don’t just say everyone owns quality - show them what quality ownership looks like in their specific role.
2. Create Psychological Safety Around Quality Concerns
People need to feel safe raising quality concerns without being labeled as “blockers” or “perfectionist.” This starts with leadership behaviour.
When someone raises a potential issue: thank them for bringing it up, engage with the concern seriously (even if you ultimately decide it’s not a priority), and never punish people for being “too paranoid” about quality.
I’ve seen too many teams where people stopped raising concerns because they got tired of being told they were overthinking things.
3. Build Quality Into Your Processes, Don’t Bolt It On
Quality can’t be an afterthought. Build it into how you work:
Code reviews that focus on more than syntax. Look at design decisions, consider maintenance implications, think about edge cases.
Definition of done that includes quality criteria. Not just “feature works” but “feature is testable, diagnosable, and maintainable.”
Regular retrospectives that include quality discussions. What quality issues came up this sprint? What could we do differently?
4. Measure and Celebrate Quality Wins
As we discussed in earlier posts, you need metrics that actually reflect quality. But beyond measuring, you need to celebrate when those metrics improve.
Did deployment success rate increase? Call it out. Did time-to-fix decrease? Recognize the team efforts that made it happen. Did customer satisfaction scores improve? Share the impact with everyone involved.
People repeat behaviors that get recognised.
5. Invest in Learning and Growth
Quality culture requires continuous learning. People need to understand not just what to do, but why it matters.
Share post-mortems widely. When interesting problems occur, don’t just fix them - help the whole team learn from them.
Encourage experimentation. Create space for people to try different approaches to quality challenges.
Support conference attendance and training. Invest in people learning about quality practices and bringing new ideas back.
Common Pitfalls to Avoid
The Quality Police Trap: Assigning one person or team to be the “quality gatekeepers” often backfires. It lets everyone else off the hook and creates an adversarial relationship.
The Perfect Process Fallacy: Believing that if you just get the right processes in place, quality will follow automatically. Processes are tools, not solutions.
The Education-Only Approach: Thinking you can train people into caring about quality. Knowledge is necessary but not sufficient - you need to create conditions where caring about quality is rewarded.
A “Real” Example: Transforming a “Good Enough” Culture
Ahem. Usually I like to use concrete examples from my own experience, but in all honesty my own experience in improving things has always been “try lots of stuff and keep what works” which would make for a much longer and more rambley example. The fictitious team in the example here is actually an amalgamation of several from my past and successfully implements things far faster than the real world teams that inspired it (and who had lots of other false starts and dead ends which I’ve quietly elided away below!).
Our team starts, as many teams do, with a serious “good enough” problem. Features shipped with edge case issues, and an ever-growing bug backlog. The overall attitude is “if customers aren’t complaining loudly, it’s fine.” But context is changing and so while “good enough” was once OK, “good enough” quality is no longer good enough quality.
We didn’t try to change everything at once. Instead, we:
Weeks 1+: Started measuring things that mattered to customers (not just bug counts), and created dashboards to make the data visible to everyone.
Week 3+: Instituted “quality rotations” - each sprint, one person was responsible for championing quality discussions in planning and retrospectives. Not as police, but as an official nudge-er to our collective conscience. Rotating so as not to remove the ownership from the rest of the team.
Week 5+: Made small improvements to development practices. Better logging here, additional test coverage there. Nothing dramatic, though noticeably each change brought and reinforced the stronger ethos.
Week 9+: Started sharing customer impact stories (from internal and external consumers). When we fixed usability issues or performance problems, we shared the positive feedback with the whole team.
Fundamentally, our goal was to shift the conversation from “is it good enough?” to “are we proud of this?” Within a handful of months we had that change - and although at first the answer was quite often “No”, the change in question was key. The code quality improved, customer satisfaction increased, and - crucially - people started enjoying their work more.
The Bottom Line
Quality culture isn’t about following rules or meeting metrics. It’s about creating an environment where people naturally care about doing good work and feel empowered to make it happen.
This means making quality part of how you work, not something you do in addition to work. It means celebrating quality wins, learning from quality failures, and creating psychological safety for people to raise concerns.
Most importantly, it means recognising that quality culture is a long-term investment. You won’t transform a team’s approach to quality overnight, but with consistent effort and the right conditions, you can build something that sustains and improves itself.
The teams with the best quality aren’t the ones with the most elaborate processes - they’re the ones where caring about quality feels natural and rewarding.
Originally published on Edmund Pringle’s Substack. Follow Ed for more on software quality and engineering leadership.