What leaders usually conclude
The common assumption is that quality control simply needs more resource as volume grows — more inspectors, more testing stations — and this is not wrong, but it treats the symptom rather than the mechanism underneath it. Nelson P. Repenning and John D. Sterman of MIT Sloan, in research published in California Management Review using system dynamics modelling and more than a dozen case studies, describe what they term the capability trap: under sustained pressure, managers default to “working harder” — more inspection, more correction after the fact — rather than “working smarter,” which would mean investing in the process changes that prevent defects occurring in the first place. Critically, they observe that the people who successfully prevent a problem receive no visible credit for the problem that never happened, while the people who catch and fix defects after the fact are visibly, measurably busy — which means firefighting is rewarded by visibility even as it consumes the time that prevention would need.
This asymmetry in visibility is worth dwelling on, because it is the actual engine of the trap rather than a side detail. A quality engineer who redesigns a process step to eliminate a recurring defect produces, if successful, an absence — a defect that never appears, a customer complaint that never arrives, a line stoppage that never happens. None of these register anywhere as an achievement, because reporting systems are generally built to count events, not their absence. A quality engineer who instead catches and corrects twenty defects in a week produces twenty visible, countable interventions — and in most organisations, visible countable activity is what gets noticed, discussed and rewarded in performance conversations, regardless of which activity was actually more valuable to the business.
Why prevention loses out as scale increases
This dynamic gets structurally worse, not better, as a manufacturer scales, for a specific reason: growth increases the volume of output moving through the same quality function at the same time as it increases the number of distinct product variants, supplier inputs, and process changes that quality control needs to track. Each of these adds a new potential source of defect, and each new source demands attention now, in the form of inspection and correction, while the underlying process improvements that would reduce future defects require time that firefighting has already consumed. Repenning and Sterman’s own words capture the trap precisely: “An organization that successfully improves its process capability will experience rising performance… creating a virtuous cycle of improved capability and increasing attention to improvement” — the inverse is equally true, and equally self-reinforcing, once an organisation is caught inside it.
A further complication specific to scaling manufacturers is that the quality function’s headcount is usually approved based on current defect volume, which is itself suppressed by the firefighting the function is already doing — a quality team that successfully catches problems before they reach the customer can end up understaffed precisely because its own effectiveness hides the true scale of what it is managing, until something eventually gets through.
This creates a particular risk at the point where a manufacturer moves from one site to several, or introduces a genuinely new product line, because both events multiply the sources of potential defect faster than the existing team’s firefighting capacity can absorb. A quality function that was coping, if only just, with one site’s complexity does not scale linearly to two — the connections between the new site’s processes and the original one’s add coordination demands the team’s existing capacity was never sized to carry, and the gap between coping and not coping can open considerably faster than headcount planning, built on last year’s defect data, is able to anticipate.
There is also a longer-term consequence worth naming directly. A quality function permanently operating in firefighting mode does not simply fail to prevent future defects — it also loses the capacity to build the kind of institutional knowledge about root causes that would make future firefighting faster and less frequent. Each defect caught and corrected under time pressure is an opportunity to understand why it occurred that the pressure itself makes difficult to take. Over several years, this can leave a scaled manufacturer with a quality function that is busier, more experienced in a narrow operational sense, and yet no closer to understanding its own recurring failure patterns than it was at a fraction of the size.
Where this shows up
People working in manufacturers will probably recognise this pattern first. The wider Asset and Production-Based grouping and the other sectors page show how it presents elsewhere.
Questions worth considering
- What share of the quality function’s time currently goes to catching problems after the fact, versus preventing them before they occur — and is anyone tracking that ratio directly?
- Has the number of distinct product variants or supplier inputs grown faster than the quality function’s headcount?
- Would the organisation notice if prevention work were being quietly deprioritised in favour of visible firefighting?
- Was the quality team’s current staffing level set based on defect volume from before or after the most recent site or product line was added?
Your team is facing similar challenges?
Subscribe to The Riddle Ledger
Perspectives are sent as they are published, with no promotional email, and you can unsubscribe at any time.