Workload Saturation · Primary
Everything is in progress. Nothing is finishing.
How this principle feeds it
rising work in progress and stretching lead time are the library's 'everything is in progress, nothing is finishing'.
Principles Library / Intake Within Capacity
Intake Within Capacity
Work Intake Within System Capacity Sustains Flow
Diagnose
AI signs are on by default. Use the AI switch to exclude them.
1. Which of these early warning signs are you seeing?
- Many items are active, but few get finished.
- People hold several active items each and switch between them most days.
- Queues grow between teams, stages, reviews and approvals.
- Known bottlenecks keep getting more work anyway.
- Forecasts lean on averages and ignore the variability underneath.
- Work takes weeks or months to become usable, so problems surface late.
- Significant work sits in personal queues or outside any visible system.
- New work starts as soon as it is approved, whatever is already in progress.
- Agent output outgrows human review, and review becomes the unmeasured bottleneck. (AI)
- Leaders see agent outputs but not the queues or what agents are doing. (AI)
- Automated stages post strong throughput, but end-to-end lead time doesn't move. (AI)
- Batch size follows what agents can generate, beyond what people can validate. (AI)
2. Over the last few months, have you noticed…
For each consequence: Not seen / Sometimes / Persistently / Not sure.
- Lead times stretch and grow less predictable as work waits longer in queues.
- Intake keeps feeding busy stages while the real bottleneck goes unmanaged.
- Intake plans undercount real load and overstate available capacity.
- Rework costs climb because large batches force many changes to be undone together.
- Context switching eats capacity that could have gone into finishing work.
- Parallel agent output overwhelms human review and validation before anyone notices. (AI)
3. The condition it becomes
Based on your answers, recognize at most two conditions: No / Partly / Yes, that is us.
Workload Saturation: Everything is in progress. Nothing is finishing.
Local Optimization Bias: Every team hits its targets. The product still misses.
Batch Amplification: Problems are found at release, not before it.
Oversight Erosion: The review process still runs. It stopped meaning anything.
Take your Diagnosis to the next level by invoking AI Diagnostic Coaching tool.
What else have you observed? Optional. Shared only if you choose to start coaching.
Start a Diagnosis session: review and edit a draft containing your note, conditions you recognized in Step 3 (including whether they match partly), warning signs and consequence ratings before sending it. No scores or principle files are sent.
Overview
Principle intent
Keep the amount and rate of work entering active delivery within the system's effective capacity to absorb, review, and complete it, and make that work visible enough to manage.
When it holds: what it does for you
More work gets finished
Teams start less at once and finish more of what they start.
Bottleneck in plain sight
Leaders can see where work waits and steer intake around the real constraint.
AI paced to review
Agent output arrives at a size and pace that human review can absorb.
When it is ignored: from early signs to a lasting condition
Early warning signs · Visible now, cheap to fix
- Many items are active, but few get finished.
- Queues grow between teams, stages, reviews and approvals.
- Known bottlenecks keep getting more work anyway.
What happens over time · Accumulates, costly to reverse
- Lead times stretch and grow less predictable as work waits longer in queues.
- Rework costs climb because large batches force many changes to be undone together.
- Context switching eats capacity that could have gone into finishing work.
The condition it becomes
Local Optimization Bias · Secondary
Every team hits its targets. The product still misses.
How this principle feeds it
intake that keeps feeding busy stages rewards local throughput while the system constraint stays put.
Batch Amplification · Primary
Problems are found at release, not before it.
How this principle feeds it
large increments that delay feedback and raise rework are the library's definition.
Oversight Erosion · Secondary
The review process still runs. It stopped meaning anything.
How this principle feeds it
reviewers facing more output than they can check start approving without checking, while the review step still looks intact.
Act
Act
Showing all 6 practices. Answer the Diagnose questions and the most relevant come first.
Show all work, human and agent
Show all work end to end, including queues, blockers, dependencies and hidden work. Put agent-driven work on the same view as human work so the full load is clear.
Start by asking your team: What decisions are we making without enough visibility to trust them?
Avoid · You’ll know it’s working when
Avoid
- Visualizing work only for reporting or compliance instead of using it to guide decisions and manage flow
You’ll know it’s working when
Leaders can see all work, human and agent, and status comes from the board instead of meetings.
Limit work in progress at the system boundary
Limit work in progress at the system boundary as well as inside teams. Finish work before starting new items.
Start by asking your team: How much work is actually active right now, and where is it piling up faster than it's finished?
Avoid · You’ll know it’s working when
Avoid
- Setting arbitrary work-in-progress limits without watching how the system actually behaves
- Limiting work in progress only at team level while intake at the system boundary stays uncontrolled
You’ll know it’s working when
Fewer items are active, more get finished, and people hold fewer priorities at once.
Shrink batches and shorten feedback loops
Cut work into smaller batches that can be integrated, reviewed or validated on their own. Shorten the gap between finishing and feedback so problems surface while they're cheap to fix.
Start by asking your team: Would smaller batches let downstream stages absorb work more effectively, or would they just add coordination overhead?
Avoid · You’ll know it’s working when
Avoid
- Creating smaller tasks or tickets without actually reducing batch size, feedback delay or downstream overload
You’ll know it’s working when
Work reaches a usable state sooner, and problems show up while they're still cheap to fix.
Manage intake around the bottleneck
Find the current bottleneck. Adjust intake, policies, sequencing or capacity around it instead of tuning stages one by one.
Start by asking your team: Which stage currently sets effective system capacity, and are we still pushing work into it anyway?
Avoid · You’ll know it’s working when
Avoid
- Maximizing utilization everywhere and assuming flow will follow
- Making people manage overload individually instead of fixing its structural cause
You’ll know it’s working when
The bottleneck stops receiving extra work, queues in front of it shrink, and faster stages show up in end-to-end lead time.
Measure flow and its variability
Track lead time, cycle time, queue growth and throughput. Look at variability as well as averages to see how work actually flows.
Start by asking your team: Where does work wait longest, and is that a people problem or a decision and handoff problem?
Avoid · You’ll know it’s working when
Avoid
You’ll know it’s working when
Forecasts account for variability as well as averages, and queue growth gets spotted early.
Cap agent output at review capacity
In AI-enabled delivery, cap generation and parallel agent runs at what human review, validation and integration can actually absorb.
Start by asking your team: As AI increases execution capacity, where must intake or parallelism be limited to protect what the whole system can absorb?
Avoid · You’ll know it’s working when
Avoid
- Letting AI generate or start work simply because execution is cheap
- Treating system capacity as whatever the fastest stage can produce
You’ll know it’s working when
Human review keeps pace with agent output, and batch size matches what people can validate.