Ashby’s Law of Requisite Variety
Only variety can absorb variety. A control system can only manage the variety in its environment if it has at least as much internal variety available to respond. This single principle explains why compliance systems fail, why expert humans become bottlenecks, why standard products get pulled toward complexity, and why centralised management cannot cope with the diversity of what it is trying to manage. The solution in every case is the same: either reduce the variety that enters the system, or build internal mechanisms with enough variety to absorb it.
☰ Contents
The Law stated precisely
— W. Ross Ashby, An Introduction to Cybernetics, 1956
William Ross Ashby was a British psychiatrist and cybernetician who formalised the mathematical theory of control systems. His Law of Requisite Variety, published in 1956, states that for a controller to regulate a system, the controller must have at least as many distinct states available as the system it is trying to regulate has disturbances that could affect it.
In plain language: a control system can only handle the variety it has been designed to handle. Any variety that exceeds the controller’s capacity passes through unmanaged, causing the failures, errors, and surprises that the control system was supposed to prevent.
Filter out external complexity before it enters the system — or build internal capability to handle it safely when it does. Those are the only two options. Everything else is the same complexity being absorbed by the same expert human, one case at a time, forever.
A thermostat has two states: heat on, heat off. It can manage exactly one type of disturbance: temperature variation. It cannot manage humidity, air quality, occupancy, or sunlight. Those disturbances pass through unmanaged because the thermostat’s variety (2 states) does not match the environment’s variety (many dimensions). To manage more variety, the control system needs more states — a more sophisticated controller with more internal variety.
What variety means in practice
In an organisational context, variety is the number of different situations, states, or conditions that a system must be able to respond to. High variety means many different situations requiring different responses. Low variety means few situations with predictable, standardised responses.
Every organisation faces variety from its environment: different customer requests, different failure modes, different regulatory requirements, different market conditions, different clinical presentations. That variety is real. It cannot be wished away. The question is always: where is this variety absorbed, and at what cost?
Variety absorbed by expert humans
- Every non-standard situation routes to the same expert
- The expert is the variety absorber for the whole system
- The expert becomes the bottleneck
- The system cannot scale without adding more of the same expert
- When the expert is unavailable, the system fails
Variety absorbed by system design
- Common situations handled by scripts, menus, and automated checks
- Experts handle only genuinely novel situations
- The system scales without proportional expert headcount
- When individuals are unavailable, the system continues
- Experts are freed for the work only they can do
The two responses
There are exactly two ways to address a variety mismatch: reduce the variety that enters the system, or increase the internal variety available to absorb it. In practice both are needed.
Response 1 — Exclude variety at the boundary. Reduce the variety the system must handle by limiting what enters. A portfolio policy that defines which product configurations are offered excludes the variety of bespoke requests before they enter the delivery system. A structured requirements template that captures customer needs in a standard format reduces the variety of interpretations a developer must resolve. A validated report catalogue that defines which reports can be built reduces the variety of SQL configurations a developer must write from scratch. These are boundary decisions — they reduce the problem before it reaches the system.
Response 2 — Build internal mechanisms with sufficient variety. For the variety that does enter, build the internal mechanisms that can absorb it without routing it through expert humans. Automated checks, validation gates, continuous monitoring systems, and structured menus are all variety absorbers. Each one handles a class of variety that previously required an expert decision. The Goalie role is a variety absorber for inbound operational demand. The automated patient list reconciliation check is a variety absorber for the variety of possible patient list errors. Bootstrap CUSUM is a variety absorber for the variety of possible outcome deteriorations — it detects structural change regardless of its specific form.
Why compliance systems fail — Ashby applied
A compliance audit has a fixed, limited internal variety: it checks for a defined set of expected states (compliant / non-compliant) against a defined list of criteria. The audit can only detect the specific failure modes it was designed to look for. Any failure mode not on the list passes through undetected.
The real world has near-infinite variety: novel combinations of circumstances, edge cases, new failure modes that did not exist when the audit criteria were written, systemic problems that emerge from interactions between individually compliant components. The compliance system’s internal variety (a finite checklist) does not match the environment’s variety (indefinitely large). The result is exactly what Ashby predicts: the variety that exceeds the controller’s capacity passes through unmanaged.
This is why serious failures so consistently occur in organisations that have recently passed their compliance audits. The audit was not wrong — it checked what it was designed to check, and the organisation complied. The failure emerged from variety the audit was not designed to see. See The Compliance Trap for the full analysis and the prevention alternative.
Why expert humans become bottlenecks
When a system lacks the internal variety to handle the situations it faces, the unmanaged variety flows to wherever the most variety is available — which is almost always the most expert human in the organisation. The expert can handle a wide range of situations precisely because they have high internal variety: deep knowledge, broad experience, pattern recognition across many domains.
This produces the Expert Trap: the expert becomes the variety absorber for everything the system cannot handle. Support queries, implementation problems, compliance reviews, sales decisions, product questions — all route to the same expert because that is the only place with enough variety to handle them. The expert is fully utilised. New work cannot proceed. The system cannot scale.
The correct response is not to find a more productive expert or ask the existing expert to work harder. It is to build internal system variety that matches the variety of the situations the expert is currently handling — so that the expert handles only the genuinely novel situations that truly require their unique capability.
The role structure described in Focus & Prioritisation is an Ashby response. The Goalie role absorbs the variety of inbound operational demand, so that variety does not flow to the Builder (the constrained expert). The Investigator builds the internal variety of the Goalie role over time by converting recurring escalations into scripts, templates, and documented processes. The Toolmaker builds system variety — automated checks, validation tools, report builders — that absorbs variety without requiring any human to handle it. Each role adds internal variety to a specific part of the system.
Standardisation as a variety reduction strategy
The standardisation vs customisation decision is, at its root, an Ashby decision. Every customisation request adds variety to the installed base that the system must absorb in perpetuity — in support, in upgrades, in regression testing, in documentation. Accepting customisation without a defined process for absorbing its ongoing variety adds to the system’s variety burden indefinitely.
A standardised product — the Blueprint — reduces the variety entering the system at the boundary (Response 1) by defining a fixed configuration space. The variety within that space (different parameter settings, different patient populations, different clinic sizes) is absorbed by the system design (Response 2) — through validated SQL fragments, automated checks, and structured parameter menus rather than bespoke development decisions.
Von Hippel’s lead user insight, reframed through Ashby: the lead users who are getting exceptional results with simple configurations have found ways to reduce the variety they introduce into the system. Their simpler, more reliable approach is the Blueprint hypothesis — not because simplicity is inherently better, but because it matches the system’s internal variety with the variety it actually needs to handle.
Bootstrap CUSUM as a high-variety monitor
A Shewhart X-mR control chart has limited internal variety: it applies a fixed set of rules (points beyond control limits, runs rules) to detect a specific class of signal (large sudden shifts). It cannot detect small persistent shifts, slow drifts, or structural change that accumulates over many observations. Its internal variety does not match the variety of ways a process can genuinely change.
Bootstrap CUSUM has higher internal variety: it accumulates evidence across all observations, detects changes of any size that persist long enough to accumulate statistically significant evidence, and tests candidate change points across the full series rather than applying fixed rules to individual points. Its internal variety better matches the variety of real process change.
Applied to outcome monitoring: a compliance audit checks a snapshot. Its internal variety is limited to what the auditor looks for on the inspection day. Bootstrap CUSUM on an outcome measure monitors continuously and detects structural change of any form — whether or not it was anticipated, whether or not it matches any predefined failure mode. It is a higher-variety controller applied to the same regulatory problem. See Three Charts, Three Stories for the direct comparison.
Where Ashby fits in the 7-step method
Step 1 (List symptoms): When the symptom list includes the same expert being the bottleneck for multiple different types of work, Ashby is the diagnosis. The variety of situations the system faces exceeds the internal variety available to handle them, and all the excess flows to the expert.
Step 3 (Root cause): The root cause in most expert-bottleneck situations is a variety mismatch — the system lacks internal variety to match the variety of its environment. Identifying which types of variety are consuming the constraint is the root cause analysis.
Step 4 (Dominant constraint): The constraint is the variety mismatch. The Theory of Constraints Step 3 (Subordinate) means routing as much variety as possible away from the constraint — through Goalies, scripts, automated checks — so the constraint handles only the variety it uniquely can.
Step 5 (Complete solution): The complete solution addresses variety at both boundaries: Response 1 (portfolio policy, standardisation) reduces what enters. Response 2 (automated checks, monitoring systems, validated tools) absorbs what gets through without routing it to the constraint.
Step 7 (PDSA): Bootstrap CUSUM on outcome measures is the high-variety monitoring system that confirms whether the variety management interventions are working. A downward change point in support volume confirms that a new variety absorber (a script, an automated check) is handling a class of variety that previously reached the expert.
Ashby’s Law sits in the Systems & Constraints group alongside Theory of Constraints, Failure Demand, and Focus & Prioritisation. Together they explain why systems get stuck and what the structural responses are. See The Compliance Trap for the most direct application.