The queue is not clearing. Everyone is working hard, nobody is idle, and the obvious answer is more people. You hire two, and six weeks later the queue is the same length.
That is not a mystery and it is not a management failure. Adding people with an unchanged set of responses changes neither of the two numbers that matter.
Why these three models
The decision is whether to spend your next budget on headcount or on redesign. The features that fire are a process failing while effort is high, arrivals meeting a finite server, and a trajectory nobody has named.
Three lenses with different error structures. Requisite variety produces an equilibrium answer about whether the process can regulate at all. Queueing produces a complex answer about what happens as utilisation approaches capacity. Behaviour modes produce a cycle answer about which shape you are actually on, which decides whether the other two are even the right questions. The first two frequently disagree, and knowing which one is binding is the entire diagnosis.
1. The controllability test: two counts, and you only track one
Start with the count nobody takes.
Write down how many genuinely distinct situations arrive at this process in a week. Not volume: kinds. A refund request, a refund request where the customer is outside policy, a refund request where the payment failed on your side, a refund request from a customer who is also a distributor. Those are four situations, not four tickets.
Now write down how many genuinely distinct responses the process has. Not how many people. How many different things they are empowered and equipped to do.
If the second number is smaller than the first, the process cannot regulate the system, however hard anyone works. This is the law of requisite variety, and Beer adopts it as an axiom of controlling complex systems: requisite variety exists where there is enough permutative variety to give a one-to-one transformation from the controlled system into the control box.1 Stripped of the language, only variety absorbs variety.
There are exactly two repairs and there is no third. Attenuate the variety arriving: standardise the offer, template the intake, restrict what can be requested without escalation, remove the edge cases from the policy rather than from the queue. Amplify your own: add response categories, delegate authority so more cases resolve without routing upward, automate a class of cases so the humans get the remainder.
Hiring does neither. Four people with three canned answers become eight people with three canned answers. The arriving kinds have not fallen and the available responses have not risen, so the queue behaves exactly as before, and the team reasonably concludes it is still understaffed.
Requisite variety, the controllability lens
- Assumes: regulation requires at least as many distinguishable responses as the controlled system has states.
- Fits because: effort is high and the outcome is not improving, which is the signature.
- Breaks when: nothing. It is close to analytic, which is its real limitation.
- Evidence: grade A, and honestly so: it is near-definitional, cannot be false, and will never surprise you.
- Counteracts: treating every capacity problem as a staffing problem.
- May reinforce: false precision, because counting distinct situations is a judgement and not a measurement.
2. The queue: why the last ten per cent costs the most
The second lens is the one that makes hiring look like it worked, briefly.
Where arrivals meet a server with finite throughput, waiting time does not rise in proportion to load. It rises gently while utilisation is moderate and then climbs sharply as utilisation approaches capacity. Variability makes it worse: the same average load with more variable arrivals produces materially longer waits.
Two consequences follow, and they pull in opposite directions from the first model.
The first is that a genuine capacity shortfall does exist and hiring does fix it. If your arriving kinds and your available responses match, and you are simply running at ninety-five per cent utilisation, then people are the answer and this article does not apply to you. The diagnosis matters precisely because both failures present as a long queue.
The second is that attenuating variety often relieves a queue faster than adding capacity, because it removes the variability rather than the load. Templating an intake reduces the spread of handling times, and the spread is doing much of the damage.
There is a practical asymmetry worth knowing. Adding a person raises capacity by a known amount after a ramp of weeks or months. Removing a class of case from the queue lowers load immediately and lowers variance at the same time, which moves the waiting time twice. The cheap intervention is also the fast one, and it is the one nobody proposes in a crisis.
Queueing and congestion, the capacity lens
- Assumes: work arrives at a server with finite throughput, and waiting is a real cost.
- Fits because: the visible symptom is a queue rather than an error.
- Breaks when: arrivals are not independent of the queue, for instance when a long wait causes customers to submit duplicates, which feeds the arrival rate.
- Evidence: grade A. Structural, and the nonlinearity near capacity is not in dispute.
- Counteracts: reading a queue as proportional evidence of a shortfall.
- May reinforce: attacking variability when the real problem is that the process cannot handle a whole class of case at all.
3. Name the shape before you explain it
The third lens comes first in practice and is almost always skipped.
Plot the queue length over time before diagnosing anything. There are a small number of fundamental shapes, and each implies a different structure.2 Steady growth with no flattening is an arrival rate above the service rate, and no amount of variety engineering fixes a genuine arithmetic deficit. Growth that flattens is goal-seeking, and something is already balancing it. Oscillation points at a delay between the signal and the response, usually a staffing or triage decision made on stale information. Growth followed by collapse is overshoot, and the collapse is usually customers leaving rather than the team catching up.
Drawing the pattern you are trying to explain before building anything is the first step of the modelling process, not a presentational nicety, and it is the step most operating reviews skip entirely.2
Naming the shape narrows the search before you pick a model, which is the point. Diagnosing a variety shortfall on a trajectory that is actually simple arithmetic will produce an elegant redesign and an unchanged queue.
Behaviour modes, the shape lens
- Assumes: the trajectory belongs to a small set of shapes, each implying a different feedback structure.
- Fits because: you have time-series data and have not looked at it.
- Breaks when: the series is too short or too noisy to distinguish shapes, which is common at small volumes.
- Evidence: grade B. Descriptive and useful, with no strong predictive claim attached.
- Counteracts: explaining a trajectory before establishing what it is.
- May reinforce: pattern-matching a shape onto noise.
The levers, cheapest first
- Do the two counts. Distinct arriving situations, distinct available responses. One hour, one whiteboard, and it usually settles the argument before any money moves.
- Plot the queue. Ten minutes. If it is growing steadily and never flattening, stop reading about variety and check whether arrivals simply exceed service.
- Attenuate first, because it is cheaper. Remove a class of request from the policy, template the intake, or set a default that covers the common case. Reversible, and it reduces variability as well as volume.
- Amplify by delegation before automation. Raising the authority limit of the people already there adds response categories at no headcount and no build time.
- Automate a class, not a step. Automating part of every case leaves the response count unchanged. Removing a whole class from human handling raises it.
- Then hire, if the counts match and utilisation is genuinely high. That is a real capacity problem and people are the right answer.
What to do this month
Do now, sized at one hour, effect visible immediately. Run the two counts on your worst process and write both numbers down. Reversible, free, and dominant across every scenario about whose fault the queue is. Bring both numbers to the meeting where the hire is being discussed.
Hedge, where the premium is the whole loss, live before the next cycle. Pick the single most common arriving situation and give it a standing response that does not require a decision. If it was not the bottleneck you have spent an afternoon writing a template, and that is the entire downside.
Defer and trigger, size fixed now. Do not redesign the whole function this quarter. Pre-commit the trigger: the next time someone proposes headcount for this process, the two counts get produced first, and if responses are fewer than situations the budget goes to redesign instead. Decide now who runs the counts, because a gate with no owner is not a gate.
Note the arrivals as well as the sizes. A template lands this week. A delegation change lands after people trust it, which is a month. A hire lands after ramp, which is a quarter, and that lag is why hiring feels like it worked and then does not.
What usually happens next
Run the break test before the base rate. Has a rule changed, has an actor entered or left, has a measurement become a target? If the team is now measured on tickets closed, expect the response set to shrink rather than grow, because the fastest close is the canned one. That is Goodhart arriving inside the diagnosis, and it will make a variety shortfall worse while the metric improves.
If nothing broke, the pattern is reliable. Teams add people, the queue holds, the conclusion drawn is that the new people are not good enough, and the next request is for more senior people. Seniority raises the quality of responses within the existing set. It rarely adds categories, because adding categories usually requires permission rather than skill.
Subtract the counterfactual before crediting a hire. Queues fall for seasonal reasons, and a hire that lands in a quiet month will take the credit for the season.
What this ensemble cannot see
All three lenses treat the process as the unit and take the arriving situations as given. None of them asks why the situations arrive.
That is the largest omission here. A support queue full of payment-failure cases is a symptom of a payment system, and every repair discussed above makes the symptom cheaper to absorb while leaving the cause untouched. Variety engineering is genuinely good at absorbing variety, which is exactly what makes it a comfortable place to hide from an upstream defect.
There is also a limit on the central model. Requisite variety cannot be false, which means it can never surprise you and never tells you that you were wrong. It structures the question rather than answering it, and a model that cannot fail should be labelled as such rather than treated as a finding.
And one property none of these models contains: as you standardise to raise the response count, you lose the informal handling that was quietly absorbing the awkward cases. That absorption does not appear in any count, and you will notice it only when it stops and a class of customer starts churning without ever filing a ticket.
The one action that survives the ignorance: before the next hire is approved for this process, take the twenty most recent cases and sort them by what actually resolved them. If more than half resolved by the same three responses, you have a variety shortfall and the hire will not clear the queue. If they resolved twenty different ways, you have a capacity problem and you should hire.
Who has to move
This changes nothing unless the person who approves headcount reads it, and that person is usually looking at a queue length and a tired team, both of which argue for hiring. The cheapest first test costs an hour and no money: produce the two counts before the budget conversation. If responses are fewer than situations, you now have a specific reason the hire will not work, which is far more useful than a general objection to hiring.
Sources and notes
- Stafford Beer, Cybernetics and Management, English Universities Press, 1959. The law of requisite variety, attributed to Ashby, is adopted in the chapter on the Black Box as an axiom in the process of controlling complex systems, with the condition stated as sufficient permutative variety to provide a one-to-one transformation from the controlled system into the control box. The distinction between control as regulation and control as instruction runs through the same chapters. Note: the copy consulted is an image-only scan and was read via optical character recognition, so it is cited qualitatively here and no figure is quoted from it.
- John D. Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World, McGraw-Hill. The fundamental modes of dynamic behaviour used in section 3, namely exponential growth, goal seeking, oscillation, S-shaped growth, S-shaped growth with overshoot, and overshoot and collapse, are developed in chapter 4. The practice of drawing the reference mode, the behaviour over time you are trying to explain, before building any model, is part of the problem articulation step in chapter 3.
A note on the weakest model here. Requisite variety is close to a tautology. That is a real criticism and it is why the transparency card says so rather than burying it. Its value is not that it might be false, it is that almost nobody runs the two counts, and the counts change what you spend money on. A framework that reliably prompts an unasked question is doing useful work even when it cannot be wrong.
Joshua Agonya Pi’Rwot, Founder.