Your QA Engineers Aren't Slowing You Down. Here's What Is.

Quick Bridge: Fifty-six percent of organizations do not view quality engineering as a strategic function. Yet engineering leaders spend sprint after sprint frustrated by the same QA problems: test counts that do not answer the risk question, compressed timelines that go unchallenged, and communication gaps that nobody names. This post explains why the QA communication problem is structural, what changed when Jesse led his own QA team directly, and what three conversations shift the dynamic without a reorganization.

The complaint I hear about QA is never that the engineers are bad at their jobs. It is that the conversations never get to the right level. You ask for status. You get counts.

You ask what the risk is. Nobody can answer.

That gap is not accidental. It is structural. And most of the industry is living inside it.

According to the Capgemini/Sogeti World Quality Report 2025-26, only 37% of organizations report strong cross-functional collaboration between QA and engineering teams. That means more than six in ten organizations are running release cycles with a fractured relationship between the people building the product and the people responsible for testing it. The leaders in those organizations are not doing anything uniquely wrong. They are caught inside a systemic problem that nobody built intentionally and almost nobody has named.

This post is about naming it.

Why Managers Find QA Communication So Frustrating

The frustration has a recognizable shape. You can find it in three specific behaviors.

The first is that QA communicates in test cases, not risk. Status updates arrive as counts: test cases complete, bugs filed, bugs resolved. What never arrives is an answer to the question that actually drives decisions: if we ship tomorrow, what is the customer risk?

The second is that QA accepts timeline compression without pushing back on what that compression costs. Development runs long. QA inherits whatever time is left. They work through it and sign off, sprint after sprint, without surfacing what they did not test or what that means.

The third is the architecture gap. QA knows the test suite and what failed last time. They do not always know which components are fragile right now, which integrations are new, or which code paths changed in this sprint. Without that context, they test broadly and equally instead of where the actual risk is concentrated.

These behaviors frustrate leaders. They are also symptoms, not causes.

The Technical Visibility Gap Inside Your QA Team

QA teams are almost always measured on defect metrics: bugs found, bugs closed, test cycle completed on time.

When your measurement is defects, you become very good at finding and documenting what can be tracked and closed. You become less practiced at the harder question: of all the things that could go wrong in this release, which ones actually matter to the customer?

That is a risk judgment. It requires knowing the product deeply, understanding the customer's experience, and having enough architectural context to assess where the real exposure is. QA is not measured on risk. It is measured on what can be documented and closed.

There is a structural layer underneath this. QA is almost always last in line. Development runs long, scope does not shrink, and QA inherits whatever time is left. Every sprint.

Pushing back on a compressed timeline requires explaining what the compression costs in terms the business cares about. Without the risk language to make that case, accepting the squeeze is the only available move.

According to the World Quality Report 2025-26 (Capgemini/Sogeti), 56% of organizations do not view quality engineering as a strategic function, and 53% report misalignment between QE processes and agile delivery methods. The report's core finding: progress depends less on technology choices and more on how organizations assign ownership, support learning, and integrate QE into delivery models. The problem is leadership and structure, not the people in QA roles. [World Quality Report 2025-26, Capgemini/Sogeti]

The pattern has a name in the testing community: fear-driven testing. The Ministry of Testing defines it as "an accidental approach to software testing that results from conducting tasks mainly out of fear that defects will escape and reach production." The behaviors it produces are exactly what frustrates engineering leaders: excessive end-to-end testing, redundant documentation, and raising bugs as the primary communication channel instead of having risk conversations. [Is Fear-Driven Testing Holding Your Software Quality Back?, Ministry of Testing]

This is not a QA personality problem. It is a measurement problem and a context problem. Leaders built those measurements. They often do not build the context around them.

Three Engineering Management Conversations That Change This

You do not need to restructure QA to shift the relationship. You need to change three specific conversations.

Tell QA what matters most before the sprint starts. Not the feature list. The specific thing that would hurt customers if it shipped broken. The payment flow nobody has touched in six months.

Give QA the context that makes prioritization possible. Equal coverage is what happens when there is none.

Ask for risk instead of status. Change "how many test cases are left?" to "what concerns you most about this release?" It takes a few sprints for QA to trust that you actually want the honest answer.

When they do, you get judgment instead of metrics. You get information you cannot get from a dashboard.

Surface the tradeoffs when QA gets compressed. When development runs long and QA inherits a shortened window, make the tradeoffs explicit rather than absorbing them quietly. If we run the full suite, we need two more days. If we ship on Thursday, here are the areas we skip and here is what that means.

Let the business decide with full information.

QA cannot advocate for what they need without the language to explain why it matters to you. You can help them build it. Or you can stay frustrated that they are not providing it on their own.

For more on the principle behind this: Context Beats Process Every Time. Giving people context enables judgment. Giving them process requires them to stay in their lane.

What Happens When You Change the Goals

The conversations above will shift how QA communicates sprint-to-sprint. The deeper shift happens when you change what QA is measured on.

When I led a QA team directly in game development, their goals were entirely individual: how many defects they documented, whether the test cycle finished within the window they were given. Those goals measured what QA could control in isolation. They had no connection to what customers actually experienced.

I changed the goals to team-level outcomes: defects reaching customers, and whether the entire game team delivered on time together. This required QA to change how they worked with the rest of the team. They had to get into conversations earlier in the sprint. They had to understand what was being built and why.

The team resisted. That was expected. Any goal change disrupts the comfortable way of working, and resistance is normal.

The change that made the difference was not the goals themselves. It was that the goals required QA to have a different kind of relationship with the engineering team. They had to learn the context that would let them make better risk judgments. And I had to give it to them.

Here is what that looked like in practice.

Before the goal change, the QA report for a sprint arrived as counts: 143 test cases complete, 22 bugs filed, 19 resolved.

After the goal change, the conversation started differently. QA came into sprint planning with questions about what had changed in the authentication flow and what the payment processing team had modified. They left with a prioritized list of what they were most concerned about and why.

The shift was not a restructuring. It was a measurement change that forced a relationship change. If your QA team is giving you counts when you need risk assessments, the measurement system is almost certainly pointing them in the wrong direction.

[Top Software QA Challenges in 2026, QA Source] covers the squeeze problem in detail: why QA teams accept timeline compression without pushback and what that pattern costs the business.

Monday Action

Before your next sprint, tell your QA lead what matters most to the customer in this release. Not the feature list. The one thing that would generate a support escalation if it shipped broken. Then ask QA what they are prioritizing differently because of that.

That conversation is the beginning of the relationship change.

Have you ever changed how your organization thinks about QA? What actually moved the needle?

You're great at the work. Let's make you impossible to ignore.

If you are looking for help improving how your engineering team works with QA and other technical partners, consider reaching out. https://www.jessestaffordcoaching.com