Foundation — Book III: QA Directors

TL;DR: Before firing your QA Director, understand if the problem is the person or the system. Most QA leaders fail because they're set up for failure in a reactive quality culture. Transform QA from a cost center into a proactive engineering powerhouse by focusing on prevention, not detection.

The Question

"Ez, should I fire my QA Director?"

Before I answered, I had one question.

I was chatting with a friend who runs a fast-growing SaaS company. He was exasperated. "I gave her budget, new tools, more headcount. We're running more tests than ever, but quality is a mess. Our defect escape rate is climbing, and my engineers are stuck in a 'blaming dance' with her team."

(It's hard to know if the problem is the person or the system. If it's the system, then replacing the QA Director won't solve anything.)

My friend's company is feeling the pressure of AI-fueled development. Their dev team is shipping code faster than ever, but this new velocity has introduced chaos. So I needed to understand if they were on the path to figuring it out. Hence, my question:

"When a bug escapes to production, what's the conversation like? Is it just about fixing that one bug, or is she telling you what she learned about the process that allowed the bug to escape? Is each failure making your system of quality stronger?"

My friend looked down and shook his head.

If your quality process is just about catching bugs after they're written, and you're not learning how to prevent them, you're not doing Quality Assurance. You're just doing expensive, morale-killing Quality Control.

Before You Blame Your QA Director

Look, it's nearly impossible for a QA leader to succeed if the company culture treats them as a simple gatekeeper—a final checkpoint for finding bugs. Generic tactics like "run more regression tests" will only get you so far.

It's tempting to hire somebody to "fix quality," but that rarely works if they aren't set up for success. Most of the time when QA leaders fail, they're in a no-win situation.

Here are a few things you can do to set them up for success, or at least make sure they're not doomed to fail:

1. Is the goal to find more bugs, or prevent them?

The goal isn't just to have a green build; it's to stop wasting engineering cycles on preventable errors. If your QA team is only measured on bugs found, you are incentivizing the wrong behavior.

2. Is Quality a silo, or an engineering practice?

Quality inevitably cuts across functions. Your QA team should be building bridges, not gates. A modern QA function has two faces: one that looks toward the customer (QA Analysts) and one that looks toward the developer (SETIs).

3. Is your team obsessed with the customer's definition of quality?

The DORA report shows that a user-centric focus is a massive lever for product performance. Is your QA team deeply embedded with Product and GTM, understanding what a "quality experience" means to the people who pay your bills?

4. Are you catching issues in minutes or weeks?

The cost of a bug skyrockets the later it's found in the lifecycle. Are you "shifting left" and catching quality issues in the design phase, or are you waiting for production failures to tell you something is wrong?

5. Is your QA team a bottleneck or an accelerator?

A team stuck doing manual regression testing is a brake on velocity. A modern QA team builds the automated infrastructure that allows your developers to ship faster and safer. They are a core part of your Developer Experience (DevEx) strategy.

This all starts with learning. If your current quality strategy isn't working, and you're not learning... then you're just hoping bugs don't happen. And hope is not a strategy.

What's the Best Way Forward?

You could keep hiring, hoping to find a unicorn who can fix a systemic problem. Or, you could start by reframing the role of Quality in your organization.

If this resonates, I've written a more detailed playbook on how to reforge your QA function from a reactive cost center into a proactive powerhouse, splitting the role into customer-focused QA Analysts and dev-focused SETIs.

You can read the full blueprint here: https://substack.com/inbox/post/171250251