Customers don’t experience your effort. They experience waiting.
Why reducing waiting time matters more than working harder
In Spider-Man 2, Peter Parker isn’t portrayed as slow, lazy or incapable.
He’s portrayed as overloaded.
He’s trying to live two lives at once. Student, friend, tenant, employee and Spider-Man. Every role matters. Every responsibility feels urgent. Nothing is trivial.
And yet, the outcome is predictable: missed commitments, late arrivals, strained relationships. Not because he doesn’t care, but because everything is active at the same time.
The film never frames this as a character flaw.
It’s a capacity problem.
Most of us recognize that feeling (minus the suit).
What this is about
That tension between effort and outcome is exactly what this article is about.
Full utilization1 means trying to keep people busy close to 100% of the time.
It sounds responsible.
It looks efficient in planning meetings.
It feels like control.
In many kinds of modern work, it quietly produces the opposite: long delays, missed commitments and a constant sense of urgency without real movement.
This isn’t about motivation or work ethic.
It’s about what happens when too much work is open at the same time.
Why this matters
Once work stops flowing smoothly, effort alone is no longer enough.
Organizations don’t succeed or fail on effort alone.
They succeed or fail on flow2.
On things like:
how long it takes for work to reach the market
whether dates and promises mean anything
how fast the organization can respond when reality interrupts the plan
Somewhere between planning meetings and delivery dates, many organizations lose sight of something simple:
Customers don’t see your internal effort.
They experience waiting.
Time to market, response time, reliability - these aren’t separate problems.
They’re different expressions of how long work sits unfinished inside the system.
Yet many organizations quietly optimize for something else: making sure everyone is busy.
That’s where the tension begins.
A system can look full and still move slowly.
Sometimes because it’s full.
Where improvement efforts often miss the point
This is where many well-intentioned improvement programs quietly go wrong.
They look at activity, not time.
Most lead time isn’t spent on actual work.
It’s spent waiting.
Waiting for decisions.
Waiting for handoffs.
Waiting for capacity.
Waiting for “the right moment.”
From the customer’s perspective, these waiting and idle times are the product experience.
That’s why improving overall lead time rarely starts with making individual steps more efficient.
It starts with reducing how long work sits untouched in between.
Fewer open items.
Less parallel work.
Faster handoffs.
Not just faster execution.
You can perfect every step and still disappoint customers
if most of the time is lost between them.
A useful way to think about it (not a perfect one)
At this point, it helps to step back and look at the system as a whole.
There’s a simple relationship that shows up almost everywhere work moves through a system:
It’s known as Little’s Law6.
No ideology attached. Just math.
Most real work doesn’t move through neat production lines. Tasks aren’t identical. Conditions change while the work is underway.
So no, this isn’t a literal model of how people work day to day.
But as a thinking lens, it reveals something that’s easy to miss when everyone is busy:
The more unfinished work you allow into the system, the longer it takes for anything to reach the customer.
This is the part that often surprises people.
If throughput stays roughly the same, there are only two ways lead time can change:
you either finish work faster or you carry less unfinished work at the same time.
Most organizations instinctively focus on the first.
Little’s Law explains why the second is often more powerful.
Urgency doesn’t change that.
Pressure doesn’t either.
Little’s Law doesn’t tell you where time is lost.
It tells you why it accumulates.
A concrete example: embedded hardware and firmware
This can still sound abstract, so let’s make it tangible.
Take a fairly typical embedded product: a custom PCB, an enclosure, a few sensors, connectivity and the firmware to hold it all together. Nothing exotic. No moonshot technology.
From an approved idea to market launch, a realistic time to market for this kind of product is around 18 months.
Not because engineers are slow.
But because the work has to move through builds, tests, iterations, suppliers and external constraints.
When you look closely, those 18 months break down unevenly.
Actual working time: roughly 6 months
Designing hardware, writing firmware, bringing up boards, debugging, testing, fixing, integrating.
Waiting and idle time: roughly 12 months
Waiting for parts.
Waiting for build slots.
Waiting between EVT, DVT and PVT.
Waiting for test results, approvals, lab availability, supplier lead times and manufacturing readiness.
That imbalance is not unusual. In complex hardware–software development, a large share of total lead time is spent not working, but waiting.
Now look at what happens when you pull different improvement levers.
Improving efficiency
Assume you do everything right internally.
Better tools.
Cleaner architectures.
More reuse.
Fewer defects.
You manage to reduce actual working time by one full month (from 6 months down to 5).
That’s a real achievement.
But the customer-visible result is modest:
Original time to market: 18 months
After efficiency improvements: 17 months
Internally, it feels faster.
Externally, almost nothing changes.
Reducing waiting time
Now pull a different lever.
You reduce the time work spends sitting idle between steps:
fewer parallel initiatives competing for the same labs and decision-makers
clearer prioritization between hardware and firmware work
faster decisions between builds
earlier supplier and part choices to avoid blocked builds
None of this makes engineers work harder.
It simply reduces how long work waits to be picked up again.
If you cut waiting time by four months (from 12 down to 8) the picture changes dramatically:
Original time to market: 18 months
After reducing waiting: 14 months
Same teams.
Same skills.
Same effort.
But the market sees the difference immediately.
When waiting dominates lead time, efficiency improvements feel good internally,
but only waiting reduction shows up on the launch date.
You’ve probably seen this play out
Once you see this pattern, it’s hard to unsee.
A project that’s “almost done.”
A decision that just needs one more alignment.
A release that slips by another week (again).
Imagine a team that can realistically complete about ten meaningful outcomes per week.
With thirty items in progress, things feel manageable.
Then more work gets started.
Nothing dramatic. Just “one more priority.”
Soon there are sixty items in the system.
Quality doesn’t suddenly collapse.
People don’t stop caring.
But time to market stretches.
Customers wait longer.
Feedback arrives later.
The queue grows and so does frustration.
“But shouldn’t focus increase throughput?”
In theory, yes.
In practice, throughput in knowledge-heavy work is often capped by things that don’t show up on a plan or org chart:
limited attention.
coordination overhead.
context switching.
dependence on other people’s availability.
Once days are broken into fragments, adding more parallel work rarely speeds things up.
It usually slows them down.
That’s the quiet risk of loading the system: you’re betting on capacity that may never appear, while customers keep waiting.
Why it feels fine… until it doesn’t
For a while, high utilization feels productive.
Little’s Law explains why more open work leads to longer lead times.
What it doesn’t explain, on its own, is how suddenly things can fall apart.
That comes from variability7.
Real work is uneven by nature:
some tasks are quick, others messy.
work arrives in waves.
priorities shift mid-stream.
When utilization is moderate, systems absorb that variability.
When utilization is high, there’s nowhere for it to go.
So it shows up as waiting.
“But some industries run at very high utilization”
They do (under very specific conditions).
High utilization works best when work is standardized, predictable and heavily buffered.
Airlines, call centers and capital-intensive operations build those buffers deliberately. Waiting is visible and often priced in.
Most modern organizational work doesn’t have those properties.
Here, waiting doesn’t look like a queue.
It looks like stalled projects, delayed releases and work that is “almost done” for weeks.
Applying the same utilization logic without the same buffers usually backfires.
The misunderstanding that won’t go away
“Idle time is waste.”
It sounds sensible.
It’s also misleading.
Slack8 isn’t about comfort or perks.
It’s what allows a system to stay stable when reality refuses to cooperate.
Remove it and variability turns directly into delay and delay is what customers feel.
What over-utilization looks like up close
You don’t need formulas to recognize it.
everything is urgent
simple tasks wait for “the right moment”
planned work gets displaced by the latest escalation
projects start easily and finish painfully
people are busy, yet outcomes arrive late
These aren’t motivation problems.
They’re system signals.
What actually helps
Once you see the system, the response becomes clearer.
This isn’t about doing less.
It’s about doing fewer things at the same time.
In practice:
limit what counts as active.
finish before starting more.
make queues visible.
protect slack deliberately.
pay attention to time, not just effort.
If everything is urgent, nothing flows and nothing reaches the customer quickly.
Getting started (without overthinking it)
Try this for two weeks.
List what’s actively in motion
Notice what’s actually moving
Pause the rest (explicitly)
Watch one signal: time to market (or time to completion)
If things start reaching customers faster, nothing magical happened.
You changed the shape of the system.
Final thoughts
Full utilization feels responsible.
In many kinds of work, it’s a slow-motion failure mode.
This isn’t an argument for lower ambition or excess capacity.
It’s an argument for respecting how work behaves under load.
Peter Parker didn’t become faster by trying harder.
He became faster by letting go of one life (temporarily) so the other could work.
Customers don’t experience your utilization.
They experience your waiting time9.
If your organization feels busy but slow, don’t ask people to push harder.
Ask something more uncomfortable:
What are we starting that we don’t need to start yet?
This doesn’t explain everything that slows organizations down, but it explains one of the most common and least discussed, ones.
Further Reading
John D. C. Little - A Proof for the Queuing Formula L = λW
Wallace J. Hopp & Mark L. Spearman - Factory Physics
Donald G. Reinertsen - The Principles of Product Development Flow
Eliyahu M. Goldratt - The Goal
Taiichi Ohno - Toyota Production System
Glossary
Utilization: How much of available capacity is kept busy. High utilization looks efficient on paper, but often increases waiting time and delays delivery.
Flow: How smoothly work moves from start to finish without unnecessary stops. Flow is about time and continuity, not about keeping everyone busy.
Lead Time: The total time it takes for something to reach the customer from the moment work starts until it is finished and usable. From the outside, lead time is the experience.
Work in Progress (WIP): All work that has been started but not yet finished. Open projects, half-done tasks, pending decisions, everything that is “in motion.”
Throughput: The rate at which finished outcomes leave the system. Not effort. Not activity. Actual completed results over time.
Little’s Law: A simple relationship connecting three things:
how much work is unfinished (WIP)
how fast work gets finished (throughput)
how long work takes overall (lead time)
As a rule of thumb: more unfinished work means longer waiting, even if people work hard.
Variability: The natural unevenness of real work: some tasks are quick, others messy. Work arrives in bursts. Priorities change. High variability combined with high utilization makes systems fragile.
Slack: Unused capacity on purpose. Slack absorbs surprises, allows adjustment and keeps lead times stable. It is not waste, it is a stabilizer.
Waiting Time / Idle Time: The time work spends doing nothing: waiting for approval, handoffs, capacity or attention. In most organizations, this is where the majority of lead time is lost.
You've hit on something critical here.
In most companies, the decision process goes like this: If the business case is feasible and the budget exists, the project gets greenlit. The more activities running simultaneously, the more efficient the organization appears to be.
But this is a fundamental misconception.
High utilization creates the illusion of productivity while actually destroying flow. When everything is running at once, nothing moves quickly. Resources get fragmented, context-switching kills momentum, and delivery timelines stretch.
The better approach: prioritize ruthlessly based on value creation and speed to market. Finish fewer things faster rather than starting everything at once.
Efficiency should be measured in flow, not utilization. A team running at 100% utilization but delivering slowly is far less efficient than a team with slack capacity that ships value continuously.
It's not about how busy your organization looks—it's about how quickly you can deliver real value to customers.
And let's be clear: this is nothing less than a cultural transformation at the top management level. It requires leaders to let go of the comfort of "full capacity" metrics and embrace the uncertainty of flow. That's not a process change—it's a fundamental shift in how success is defined and measured.
Excellent article! This should be obvious—but it’s not. Thanks for calling this out