Why CAPA Systems Rot (And Why Naming Names Doesn’t Fix It)

A Deep Dive: Conflict Avoidance as the Root Cause of FDA Quality System Failures

The Pattern

If you read enough FDA Warning Letters for medical devices, a specific cluster of citations appears again and again:

Failure to maintain an adequate CAPA system (21 CFR 820.198)
Failure to analyze complaint data (21 CFR 820.198(a))
Failure to determine root cause of deviations (21 CFR 820.198(b))
Failure to implement effective corrective actions (21 CFR 820.198(d))

These four citations appear together in a majority of device Warning Letters. They’re not independent failures. They’re a single failure expressed four ways: the organization’s feedback loop is broken.

Complaints arrive. They’re logged. Nobody analyzes them for patterns. No CAPA is opened. Or a CAPA is opened, assigned to someone who closes it with a procedural fix (updated SOP, retraining) that doesn’t address the root cause. The same deviation recurs. The FDA shows up. The same four citations appear.

A Composite Case

To illustrate the method, we built a composite case from three real companies that received Warning Letters within the past year. We’ve blended their data and removed identifying details. The patterns, citations, and timeline are real. The company name is not.

The company: A mid-size medical device manufacturer (~100-200 employees) producing an implantable or closed-loop therapeutic device. The product requires embedded software, custom hardware, and rigorous regulatory controls. The company has a dedicated quality team, a documented QMS, and a history of FDA submissions.

The Warning Letter citations:

Failure to maintain an adequate CAPA system
Failure to analyze complaint data to determine if a device defect exists
Failure to investigate the cause of non-conforming product
Failure to ensure that corrective actions are effective and do not adversely affect the device

The timeline: The FDA inspected the facility. Observations were issued on Form 483. The company responded within 15 business days (as required). The FDA reviewed the response and determined it was inadequate. A Warning Letter was issued 2-4 months later.

By the time the Warning Letter was public, the company had known about these problems for at least 6 months. The FDA inspector saw them at the end of a multi-day inspection. The company’s own quality team likely saw them earlier still, but the information never translated into effective action.

The question is: why not?

The Surface Diagnosis

The regulatory consultant’s answer: strengthen your CAPA process.

The prescription is typically procedural: better CAPA software, more rigorous root cause analysis training, tighter escalation paths, more frequent management review meetings. The company implements the recommendations. The CAPA system produces more documentation. The next FDA inspection cites the same violations.

The problem is that the prescription is incomplete. It addresses the mechanism without addressing the motive. It addresses the mechanism without addressing the motive.

The Deep Diagnosis

CAPA systems rot because of conflict avoidance, a cognitive bias that was adaptive for most of human evolutionary history but is destructive in modern quality systems.

Here’s the chain:

Step 1: A complaint arrives. A customer reports a device malfunction. The quality team logs it. So far, everything is procedural. No conflict yet.

Step 2: Pattern analysis requires judgment. If this complaint is part of a pattern, it suggests a systemic defect. Identifying a pattern requires looking across time, across products, across departments. It requires connecting dots that different teams own. This is where conflict avoidance enters: analyzing the pattern will likely point to a design flaw or a process failure that someone in the organization is responsible for.

Step 3: Root cause analysis requires attribution. Determining root cause means naming a cause. Naming a cause means pointing to a person, a team, or a decision. In an organization where conflict is avoided, root cause analysis defaults to the safest answer: “operator error” or “inadequate training.” These answers are procedurally sufficient (the CAPA form is filled out) and socially safe (no one is blamed). They are also almost always wrong.

Step 4: Corrective action addresses the symptom, not the cause. If the root cause is “operator error,” the corrective action is retraining. The operator is retrained. The same deviation recurs because the real cause (a design flaw, a process gap, a resource constraint) was never addressed. The CAPA is closed. The problem persists.

Step 5: The cycle repeats. More complaints arrive. More CAPAs are opened and closed with procedural fixes. The pattern accumulates. The FDA inspector arrives and sees the pattern that the organization’s conflict avoidance prevented from being addressed internally.

The CAPA system breaks down because the procedures require people to do something their brains evolved to avoid: name a problem that implicates someone in their tribe.

Why Naming Names Doesn’t Help

This article uses a composite case rather than naming a specific company. This is a deliberate choice, not a legal precaution.

Logically, naming a company and analyzing its failures treats the symptom as if it were the cause. Company X got a Warning Letter for CAPA failures. So what? Every company that gets a Warning Letter for CAPA failures is suffering from the same underlying dynamic: conflict avoidance breaking the feedback loop. Knowing that Company X has this problem doesn’t help Company Y understand its own. The useful unit of analysis is the pattern, not the company.

Tactically, public shaming triggers the exact cognitive bias we’re trying to address. When a company is publicly called out for quality failures, its natural response is defensiveness, not introspection. The leadership team doubles down on protecting the organization’s reputation. The quality team is further marginalized. The CAPA system rots faster. The company that might have been receptive to help becomes hostile to it.

We’ve seen this dynamic play out repeatedly. Companies that receive Warning Letters fall into two categories: those that use the experience as a catalyst for genuine improvement, and those that treat it as a reputational crisis to be managed. The difference is whether the leadership team can see past conflict avoidance to the real constraint.

Our job is to help companies see that constraint. Public shaming makes that harder, not easier.

The TOC Diagnosis

Theory of Constraints frames this differently. Instead of asking “what procedures are broken?” it asks “what is the system constraint that makes conflict avoidance the rational choice?”

In most medical device companies, the constraint is regulatory throughput, the rate at which the organization can safely move from design change to FDA-approved release. Everything in the organization is optimized to maximize this throughput.

Conflict avoidance emerges as a rational response to this constraint. Here’s why:

Raising a systemic problem slows throughput. If a quality engineer identifies a pattern of complaints that suggests a design flaw, addressing it requires a design change, which requires re-validation, which takes months. The program is already behind schedule. Raising the problem makes the delay visible. Avoiding the conflict keeps the schedule looking clean.
The person closest to the constraint has the most to lose. The program manager or VP Engineering who owns the schedule is also the person whose authority would be challenged by a quality finding. In a hierarchy, challenging authority is costly. Conflict avoidance is the rational choice for anyone who wants to keep their job.
Local optimization reinforces the dynamic. The quality team optimizes for closed CAPAs (their metric). The engineering team optimizes for on-time delivery (their metric). Neither team optimizes for the system constraint (regulatory throughput), because neither team has visibility into it. Conflict avoidance is the equilibrium that emerges when local optimizations conflict.

The TOC prescription is counterintuitive: don’t fix the CAPA process. Fix the constraint.

When the constraint is regulatory throughput, every decision in the organization should be evaluated against one question: does this increase or decrease our rate of safe, approved releases?

If raising a systemic problem will ultimately increase regulatory throughput (by preventing a larger failure later), it should be raised, and the organization should be structured to reward the person who raises it.
If the CAPA process is designed to produce documentation rather than insight, it’s optimizing for the wrong metric.
If the quality team is siloed from engineering, the dependency chain is broken and the constraint can’t be seen.

The CAPA system doesn’t need better procedures. It needs a different objective function.

What This Looks Like in Practice

Here’s what the pattern looks like when it’s working:

The TOC diagnosis reveals the constraint: the VP Engineering is measured on on-time delivery. Every quality finding that threatens the schedule gets deprioritized by his office. The quality team learns this, so they stop raising systemic problems and focus on procedural CAPAs that won’t trigger a schedule conflict. The CAPA system produces documentation but no insight.

The fix is a conversation between the CEO, VP Engineering, and VP Quality that realigns the VP Engineering’s metrics to include regulatory risk. Once the VP Engineering is measured on both schedule and regulatory throughput, the dynamic changes. Quality findings start being raised and addressed. The CAPA system starts producing insight. The next FDA inspection is clean, and the team actually learns something.

The procedures didn’t change. The objective function did.

We haven’t yet run this diagnosis with a medical device client. The pattern comes from analyzing the FDA data and mapping it to the cognitive drivers we see repeatedly in manufacturing and software organizations. The medical device space is where the pattern is most visible, because the consequences of getting it wrong are public, documented, and potentially lethal. That’s why we’re starting here.

The Method

If you’re reading this and recognizing your own organization, here’s what to do:

1. Map the complaint-to-CAPA chain. Trace a single complaint from receipt to CAPA closure. At each handoff point, ask: what information is lost here? What judgment is required? What conflict is avoided?

2. Identify the constraint. What metric is the organization actually optimizing for? Is it throughput? Schedule? Cost? Closed CAPAs? The constraint is the metric that everyone is implicitly optimizing for, even when it conflicts with quality.

3. Realign the objective function. The person closest to the constraint needs to be measured on regulatory throughput, not just their local metric. This is a leadership decision, not a quality decision.

4. Introduce a cognitive layer. Use an external facilitator (a consultant, an AI-assisted diagnostic tool, a cross-functional team with no skin in the game) to surface the conflicts that the organization avoids. The constraint can’t be seen by the people who are constrained by it.

5. Test the fix. Run a single CAPA through the new process. Does it produce insight or documentation? If it produces insight, the objective function has shifted. If it produces documentation, you haven’t changed the constraint.

A Note on the Data

The composite case in this article is built from three real FDA Warning Letters issued to medical device companies within the past year. The companies produce implantable or closed-loop therapeutic devices requiring embedded software and custom hardware. The citations, timeline, and patterns are accurate. The company name and identifying details are fictional.

We chose this approach because the useful unit of analysis is the pattern, not the company. If you’re going through a similar situation, the analysis applies to you regardless of whether your name appears in an article. If you’re not, the analysis helps you understand the patterns to watch for before they become Warning Letters.

Either way, the goal is the same: help organizations see their constraints clearly enough to address them.

This article is part of a series on cognitive drivers of medical device quality failures. The introductory article, “The Same Seven Mistakes, Every Company, Every Decade,” provides the broader framework. The full pattern library and underlying data are available for review.