Quality is a systems problem, not a testing problem.

Every org I've joined had the same instinct when bugs leaked to production. Add more testers. Add more test cases. Add another gate. None of it ever moved the needle for me, because quality is a property of the system that produces the software. It is not a layer you bolt on at the end.

When the architecture is tangled, when ownership is unclear, when CI takes 40 minutes and people start skipping it, no amount of manual QA will save you. The defects are already upstream of the test suite by the time anyone runs it.

My fix is usually unglamorous. Shorten the feedback loops. Isolate the blast radius. Make the cost of breaking something visible to the person who broke it. That is where I have consistently seen escaped defect rates drop by an order of magnitude.

A concrete example of this systems lens applied to test infrastructure: predicting flaky tests with a Random Forest classifier turned a distrusted CI pipeline back into a reliable signal in weeks. Same principle, sharper tool.

And the leaders who actually fix these systems tend to share one trait, which is the unpopular opinion that might save your career: they stay technical. You cannot redesign a system you no longer understand.

I wrote up the full framework, including the metrics I track and the rituals I install, on my main site.