Ashby's Law of Requisite Variety
In 1956, W. Ross Ashby — psychiatrist, cyberneticist, and one of the pioneers of systems theory — published An Introduction to Cybernetics, which included a result he called the Law of Requisite Variety. It is a theorem about control, regulation, and the limits of simplicity.
The law says: a controller must be at least as complex as the system it seeks to control. Simple rules cannot govern complex systems.
The formal statement
Ashby's Law can be stated in information-theoretic terms:
Law of Requisite Variety. Let D be a set of disturbances that can affect a system, R be a set of responses available to a regulator, and E be the set of essential outcomes (the states we want the system to remain in). Then:
|E| ≥ |D| / |R|
Or equivalently, log |R| ≥ log |D| − log |E|.
To keep the system within the set of desired outcomes, the variety (number of distinct states) of the regulator must be at least as great as the variety of the disturbances, divided by the acceptable variety of outcomes.
In plain language: if the environment can throw 1,000 different disturbances at your system and you want only one acceptable outcome, your controller needs at least 1,000 different responses. If you are willing to accept 10 different outcomes, your controller needs at least 100 responses. But if your controller only has 5 possible actions, it can only handle 5 disturbances (assuming one acceptable outcome).
The key insight is captured in the slogan:
Only variety can absorb variety.
Understanding through examples
The thermostat
A thermostat is a simple regulator. It can do two things: turn the heater on or turn it off. That gives it a variety of 2.
What disturbances does it face? Temperature changes caused by weather, open doors, number of occupants, sunlight, appliance heat, etc. The variety of possible temperature states is large — let's say thousands of distinct temperature trajectories.
Does the thermostat violate the Law? No, because we have relaxed the "essential outcome" — we don't demand an exact temperature, just that the temperature stays within a range. The acceptable variety of outcomes is also large (any temperature between 19°C and 22°C, say). The thermostat only needs to handle the disturbances that would push the temperature outside this range, and a binary on/off response is sufficient for that reduced problem.
But if we wanted exact temperature control to 0.01°C across all conditions, a binary thermostat would be hopelessly inadequate. We would need a regulator with much higher variety: variable-speed fans, multi-zone heating, predictive models, feedback from multiple sensors. The variety of the regulator must match the variety of the disturbance relative to the precision of the goal.
The micromanager
Consider a manager overseeing a team of 50 engineers, each working on different tasks with different technical challenges, different stakeholders, and different timelines. The variety of disturbances (problems that could arise) is enormous.
If the manager's "regulation" strategy is a single rule — "everyone follows the same process" — the variety of their response is 1. Ashby's Law predicts failure: a single process cannot handle the diversity of situations a 50-person team encounters.
Effective management requires requisite variety: delegated authority, context-dependent guidelines, empowered team leads who can adapt to local conditions. The management system (the regulator) must be complex enough to handle the complexity of the work (the disturbances).
This is why command-and-control management fails for knowledge work: the variety of the regulator (top-down directives) is too low for the variety of the system (creative, unpredictable work).
The immune system
The human immune system is a spectacular example of requisite variety. The variety of possible pathogens (disturbances) is astronomically large — billions of distinct molecular patterns. The immune system's response must have comparable variety.
It achieves this through:
- V(D)J recombination: a genetic mechanism that generates roughly 10¹¹ distinct antibody configurations from a limited genome.
- Clonal selection: antibodies that match a pathogen are amplified; others are not.
- Adaptive memory: previous encounters are remembered (vaccination works because of this).
The immune system works because its variety (10¹¹ antibody types) is commensurate with the variety of threats. An immune system with only 100 antibody types would be overwhelmed.
Implications for software systems
Ashby's Law has direct consequences for how we design, operate, and manage software systems.
Monitoring and observability
A monitoring system is a regulator: it observes the system and triggers responses (alerts, auto-scaling, circuit breakers). Ashby's Law says the monitoring system must have enough variety (sensors, metrics, alert rules) to match the variety of failure modes.
A system with three metrics and one alert rule cannot regulate a distributed system with hundreds of failure modes. This is why observability — high-cardinality metrics, distributed tracing, structured logging — is not a luxury but a requirement for operating complex systems. You need variety in your observations to match the variety of things that can go wrong.
Error handling
A function with a single error path (catch (Exception e) { log(e); return null; }) has a regulator variety of 1. If the function faces 20 distinct failure modes, this catch-all handler cannot respond appropriately to any of them. Ashby's Law predicts that the system will behave poorly under most failure conditions.
Robust error handling requires matching the variety of errors with the variety of responses: specific catch blocks, retry strategies, fallback behaviour, circuit breakers, and graceful degradation paths.
Automation and runbooks
An automated remediation system (a "runbook") is a regulator. If the runbook has 10 playbooks, it can handle 10 types of incidents. The 11th type will go unhandled, requiring human intervention.
Ashby's Law explains why full automation of operations is asymptotically difficult: the variety of production incidents is open-ended, and the automated response must grow in variety to match. This is why SRE teams combine automation (for known failure modes) with human judgement (for novel ones) — human operators provide the requisite variety that automation lacks.
Security
A firewall with 5 rules has variety 5. An attacker with 1,000 techniques has variety 1,000. Ashby's Law predicts that the firewall alone is insufficient. Defence in depth — combining firewalls, intrusion detection, application-level controls, monitoring, and incident response — is a strategy for increasing the variety of the security regulator to match the variety of threats.
Organisational design
Conway's Law says that systems mirror the communication structures of the organisations that build them. Ashby's Law adds a constraint: the organisation must have enough internal variety to handle the variety of the problems it faces.
A small, homogeneous team building a complex system with diverse user needs will struggle — not because the individuals are incompetent, but because the team's variety (perspectives, skills, experiences) is insufficient for the problem's variety.
Strategies for matching variety
Ashby's Law does not say "make everything complex." It offers two complementary strategies:
1. Increase the variety of the regulator
Add more sensors, more response options, more automation playbooks, more team diversity, more flexible processes. This is the direct approach: if the disturbances are complex, make the controller complex enough to match.
2. Reduce the variety of the disturbances
Simplify the system being regulated. Reduce the number of things that can go wrong. Constrain the environment.
Examples:
- Immutable infrastructure reduces the variety of server states (no configuration drift).
- Type systems reduce the variety of runtime errors (the compiler eliminates whole classes of bugs).
- Service boundaries reduce the variety each team must handle (bounded contexts).
- Feature flags reduce the variety of active code paths in production.
- Standardised environments (containers, Nix) reduce the variety of "it works on my machine" problems.
The most effective systems engineering combines both strategies: reduce the variety of disturbances where possible, and ensure the regulator has enough variety to handle whatever remains.
Ashby's Law and the limits of simplicity
There is a cultural pressure in software engineering toward simplicity — and rightly so, since unnecessary complexity is a major source of bugs and maintenance burden. But Ashby's Law places a lower bound on necessary complexity: a system that is too simple for its environment will fail to regulate it.
The art is distinguishing accidental complexity (which should be eliminated) from essential complexity (which reflects the genuine variety of the problem domain and cannot be removed without losing control).
A system is not "too complex" merely because it has many components. It is too complex if its complexity exceeds the variety of the disturbances it must handle. Conversely, a system is not "simple" merely because it has few components — it may be dangerously under-equipped for its environment.
Ashby's Law is the antidote to naïve simplicity: the reminder that some complexity is not a choice but a requirement.