When a computer is running too many tasks simultaneously, it builds up a working queue. To process that queue it needs a small amount of spare capacity (room to move things around, to load and unload jobs efficiently). When that spare capacity disappears, something counterintuitive happens. The system starts using most of its processing power just to manage the queue itself. Simple tasks that should take seconds suddenly take minutes. The computer is visibly busy, apparently working flat out, and producing almost nothing.
Sound familiar?
People thrash too. Not in a metaphorical way, in a genuinely observable, measurable way. When someone is carrying too many simultaneous demands — across projects, teams, inboxes, meetings — the overhead of tracking everything, remembering where they left off, switching context, picks up the slack in their day. They're busy. They feel busy. And the actual work moves at a fraction of the pace it should.
The uncomfortable truth is that most organisations build the conditions for this themselves.
We're bad at honest accounting
The instinct, when thinking about what a person or a team can handle, is to count hours. Eight hours in a day. Five days in a week - and if someone isn't on leave and hasn't got a conflicting commitment, those hours are available. Allocated. Job done.
But available hours and productive hours are not the same thing. They've never been the same thing. And the gap between them isn't a discipline problem, it's a human one.
People need processing time. Time to think through a problem before the meeting where they're expected to have a view. Time to read back through their own notes before picking up where they left off. Time to have the conversation with a colleague that saves three hours of going in the wrong direction. Time that produces no visible output, but without which the visible outputs arrive late, half-formed, or not at all.
This applies to every function in a business - not just delivery teams or developers. A finance manager, a fundraiser, a marketing lead, a trustee: anyone who is managing competing demands across a working week is susceptible to thrashing. The mechanisms are the same. Only the tasks change.
When organisations fail to account for this, they don't just reduce individual performance. They create a systemic drag that is genuinely hard to diagnose, because everyone is visibly working hard. The capacity looks full. The output is the problem. And the cause is structural.
The 70/20/10 rule
I use a simple model when I'm helping organisations think about what their people can realistically carry. It's not precise (no model of people ever is), but it's a useful corrective to the hours-equals-capacity assumption.
70% of someone's time can reasonably be allocated to named tasks. This varies by role - a developer doing focused build work might sustain more, a senior leader managing relationships and reacting to context might sustain less. But 70% is a workable starting point for most knowledge workers.
20% of their time needs to be protected as processing space. This isn't downtime in the pejorative sense. It's the time spent re-reading a brief before a call, thinking through a decision before it needs to be made, having an unscheduled conversation that changes the approach entirely. It's the L2 cache of your team (the reserve that allows everything else to run smoothly).
The remaining 10% is the buffer that makes you look like you planned well. Because something will happen. It always does.
Run the numbers against your current situation. If you've allocated someone across four concurrent priorities at what looks like 25% each, you haven't given them a manageable workload. You've induced thrashing and called it resource management.
What 3M understood in 1948
In the years after the Second World War, 3M made a decision that looked, on the surface, like giving something away for nothing. They told every employee that 15% of their paid working time was theirs to spend on whatever they thought might be useful - side projects, hunches, ideas that didn't fit anywhere in the current roadmap. They called it "bootlegging," which tells you something about how subversive the idea felt at the time.
The Post-it Note came from that 15%. Not from a strategy day, not from a brief, not from a meeting. From the space between the official work.
What 3M had understood - decades before anyone was writing business books about psychological safety or cognitive load - was that people operating without any breathing room don't produce their best work. They produce their most pressured work, which is a different thing entirely. The 15% wasn't generosity. It was engineering.
The deeper point isn't really about innovation programmes or creative time. It's about the underlying recognition that people don't work at 100% capacity. Most are working at something closer to 60% of their theoretical maximum for much of the time - and that isn't a failure. It's a feature. It's the processing space that makes the remaining capacity function properly. An organisation that treats that space as waste to be eliminated isn't running efficiently. It's running towards thrashing.
A note on the sprint
None of this means that people can't or shouldn't work flat out when it matters. There are weeks - sometimes months - when teams push hard to get something over the line, and they do. That's real, and it's important.
The problem is when the sprint becomes the baseline. When full utilisation stops being the exception and becomes the expectation baked into every quarter, every plan, every conversation about what the team can carry.
People can sustain a sprint for four to six weeks. Beyond that, the processing deficit compounds. The things that weren't thought through properly surface as problems. The conversations that didn't happen show up as misaligned decisions. Quality drops in ways that are hard to trace to any single cause, because the cause is structural.
You built a plan that assumed computers. You hired people.
The question worth asking
Before you add the next priority, or sign off the next plan, ask two things.
What percentage of this person's - or this team's - time are you actually allocating? Add up everything. Every project, every team they sit on, every standing commitment. Most organisations don't do this with any rigour, and the honest answer is usually a number no sensible person would sign off on if they saw it written down.
What are you protecting? If the answer is nothing - if every hour is spoken for and there's no room to think, to course-correct, to have the conversation that changes everything - then the output is going to be slower and worse than the plan suggests. And you won't fully understand why.
If the honest accounting reveals that the team is already at capacity and you're about to add something new, something has to give. A priority drops, a scope reduces, a hire is made. The fourth option - everyone just works harder and it'll be fine - is how organisations end up in sustained thrashing.
The strange truth is that we apply this logic automatically to our technology. No responsible engineer runs infrastructure at 100% utilisation. The headroom isn't waste, it's the thing that makes everything else work.
Your people deserve the same consideration. And unlike your servers, they'll occasionally invent something extraordinary if you give them the space to do it.