
When I first studied economics I was taught that queuing was a form of non-monetary payment. My teachers pointed to the Soviet Union and described how, in a non-market economy, queues were the price people payed rather than money. In a free market when demand exceeded supply prices rose, that increase was information which pulled in other suppliers until supply matched demand.
Or maybe prices rose to the point were people decided they would spend their money on something else. Or maybe a bit of both. With a queue people paid with their time by standing in line but without the feedback loop of price there was no signal.
Wake up and see the queue
If I had a magic wand and I could magically teach everyone one thing it would be: queuing. Everybody knows how to queue (stand-in-line for American readers) but almost nobody knows the meaning of queues or how they arise.
At the same time I want to open eyes to the implication of queues. If I could motivate our leaders to fix just one thing it would be queuing and the implications of queuing theory.
It is a simple economic model. We could discuss market failure, exceptions, and a lot other “special cases” but the theory is sound. It also does a long way to explain why the USSR no longer exists. Queuing theory is sound too, and it is more than a theory, it is mathematically provable, there are equations.
Spoiler: if you study queuing theory itself it turns out to be more complicated. It is not just about shortages. However, the basic premise stands: time in a queue is a form of pricing, often a hidden cost.
Hidden costs
Now the killer: The cost of queuing doesn’t appear on any balance sheet anywhere.
Cash flow reports don’t measure time spent queuing, value lost from queues, workflows, lack of flow, disruption from queues, human costs of queues (extra stress, lost time, lost work-life balance) or simply any queue in any organization, anywhere.
Queues increase costs directly because it takes longer to get the benefits, e.g. if I queue for an hour to see a doctor then it is one hour longer before I have a diagnosis and can start medication. This is a form of cost of delay.
I was reminded of this by John Burn-Murdoch’s FT column “How London unwittingly killed housebuilding” (probably paywalled). He describes how new safety reviews have created an 8 month delay in building projects which can render house building uneconomic.
Once you know what you are looking for you see it everywhere, but unless you know about queuing theory, or been trained in economics or systems thinking it is invisible. And it gets worse.
Queues also cost because they increase complexity. If I have to queue for an hour to buy a chicken then I have to go to the shop and hour early. That also decreases choice and options because costs increase (time) which makes some options unviable. (And for those still interested, that decreases your agility because it both reduces options and increases lead time.)
That complexity increases dramatically when there are multiple queues (I need to queue for chickens and for chicken feed). When those queues are intertwined complexity increases again (I’m not allowed to buy chickens unless I can show I have chicken feed to give them.)
For humans that complexity increases cognitive load. Because I am thinking about buying my chicken feed and chickens my brain forgets what I am supposed to be at the doctor’s.
Complexity and cognitive load isn’t measured on balance sheets and cashflow statement either but this is where so many organisations, especially large corporate ones, destroy their own capabilities.
Because none of this appears on any financial report, then someone – manager, consultant, CEO, politician – can save money by cutting capacity to service the queue. This is cutting the back office, it looks harmless but it is insidious. The impact might not happen immediately so it looks like a cost-free saving, but over time it degrades system performance.
To continue the building example: suppose we have 20 people reviewing building plans and it takes two months to get a Yes or No. If we remove half the team, 10 people, then we have saved money, 10 salaries. That will appear on financial statements almost immediately. At first output looks the same because there was work in progress.
The work of 10 people will silently disappeared into a queue but the queues will impose costs nobody measures. The organization with the longer queue sees no financial consequence – yippee!
The 10 people left might change their work patterns to compensate: they might do the easy cases first. They might even work harder or longer for a while. Eventually those compensations will wear off. Plan review will take an extra 2 months. Since the easy cases have been done there is a higher ratio of hard to easy cases so things slow down further. And since the system has less capacity any variability will have a greater impact.
But there are external costs: the companies waiting in the queue do see a cost, a cost of delay. One place saves while another pays. This is what economists call an externality, the cost shows up somewhere else.
Rampant corporate queues
This kind of problem is absolutely rampant inside large corporate entities in both the private and public sectors (think immigration processing). Waiting for security review, architecture review, budget approval, business case review, sign-off, meeting, meeting, meeting. The more these queues cross over the higher the cognitive load, it is nye on impossible to know how things should work or how to accelerate work. Often these externalities are actually internal, one department saves while another looses out.
The systems “work” but they work at a high, hidden, cost. I would also argue that this is corrosive to trust between the parties and feeds into the feeling that “nothing works” any more.
As I said, I wish I could open people’s eyes, I wish I could make them see how queues are not cost free but undermine progress, delivery, trust, and rational thinking.
Subscribe to get my thinking in your mailbox (and a free book)
Picture copyright Kirill Razumov
100% agree. Queues are an insidious performance killer, and a lot of my work with teams involves making them visible, and eliminating/reducing them one constraint at a time – both with behaviours and improving technical capability. Testability springs to mind. Good design, automated tests and trunk based development reduce the cycle time (the ‘change request to deployed live’ queue) massively, and *safely*.
But the value of doing this is generally not visible on the CxO spreadsheets directly, so it is missed & ignored in favour of guessworks and short term money saving.