I joined SpotDraft as the first QA hire. There was no process, no automation, and no shared understanding of what "quality" meant across the team. Within two years, I had built a 12-member QA team and, more importantly, a quality-first engineering culture that extended well beyond the QA team itself. This is what I learned.
Culture Cannot Be Mandated — It Must Be Demonstrated
The biggest mistake new QA managers make is trying to enforce quality through process — mandatory checklists, approval gates, test sign-off forms. These things create friction, not culture. Real quality culture happens when the team internalises quality as their own standard, not as an external requirement.
The way to build that internalisation is through demonstration. Show what good quality looks like. Celebrate when a developer writes a thoughtful unit test. Highlight when a bug caught in requirements review saved a week of rework. Make the value of quality tangible and visible.
The Five Pillars of Quality Culture
1. Shared Ownership of Quality
In a quality-first culture, quality is not the QA team's responsibility — it is everyone's responsibility. Developers own the quality of their code. Product managers own the quality of requirements. Designers own the testability of their designs. QA owns the quality strategy, the tooling, and the standards — but not the quality itself.
To make this real, remove language like "it's in QA" from your team's vocabulary. Replace it with "it's ready for verification" — a subtle but significant shift that implies the developer already believes their code is correct.
2. Psychological Safety Around Bugs
Teams that punish bug reporters produce teams that hide bugs. Create an environment where finding a bug — in your own code or someone else's — is celebrated, not feared. A bug found in development is a win. A bug found in production is a learning opportunity. Neither should result in blame.
3. Quality Metrics That Drive Behaviour
What you measure shapes what your team values. Choose quality metrics carefully:
- Good metrics: Defect escape rate (bugs reaching production), test coverage trends, mean time to detect, deployment frequency with quality gates passing.
- Dangerous metrics: Bug count per developer (creates hiding behaviour), test case count (creates low-value test inflation), percentage of tests passing (teams fix tests instead of code).
4. QA as a Knowledge Hub
The best QA engineers I have worked with are also the team's best system thinkers. They understand the product end-to-end better than almost anyone. Position your QA team as knowledge holders — the people who can answer "what happens if X goes wrong" for any part of the system. This elevates QA's value far beyond test execution.
5. Continuous Learning and Tooling Investment
Quality tooling evolves fast — AI-assisted testing, self-healing selectors, visual regression, performance monitoring. Invest in your team's ability to adopt new tools and approaches. A QA team that is always learning is a QA team that is always improving your quality bar.
Practical Steps for the First 90 Days as a QA Manager
- Days 1–30: Observe, listen, and map the current state. What breaks most often? Where are the biggest quality gaps? What does the team already care about?
- Days 31–60: Introduce one lightweight process improvement that solves a visible pain point. Quick wins build credibility and buy-in for bigger changes.
- Days 61–90: Establish the quality metrics dashboard. Make quality visible to the whole team, not just QA. Begin Three Amigos sessions for new features.
// Key Takeaways
- Quality culture is built through demonstration and visibility, not through mandated process.
- Shared ownership means everyone is responsible for quality — QA owns the strategy, not the quality itself.
- Blameless postmortems are the most powerful cultural tool for sustainable quality improvement.
- Measure defect escape rate and deployment quality, not bug counts per developer.
- The first 90 days as a QA manager should focus on observation, one quick win, and metric visibility.