Building a Quality Culture: Lessons from the Trenches
What I've learned about fostering quality-first mindsets across engineering teams, and why it starts with relationships, not tools.
Quality is a team sport
One of the biggest misconceptions I see in engineering teams is that quality is the responsibility of the QA team. It's not. Quality is everyone's job. But telling people that doesn't make it happen. You have to create an environment where quality naturally becomes part of how people work.
At Dunelm, I spent years building this kind of culture. It didn't happen overnight. It started with small conversations, pairing with developers, and showing genuine interest in understanding their challenges. When people trust you, they listen. And when they listen, you can start shifting mindsets.
Relationships come first
Before you introduce a single tool or process, invest in relationships. Get to know your developers. Understand what frustrates them. Find out what "quality" means to them because it's different for everyone.
I've found that the best way to influence change is to be genuinely helpful first. Fix a flaky test that's been annoying someone. Pair on a tricky piece of test automation. Share a useful article. These small actions build trust, and trust is the foundation of culture change.
Make quality visible
People care about what they can see. If quality is invisible, it gets ignored. I started making quality metrics visible in our team spaces, not in a shaming way, but as conversation starters. Test coverage trends. Defect escape rates. Pipeline health. When these numbers are visible, they become part of the team's consciousness.
We also started celebrating quality wins. Someone wrote a test that caught a critical bug before production? Shout about it. A team hit zero escaped defects for a sprint? Recognise it. Positive reinforcement works far better than finger-pointing.
Embed, don't gatekeep
The old model of QA as a gatekeeping function at the end of a pipeline is dead. Quality engineers should be embedded in squads, involved from the start, contributing to design discussions, and helping shape testability before a single line of code is written.
When I moved from a centralised QA approach to an embedded model, the results were immediate. Developers started thinking about edge cases earlier. Test automation became a shared responsibility. And the feedback loop tightened dramatically.
Start small, be patient
Culture change is slow. You won't transform an organisation in a sprint, or even a quarter. But every conversation, every pairing session, every small win compounds over time. The key is consistency. Show up every day with the same message: quality matters, and we're all responsible for it.
If you're trying to build a quality culture in your team, start with one relationship. One conversation. One small improvement. The rest will follow.