Obsessed with Efficiency? Here’s the Tradeoff You’re Missing.

12 min readFeb 2, 2025

Introduction: The Busy Trap

Most companies are obsessed with keeping people busy. They track hours, scrutinise utilisation rates, and celebrate teams always at full capacity.

It makes perfect sense on paper — why would you pay people to sit idle? Every developer coding, every designer designing, every tester testing… (🎶 and a product manager in a pear tree 🎶). Right?

Wrong.

Because the real question isn’t “Are my people busy?” The real question is, “Is my work flowing?”

And if you’re still focusing on resource efficiency — maximising the busyness of individuals — you’re probably looking in the wrong place.

You might be making things worse…

The Problem — Why Resource Efficiency Is a Trap

Let’s play out the logic.

Imagine you’re managing a highway. Your goal? Move as many cars as possible from Point A to Point B as fast as possible.

Now, one approach is to ensure every inch of the road is always occupied — no gaps, no wasted space, just bumper-to-bumper traffic. Perfect efficiency, right?

Except… now nobody is moving.

This is precisely what happens when companies obsess over keeping every individual at 100% utilisation. The system looks full, but nothing flows.

Here’s what that looks like in real life:

Developers are overloaded with work, so tasks pile up while waiting for code reviews.
Testers are stretched thin, so features get stuck waiting for QA.
Project managers start optimising for busyness instead of delivery — because if someone isn’t working on something, that must be bad.

And then, the death march begins.

As cycle times stretch, managers panic. They look around and see people sitting idle, waiting on blocked work, and instead of fixing the bottleneck, they shove more work into the system — because if things are taking too long, surely the answer is to start more things, right? Wrong. Dead wrong.

More WIP → Longer cycle times → More delays → Even more work gets started → The system grinds to a halt.

At this point, the team isn’t working. They’re drowning.

It’s like sitting in a traffic jam and thinking, “You know what would help? More cars.”

The Hidden Cost of Optimising for Busyness

This mindset leads to three dangerous side effects:

Work Takes Forever — High utilisation creates long queues. The more overloaded a system is, the longer it takes to finish anything. (Ever been to an overbooked restaurant?)
Context Switching Kills Productivity — People who are overburdened start juggling tasks. More WIP means more unfinished work, which means more delays.
Quality Drops — Rushing work through an overloaded system leads to half-baked solutions, missed details, and rework. (Hello, tech debt.)

So while managers celebrate packed schedules, they’re missing the bigger picture: a busy team is not the same as a productive team.

The real goal isn’t to keep people working — it’s to keep work flowing.

The Shift in Mindset — From Busyness to Flow

If resource efficiency is about keeping people busy, flow efficiency is about finishing work. It’s a fundamental shift:

Stop measuring how occupied people are.
Start measuring how smoothly work moves from start to finish.

And here’s the kicker: maximising flow often requires allowing some resource inefficiency.

Wait, what? That sounds like heresy in most organisations. But hear me out.

The Power of Idle People (and the Danger of Idle Work)

Not all idleness is bad. A developer with nothing to do for an hour is not a problem. But a feature that sits idle for a week waiting on review? That’s a problem.

Think about it like this:

Would you rather have a doctor fully booked with zero downtime, forcing patients to wait weeks for an appointment?
Or would you rather have some slack in the system so patients can get treated quickly when needed?

This is why hospitals don’t optimise for 100% doctor utilisation — they optimise for patient flow. This is why Amazon doesn’t focus on keeping every warehouse worker busy every second — they optimise getting packages to customers faster.

Yet, in most companies, we do the opposite. We insist on maxing every person out, even if it means work sits around waiting.

This is the mindset shift: Idle work is worse than idle people.

How Flow Efficiency Works in Practice

Instead of focusing on keeping individuals busy, flow efficiency optimises how quickly work moves across the system.

That means:

Reducing work in progress (WIP) — Fewer things in progress = faster delivery.
Prioritising bottlenecks, not people — If work is stuck, fix the blockage instead of throwing more people at it.
Optimising for end-to-end speed, not local utilisation — A feature sitting in a testing queue for two weeks isn’t “efficient,” no matter how busy the testers are.

When companies make this shift, things change fast:

Work moves quicker instead of stalling in queues.
Teams deliver more by working on less at a time.
Customers see value faster — which, let’s be honest, is the only thing that actually matters.

Because in the end, nobody cares how hard your team worked. They care about when they get what they need.

The Proof — What Happens When You Focus on Flow

Alright, so we’ve established that busyness is a trap and that flow efficiency beats resource efficiency. But let’s get real — does this actually work?

Yes. And the data proves it.

What the Numbers Say

Flow efficiency is backed by queueing theory, lean principles, and real-world results. Here’s why:

Little’s Law — The more work in progress (WIP) in a system, the longer it takes to finish anything. High utilisation = high WIP = slow delivery.
The Cost of Delay — The longer work sits idle, the more expensive it gets. Delays create missed opportunities, rework, and frustrated customers.
Total Work Item Age — The sum of the age of all in-progress work is one of the best early warning signals for flow problems. The longer the work sits, the longer the cycle times will be. Total Work Item Age today predicts Cycle Time tomorrow.
Kanban & Lean Results — Teams that limit WIP and actively manage Work Item Age consistently cut cycle times, reduce stress, and improve predictability.

Example:
A product team at one of my client's sites reduced WIP limits, allowing developers to pull in new work only after finishing current tasks. They also tracked Total Work Item Age daily. The result?

Total Work Item Age dropped by >90%
Throughput increased by 25%
Customer complaints about delays plummeted

Impact of WIP Limits on Total Work Item Age — A Leading Indicator of Flow Efficiency

Why? Because work stopped piling up. Instead of pushing more work into the system, they let the system breathe — and suddenly, everything flowed.

The Leading Indicator That Everyone Ignores

Here’s the key insight:

Your future cycle times are already in your system right now.

Want to know what your delivery speed will look like a month from now? Check your Total Work Item Age today:

If it’s rising, your cycle times will go up.
If it’s stable or dropping, you’re improving flow.

Most teams track cycle time as a lagging metric — but by the time it looks bad, it’s already too late.

If you’re only looking at cycle time after work is finished, you’re steering the ship by looking at the wake instead of what’s ahead.

And what’s ahead? The bow wave.

The wake tells you where you’ve been. The bow wave tells you where you’re going.

Cycle time (wake): A reflection of past conditions. When you see the impact, it’s too late to adjust.
Total Work Item Age (bow wave): A real-time signal. If the bow wave gets bigger, you know trouble is coming before it hits.

If your Total Work Item Age is creeping up, your early warning system is flashing red. It means work is ageing in progress, cycle times are about to spike, and delays are baking into your system right now.

Steer by watching the bow wave, not the wake.

Why This Feels So Hard (and Why Leaders Struggle to Let Go)

If flow efficiency is so powerful, why don’t more companies embrace it?

Simple: busyness feels safe.

When people are visibly working, leaders assume things are going well. Empty hands feel like a red flag. And the idea of letting people have slack time? Unthinkable.

But this mindset leads to a dangerous cycle:

Teams get overloaded because leaders equate starting work with making progress.
Work slows down because overloaded systems create bottlenecks.
Managers respond by pushing harder, increasing WIP instead of fixing flow.

This is how organisations get stuck in a death march of busyness while delivery grinds to a halt.

The shift to flow efficiency requires something uncomfortable: trusting the process. It means letting go of “everyone looks busy” as a metric of success and replacing it with “Are we delivering value quickly?”

The Reality Check

The best teams don’t just “look” productive. They deliver.
The most effective systems aren’t crammed full — they flow smoothly.
The goal isn’t to be busy — it’s to finish valuable work faster.

And that starts by stopping the obsession with efficiency.

The Takeaway — How to Make the Shift

So, if resource efficiency keeps you stuck and flow efficiency unlocks faster, more predictable delivery, how do you make the shift? It starts with a fundamental change in what you measure, optimise for, and how you manage work.

Here are five practical, proven steps to start moving from busyness to flow:

1. Measure Flow, Not Busyness

Stop tracking: Utilisation rates, hours worked, “percentage of time spent coding.”

Start tracking:

Work Item Age (How long has each item been in progress?)
Total Work Item Age (Is the age of all unfinished work creeping up?)
Cycle Time (How long does work take from start to finish?)
Throughput (How much gets delivered over time?)

These flow metrics tell you the truth — if your system is getting faster or slower, more predictable or chaotic.

2. Limit Work in Progress (WIP)

If you do just one thing to improve flow, set WIP limits.

Why? Because WIP is the silent killer of flow:

The more things in progress, the longer everything takes.
The longer things take the more unfinished work piles up.
The more unfinished work piles up, the slower delivery gets.

Test this yourself: Cut your WIP limit in half. It’ll feel counterintuitive at first — like you’re doing less work — but within a few weeks, you’ll be delivering more.

But here’s the kicker: You don’t have a pull system unless you have WIP limits.

Many teams think they’re pulling work, but in reality, they’re just picking up the next available thing as soon as they finish something else — which is still a push system in disguise.

A proper pull system only works when there’s a cap on how much WIP exists at any given time. Without limits, teams keep grabbing work, leading to overload, long cycle times, and zero predictability.

3. Optimise for Bottlenecks, Not People

Most teams try to keep everyone busy instead of fixing the biggest constraint in the system.

Bad approach: “Dave has nothing to do! Let’s give him more work.”
Better approach: “Why is everything piling up in QA? Let’s solve that first.”

There’s always one part of the system slowing everything else down — find it, fix it, and flow improves.

4. Embrace Slack Time (Yes, Really)

Slack time isn’t waste. It’s what prevents delays from spiralling out of control.

Highway analogy: If cars drive bumper to bumper, one sudden stop causes a pileup. If there’s space between them, the system absorbs shocks smoothly.
Team reality: Small blockers create massive delays if everyone is at full capacity. But with slack, you can adjust, solve problems, and keep work moving.

If your team has no slack, your system is fragile.

5. Shift from ‘Push’ to ‘Pull’

Push: Work is assigned and shoved into the system, and people are expected to start everything immediately.

Pull: Teams only pull in new work when they have the capacity to finish it.

This one shift prevents overload, keeps WIP low, and forces prioritisation. Think of it like a restaurant kitchen. If orders continue to get pushed in faster than they can be cooked, the kitchen gets slammed, food takes longer, and chaos ensues. But everything flows smoothly if orders are pulled in at the pace they can be completed.

And here’s something unexpected: Dropping WIP limits doesn’t just speed things up — it forces collaboration.

When people aren’t racing to pick up the next ‘thing’ from the backlog, they actually have time to work together, improve quality, and solve problems faster.

But when WIP limits are really low — lower than the number of people on the team — collaboration isn’t just encouraged; it’s mandatory.

At that point, there’s no other option.

You can’t just grab another ticket from “Ready for Development” and keep the factory line moving.
You have to swarm on existing work to get it finished.
Instead of starting more, you start helping more.

And when that happens? Flow efficiency skyrockets.

Now, instead of everyone hoarding their own tasks, the team is pulling together to get work across the line faster.

This is where flow efficiency obliterates resource efficiency every time.

Want a predictable delivery process? Pull work, don’t push it. And if you really want to see flow improve, lower those WIP limits until collaboration becomes inevitable.

Finding the Sweet Spot — It’s Not All Slack or All Utilisation

If you’ve made it this far, you might be thinking, “So… am I supposed to just let people sit around doing nothing?”

Not at all. Flow efficiency isn’t about throwing utilisation out the window — it’s about finding the balance where work moves predictably and smoothly.

Here’s the reality:

Too much slack? You leave value on the table, and work could move faster.
Too much utilisation? You clog the system, cycle times explode, and work slows down.

Neither extreme works. The sweet spot lies somewhere in between.

The “Goldilocks Zone” of Efficiency

Instead of aiming for 100% utilisation, high-performing teams find a balance where:

There’s enough slack to handle unexpected blockers and allow collaboration.
Work flows fast enough that cycle times are predictable, and customers get value quickly.
There’s enough work-in-progress to keep things moving, but not so much that things get stuck.

This is why WIP limits matter — they help you fine-tune the balance rather than swinging from one extreme to another.

A helpful rule of thumb:

You might have too much slack if work is sitting around waiting most of the time.
If work is getting stuck for long periods, your team is overloaded.
You likely haven’t found the sweet spot if you have unpredictable cycle times.

How to Find Your Team’s Flow Sweet Spot

Every team’s ideal balance differs, but you can find it using data, not guesses. Here’s how:

Track Total Work Item Age — If it’s creeping up, your system is slowing down. Adjust WIP limits.
Experiment with Lower WIP Limits — If cycle times improve, you were overloaded. If things start idling for too long, you went too far.
Use Retrospectives to Tune Flow — Every few weeks, ask: Are we finishing work at the right pace?

By tweaking WIP limits, monitoring flow metrics, and adjusting based on the data, you can dial in the right balance for your team.

The Takeaway: Efficiency is a Spectrum, Not a Binary Choice

It’s not ‘all slack’ or ‘all utilisation.’
It’s about tuning flow to keep work moving smoothly and predictably.

The best teams don’t aim for max utilisation or max slack — they optimise for fast, predictable value delivery.

Because at the end of the day, the real goal isn’t to be as busy as possible or to sit around doing nothing — it’s to get the right things done at the right time.

Final Thought: Start Small, Measure, Adjust

Shifting from busyness to flow isn’t about grand restructures or massive process overhauls. It’s about small, deliberate changes that improve delivery over time.

Pick one metric to track this week — maybe Total Work Item Age or WIP limits.
Make a small policy change — maybe stop starting new work until something is finished.
Observe what happens — and adjust based on what you see.

Because at the end of the day, nobody cares how busy your team is. They care about how fast they get what they need.

So stop optimising for busyness. Start optimising for flow.

If you still measure success by utilisation, here’s your challenge: Track the Total Work Item Age for one month. Then come back and tell me what happened.

About Me

I’m Paul, a Partner at Thrivve Partners and a Product & Flow Practitioner, focused on data-informed, evidence-led ways of working. As a ProKanban trainer, I help teams and organisations navigate complexity, optimise flow, and deliver value — without getting trapped in rigid frameworks. I believe in leading with curiosity, not judgment — helping teams uncover better ways of working through exploration, learning, and continuous improvement.

Thrivve Partners