Anyone who has sat in a motorway jam that appeared from nowhere knows the strange feeling of it. No crash, no roadworks, no obvious cause. The road was simply carrying as many cars as it possibly could, and then a single brake light was enough to bring it all to a standstill.
The road was at its most efficient just before it stopped moving at all.
You see this in organisations too - you have targets on sales, product development, customer support and you fine tune your headcount to match those targets and it flows - until someone leaves, is laid off, is away on long term sick, is directed to address a cyber incident, a supplier has a minor delay - and a domino effect of lost sales, product delays and customer dissatisfaction occur.
I keep seeing the same pattern everywhere I look: in people, in organisations, in contracts and now in AI. We are very good at measuring the cost of spare capacity and very bad at measuring the cost of having none.
The maths of a very busy system
Queueing theory has been describing this for over a century. Waiting times don't rise in a straight line as a system fills up. They climb steeply as utilisation approaches 100%, so a system running flat out has no room to absorb a late delivery, a sick day or an unexpected request. Every small shock turns into a queue.
That's why practical guidance for knowledge work usually lands well below full load, often quoted at around 70 to 85% depending on how unpredictable the work is. Those are rules of thumb rather than laws, but the direction of travel isn't in dispute. Slack in the system isn't idle time; it's what keeps the system moving when reality turns up.
People are not machines
Tom DeMarco made this argument for people more than twenty years ago in his book Slack. He defined slack as the degree of freedom required to effect change, and called it the natural enemy of efficiency. His point was that when you fill every hour with assigned tasks, you remove the one thing that lets an organisation reinvent itself.
Think about what that means in practice. If someone's week is fully booked
Who stops to ask whether the task itself still makes sense?
Who has time to notice that a report nobody reads takes six hours, or that a manual step could simply be removed?
If you introduce a new process / tool / AI agents, when do employees have time to innovate, experiment, learn, make mistakes and feedback into the continuous improvement both they and the organisation would like?
Improvement is work too, and it needs hours to happen in.
There's a trap here as well. Carving out "20% time" doesn't help if the remaining 80% is simply relabelled as the new 100%. You've moved the same load around. The aim is to escape the utilisation trap, not redecorate it.
Giving people time to think and try something different
A system built for instant response quietly favours one way of working: reacting fast, switching tasks without friction, and thinking out loud in the meeting. Plenty of people work differently - different personality traits, life events changing priorities, etc. Some need longer to process a change before they can respond to it. Some do their best work deep in one problem and pay a real cost every time they are pulled out of it. Some need to take in the detail before they can say anything useful.
This matters especially for neurodivergent colleagues, who are often the first to be squeezed by a calendar with no gaps, and who often lose the most when the working day is run as a relay of interruptions. Time to think is frequently treated as an adjustment for some people and organisation policies and "Employee Resource Groups" get created that start to "other" these into exceptions.
I'd argue it's a more inclusive (and arguably) better way of running the work for everyone, because nobody improves a process in the five minutes between two meetings.
The capacity to change
There's a second cost of running at full load that rarely appears on a dashboard: a team with no slack can't change how it works. Every new tool, process or way of working takes time to learn, time to get wrong, and time to do the old and the new side by side. If every hour is already allocated, the change either doesn't happen or happens badly, on top of the day job.
This is exactly what I see with AI adoption. Organisations want the productivity gain from the new tools, but the people who would have to learn them have no spare time to experiment, fail and refine. So the pilot is run as one more task squeezed into a full week, and the verdict on the technology is really a verdict on the lack of capacity.
The organisations that adapt fastest to anything, whether that's a new technology, a regulation or a competitor, aren't the ones that squeezed every hour. They're the ones that kept enough room to change.
The same mistake in supply chains, contracts and models
Supply chains. The pandemic gave us a very public lesson. Lean, just-in-time supply chains were brilliant at cutting inventory cost right up until supply and demand both moved at once. UPS's CEO described how companies that had spent years optimising working capital were suddenly talking about "just in case" inventory instead. I'm sure all the businesses owning "smart fridges" in the last few weeks - aimed to be ultra-efficient at stock and inventory management for just in time availability - are now considering if the cyber issues they've seen may require a different resilience approach (2 different fridge manufacturers, changing default admin passwords, backup stock and fridges located offsite etc. It's worth being fair here, because the lesson isn't that lean is bad. Wharton's Gad Allon put it well: nothing is inherently wrong with being lean, but firms may have taken it a step too far. Researchers have also argued that just-in-time can still work in turbulent times if it's applied to the right parts of the chain (see my prior Systems Thinking article). The question is never "lean or not". It's "where do we need a buffer, and what is it buying us?"
Contracts. This is where I see it most in my own work. When a Microsoft agreement comes up for renewal, there is enormous pressure to right-size to the exact last seat, the last subscription, the smallest Azure VM size, last unit of committed spend. Shelfware is waste, and removing it is absolutely the right thing to do. But an estate trimmed and fixed to exactly today's headcount and today's plans has no room for a hiring push, an acquisition, a pilot of something new, or a business that grows faster than the forecast. The same if circumstances change and headcount reduction or spend controls mean a reduction from what was agreed in contract. Then the cost of flexing shows up, which if not considered may be at a worse price and at a worse time. Good commercial structuring deliberately accommodates for flexibility (headroom and reductions), and knows what it's paying for.
AI Models & agents. AI has its own version, and it's the one that worries me most as more organisations build agents and automated pipelines. In machine learning, overfitting is what happens when a model is tuned so tightly to its training data that it falls apart on anything new. It's an instance of a wider idea I'm seeing increasingly referenced - Goodhart's law - usually summed up as: when a measure becomes a target, it ceases to be a good measure. A simulated boat-racing agent learned to drive in circles collecting bonuses rather than finishing the race. A robot rewarded for moving quickly learned to make itself tall and fall over. Language models trained on human approval can drift towards telling people what they want to hear and as quickly as possible. In each case the system did exactly what it was optimised to do, but may not have accommodated for times when you didn't want a quick or the same answer.
The same thing happens in how we design AI and agent workflows. Strip out every validation step as "wasteful". Remove the human checkpoint because it slows the pipeline. Tune the prompts against a test set until they ace it, then watch them fail on the first unusual customer email. It all looks efficient on the dashboard, and it is all fragility underneath.
When something goes wrong
The clearest test of whether an organisation has any slack is the day something serious breaks. Take a cyber attack. The response needs people who can drop what they're doing, make decisions, communicate with staff and customers, and work through the recovery, often for days, and often out of hours. In an organisation where every person and every hour is already allocated, there is nobody to drop anything. Incident response gets bolted onto full-time jobs, the normal work either stops or quietly fails, and the people holding it together run out of energy long before the recovery does.
It also shows up in the decisions. A team that has never had time to rehearse the plan, question its assumptions or keep its documentation current will be improvising under pressure. Then, that first "exception" becomes the normal way to deal with everything as Urgent and Important. A plan that exists only on paper is just another shelf item. The organisations that recover well tend to be the ones that invested in spare capacity and practice before they needed it, and that investment looks like waste right up until the day it doesn't.
Corporate Capitalism: We are saving PDFs, not lives
Much of the pressure to squeeze comes from a feeling of constant urgency. Everything is a priority, everything is due yesterday, and every spare hour looks like a failure to deliver. We then get into cycles of blame, performance management, layoffs, delayed rehiring - add to the capacity challenges all because there wasn't any in the first place, and "do more with less" breaks the system and all the people within it,
Most of us are producing reports, decks, contracts and emails. We are saving PDFs, not lives. If a deliverable arrives a day later because someone took time to get it right, the world carries on.
The irony is that even where lives really are at stake, the maths still holds. Queueing theory is routinely applied to emergency departments, which need deliberate spare capacity precisely because demand is unpredictable. If an A&E can't afford to run at 100%, an office making slide decks certainly doesn't need to run that way. We often behave as if our work were an emergency service when it's closer to a workshop, and a workshop needs room to think.
So what do we do instead?
None of this is an argument for waste. Slack with a purpose is a design choice. Slack without one is just waste with a better excuse. A few questions I'd ask of any team, contract or system when framing my engagements with them:
Is our target utilisation below 100% on purpose? If you can't say what the buffer is for, you probably don't have one, or you have the wrong one.
Are we measuring queues and cycle times, or only hours booked? Busy is not the same as productive.
Is there protected time to think, improve and learn, and is it safe from being reallocated? The first thing to go in a squeeze is usually the only thing that would have reduced the squeeze.
Does the way we work leave room for people who need more time to process, switch or go deep? Doing this well tends to improve the work for everyone.
If something serious breaks tomorrow, such as a cyber attack, who would actually have the capacity to respond? If the honest answer is nobody, that's a risk, not a saving.
In contracts and capacity, have we bought headroom deliberately? Know what flexibility costs before the moment you need it.
In AI, are we testing on things the system hasn't seen, and keeping a human in the loop where the stakes justify it? A model that has only ever been scored on the test hasn't really been tested.
Back to the motorway
The lesson of the phantom traffic jam is that a system can look perfectly healthy right up to the moment it isn't. Efficiency numbers tell you how well things run on a normal day. They are silent on what happens on the day something goes wrong, or the day something needs to change.
The organisations, teams and models that cope best with that day are rarely the ones that squeezed hardest. They're the ones that left a little room to think, to adapt and to move.
Sources
Operational Slack: Why It Looks Like Capacity (But Isn't), Cleverence
Capacity Utilization (expanded version), on the "80 is the new 100" trap
Rethinking Your Just-in-Time Supply Chain, Wharton Executive Education
Just-in-Time for Supply Chains in Turbulent Times, Production and Operations Management (2023)
The PESQetarian: On the Relevance of Goodhart's Law for Speech Enhancement, arXiv
On Goodhart's law, with an application to value alignment, arXiv