In my previous article, I talked about how latency kills learning. How the months between deciding to build something and actually learning if it works creates a strategic vulnerability.
But I didn’t answer the harder question: Why does this latency exist in the first place?
The answer lies in how we fundamentally misunderstand product development work. We treat it like manufacturing. We optimize for resource efficiency. We keep people busy.
And in doing so, we’ve built systems that are perfectly designed to maximize delay.
The Efficiency Trap
Walk into most organizations and you’ll hear variations of the same concern:
“We can’t have developers sitting idle.”
“We need to maximize utilization.”
“Everyone should be working on something.”
It sounds reasonable. After all, you’re paying these people. They should be productive, right?
This thinking is killing your flow.
Here’s what actually happens when you optimize for resource utilization:
- Developers are assigned to multiple projects simultaneously
- Each person’s queue of work grows longer
- Context switching becomes constant
- Work sits waiting for the “next available person”
- Everything takes longer than it should
You’ve achieved 95% utilization. Congratulations. You’ve also achieved 500% cycle time.
Don Reinertsen’s Revelation: Watch Idle Work, Not Idle People
(once more: Watch idle work, Not idle people)
Donald Reinertsen, in The Principles of Product Development Flow, turned conventional wisdom on its head with one insight:
In product development, the cost of queues (work waiting) far exceeds the cost of idle resources (people waiting).
Think about that.
When a developer sits idle for an hour, you’ve lost one hour of labor cost.
When a feature sits in a queue for a week waiting for that developer, you’ve lost:
- A week of potential customer feedback
- A week of learning opportunity
- A week of possible revenue (Cost of Delay)
- A week your competitor might be shipping
- The compounding cost of every other feature blocked behind it
Which is more expensive?
The Math of Queues
Reinertsen showed us something software organizations still struggle to accept: queue time dominates cycle time in product development.
A typical feature might have:
- 40 hours of actual work time
- 400 hours of queue time (waiting in backlogs, waiting for reviews, waiting for deployment, waiting for dependencies)
You’ve spent 40 hours working and 400 hours waiting. Your efficiency is 9%.
But here’s the kicker: reducing the work time from 40 to 30 hours (a 25% improvement!) only reduces total cycle time from 440 to 430 hours — a 2% improvement.
Reducing queue time from 400 to 200 hours? That’s a 45% improvement in cycle time.
The leverage isn’t in working faster. It’s in waiting less.
The Cost of Delay: Making Invisible Work Visible
Why does queue time matter so much? Because every hour work sits idle, you’re paying the Cost of Delay.
Reinertsen taught us to quantify this. Every feature has an economic value over time. When that feature is delayed:
- Value that could have been delivered isn’t
- Learning that could have happened doesn’t
- Revenue that could have been earned isn’t
- Strategic options that could have been created aren’t available
A feature that would generate $100K/month in value costs you $100K for every month it sits in your backlog unshipped.
Suddenly, that backlog of 200 items isn’t an asset. It’s a liability.
Each item represents:
- Committed capital (analysis, design, planning already invested)
- Opportunity cost (other things you could be learning instead)
- Delay cost (value not being delivered)
- Decay cost (requirements aging, assumptions becoming stale)
Most organizations treat their backlog like a warehouse of valuable inventory. Reinertsen helps us see it for what it really is: a warehouse of delayed decisions and deferred learning.
Russell Ackoff: You’re Solving the Wrong Problem
Now let’s add another layer. Russell Ackoff, the systems thinking pioneer, warned us:
“The righter we do the wrong thing, the wronger we become.”
And: “Managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other.”
Read that again slowly.
Your “resource efficiency problem” isn’t really a resource efficiency problem. It’s part of a larger system that includes:
- How you fund work (annual budgets create batch size problems)
- How you measure success (utilization metrics drive local optimization)
- How you organize teams (functional silos create handoff delays)
- How you approve decisions (centralized control creates bottlenecks)
- How you define done (quality gates create queue buildup)
You can optimize each piece individually and make the whole system worse.
The Real Problem Behind the Problem
Most organizations ask: “How do we deliver more features faster with the same resources?”
Ackoff would tell us this is the wrong question. It assumes:
- More features = more value (wrong)
- Faster delivery = better outcomes (not necessarily)
- Resource constraints are the binding constraint (usually not)
The better question: “How do we maximize learning and value delivery with the least delay?”
This reframes everything:
- Maybe you need fewer features, not more
- Maybe you need smaller batches, not faster execution
- Maybe you need less work in progress, not more resources
- Maybe you need to validate assumptions earlier, not build more completely
Ackoff taught us that dissolving problems is better than solving them. Instead of asking “how do we manage this massive backlog efficiently?”, ask: “Why do we have a massive backlog in the first place?”
Flow Efficiency vs. Resource Efficiency
Here’s where Reinertsen and Ackoff converge beautifully.
Resource Efficiency asks: “How busy are our people?”
Flow Efficiency asks: “How quickly does work move through the system?”
Traditional management optimizes for resource efficiency:
- Keep everyone at 95%+ utilization
- Maximize output per person
- Minimize “idle time”
Result: Massive queues. Long cycle times. Delayed learning. High Cost of Delay.
Flow-based management optimizes for flow efficiency:
- Limit work in progress
- Reduce batch sizes
- Eliminate delays between stages
- Allow spare capacity for pulling work through quickly
Result: Some idle time. Short cycle times. Fast learning. Low Cost of Delay.
The Counterintuitive Truth
Systems with spare capacity move work faster than systems at full capacity.
Think about traffic. A highway at 70% capacity flows smoothly. At 95% capacity, it’s stop-and-go. At 100%, it’s a parking lot.
Your product development system is no different.
When you run at 95% utilization, you’ve created a system where:
- Everything is queued
- Nothing moves quickly
- Every dependency creates delay
- Every interruption cascades
- Learning happens in slow motion
When you run at 80% utilization with deliberate spare capacity, you’ve created a system where:
- High-value work can jump the queue
- Dependencies resolve quickly
- Problems get swarmed and solved
- Learning happens rapidly
- Strategic options remain open
You’re trading 15% labor efficiency for 300% flow efficiency.
That’s not a cost. That’s a bargain.
Practical Implications: Redesigning for Flow
So what does this actually mean for how you work?
1. Limit Work in Progress (WIP)
The single most powerful lever for improving flow: do less simultaneously.
Instead of 10 features in progress, do 3. Yes, this means some people might wait. That’s the point.
Idle people with fast-moving work beats busy people with slow-moving work.
2. Reduce Batch Size
Don’t plan quarters. Plan weeks.
Don’t build whole features. Build testable slices.
Don’t wait for perfect requirements. Start with sufficient clarity and learn.
Smaller batches mean:
- Faster feedback
- Lower risk
- More flexibility
- Reduced queue time
3. Visualize Queues, Not Just Active Work
Your kanban board probably shows “In Progress” and “Done.”
Add columns for:
- “Ready to Start” (queue time before work begins)
- “Waiting for Review” (queue time in code review)
- “Waiting for Deploy” (queue time before production)
- “Waiting for Validation” (queue time before learning)
Make the waiting visible. Measure it. Then reduce it.
4. Measure Cycle Time and Flow Efficiency
Stop measuring velocity (how much work we complete).
Start measuring cycle time (how long work takes from start to finish).
Calculate flow efficiency: (Active Work Time) / (Total Cycle Time)
If your flow efficiency is below 15%, you have a queue problem, not a productivity problem.
5. Make Cost of Delay Explicit
For every item in your backlog, ask:
- What’s the economic value of shipping this sooner?
- What’s the learning value of validating this sooner?
- What’s the cost of this sitting in the queue another month?
Rank work by Cost of Delay Divided by Duration (CD3). Do the things where delay hurts most and duration is short first.
6. Create Capacity for Fast Work
Reserve 20% of your capacity for:
- Urgent strategic work that needs to skip the queue
- Rapid experiments and learning
- Helping unblock others
- Reducing technical debt that slows flow
This isn’t slack. This is strategic capacity for responsiveness.
The System View: Everything is Connected
Here’s where Ackoff’s systems thinking becomes critical.
You can’t just “implement WIP limits” and expect transformation. The system will resist.
Your funding model might require predicting a year of features (forcing large batches).
Your governance might require tollgate approvals (creating bottlenecks).
Your architecture might be tightly coupled (creating dependencies and queues).
Your incentives might reward individual output (discouraging helping others).
Your culture might punish “not being busy” (preventing spare capacity).
You’re not fixing a process. You’re redesigning a system.
This means asking Ackoff’s questions:
- What is the real problem? (Not “we’re slow” but “we optimize for the wrong things”)
- What are the interconnections? (How do funding, governance, architecture, and culture interact?)
- What are we really trying to achieve? (Fast learning and value delivery, not busy people)
- What would need to change systemically? (Not just process, but measurement, incentives, structure)
The Competitive Advantage of Flow
Organizations that understand flow have a structural advantage.
They learn faster because work moves through their system faster.
They adapt faster because they have capacity to respond to change.
They deliver value faster because they minimize time in queues.
They make better decisions because they’re operating on recent data, not stale assumptions.
Meanwhile, their competitors are:
- Keeping everyone busy
- Managing massive backlogs
- Celebrating high utilization
- Wondering why everything takes so long
They’re doing the wrong thing righter. And becoming wronger.
Your System Today
Look at your product development system right now.
How many items are in progress simultaneously?
How long does the average feature sit in queues vs. active work?
What’s your flow efficiency?
What’s the Cost of Delay for work sitting in your backlog?
Are you optimizing for busy people or moving work?
More importantly: Are you asking the right questions?
Not “How do we go faster?” but “Why are we going so slow?”
Not “How do we do more?” but “Why are we doing so much?”
Not “How do we stay busy?” but “Why is our work waiting?”
The answers are in your queues. The leverage is in your flow. The opportunity is in your system design.
Watch idle work, not idle people.
Because the work that’s waiting is costing you more than you think.
What’s the biggest queue in your product development system? How long is work really waiting? Share your observations below.
About the Author: Ralph Jocham is Europe’s first Professional Scrum Trainers and co-author of “Professional Product Owner.” He helps organizations build self-evolving systems where strategic clarity and operational excellence reinforce one another. Connect at effectiveagile.com or find more insights at scrumexpansion.org.