T
Throughput
Rate of user-facing value that reaches production and is actually used — features that move a metric, cut cost, or make revenue.
Classic: Rate the system generates money through sales.
More adopted outcomes per week.
Topic 01 · The Goal
The slowest stage sets the pace.
Most teams measure local activity — points, pull requests, how busy people look. The system’s output is something else: valuable work in production that users actually adopt. This is a course in the Theory of Constraints, in the language of pipelines.
Eight short sections. The models are yours to push. Progress stays in this browser.
01
Local busyness is not throughput
Every system has one constraint. Improving anything else does not improve the system. In software the constraint is rarely “not enough coding”.
It is usually review, a flaky pipeline, a product decision, or a single person who understands the legacy module. Teams still add developers, dashboards and story points — and the rate of adopted value stays flat.
Code
An hour here, while review waits, becomes inventory.
Review
An hour here is an hour for the whole system.
Deploy
Downstream of the wait. It cannot go faster than review.
Where do you spend the hour?
02
Throughput, inventory, expense
Goldratt threw out local efficiency and kept three global measures. The priority does not change when the work is software.
I
Inventory
Work in process: open branches, unreviewed pull requests, half-done tickets, code sitting in staging, knowledge trapped in one head.
Classic: Money tied up in things intended for sale.
Lower WIP. Shorter lead time.
OE
Operating expense
Salaries, cloud, licences, meeting load, and the support created by poor flow.
Classic: Money spent turning inventory into throughput.
Controlled. Secondary to raising throughput.
03
Dependency and a slow hiker
Delivery is a chain: design, code, review, test, deploy, observe. Each step varies. A bad day stacks. A good day cannot reach back and undo it.
In The Goal, a troop of hikers is limited by Herbie, the slowest walker. Gaps open in front of him. In a software team Herbie is often the senior who must review every critical change, the flaky end-to-end suite, a manual security gate, or the one person who understands the old module.
Code
Ideas are plentiful. This stage’s output is what review inherits.
4/ day
ReviewHerbie
Waiting 25
1/ day
Test
Waiting 1
4/ day
Deploy
Waiting 1
4/ day
Throughput
0.6
finished / day
Inventory
27
items in queues
Lead time
43.2
days of WIP
Work in progress · day 8 · finished today 1
Coding produces four pull requests a day. Review can take one. The line is not balanced, and it should not pretend to be. Work is stacking in front of review. Throughput sits near 1 a day. Faster coding only lengthens the queue.
Lead time here is Little’s Law: inventory divided by throughput. Same finish rate, less WIP, shorter wait. A “balanced” team at full utilisation is fragile. Protective capacity — people who are not constantly maxed — absorbs variation so the constraint keeps moving.
04
Walk until you see the pile
The constraint is where work waits, and where the system’s output is decided. Not where people look the busiest.
Open the board or the pipeline. Which column holds tickets the longest? Whose calendar decides when something actually ships? That stage is Herbie until the evidence says otherwise.
The usual Herbie. Pull requests pile up, and everything after review sits idle.
Throughput is set at the marked stage. Making any other stage faster does not raise it.
Where teams actually get stuck
05
Five steps, in order
Most teams jump to “hire” — elevate — before they have exploited the constraint or subordinated the rest of the system to it. Subordination feels wrong. That feeling is usually local efficiency arguing with the system.
- 01Identify
- 02Exploit
- 03Subordinate
- 04Elevate
- 05RepeatThen back to Identify
1Identify
2Exploit
3Subordinate
4Elevate
5Repeat
Step 1 of 5 · do not skip ahead
The team feels slow. Developers say they are flat out. Twenty-three pull requests sit in review. CI is green in about eight minutes. Where is the constraint?
1Identify
Find the one limit on valuable output
Mistake: Treating every busy person as a constraint
In software: The longest queue is code review
2Exploit
Get more from it without major spend
Mistake: Buying tools or hiring first
In software: Protect focus, automate trivia, order by value
3Subordinate
Make every other decision serve it
Mistake: Keeping velocity and utilisation targets
In software: WIP limits so coding cannot outrun review
4Elevate
Add capacity only if still needed
Mistake: Elevating too early
In software: Train another reviewer, split ownership
5Repeat
Go back to Identify
Mistake: Managing the old constraint forever
In software: Discovery becomes the limiter
06
A drum, a buffer, a rope
This is how subordination works on a board. It looks like a well-run Kanban system because it is one.
- Drum. The constraint sets the cadence. If review can finish eight pull requests a day, the team does not start more than that.
- Buffer. A small queue of ready work sits in front of the constraint so a sick day or a flaky test does not starve it.
- Rope. Intake. New work is pulled only when the drum has capacity. The board does not fill with half-done tickets.
Done
0
WIP
4
Rope credits
0
Beats 0
Backlog
Not started
- Audit log
- Retry policy
- Org invite
- Rate-limit headers
In progress
WIP limit 2
- Empty states
Ready for review
Buffer · limit 3
- Billing export
- Webhook signatures
In review
The drum
- Checkout race
Done
Throughput
- Empty
Review is the drum. Beat it to finish what is in review and pull the next buffered item onto it.
Release the rope and start work. Done will not speed up. Work in progress will. Put the rope back and the same drum produces the same throughput with less inventory — which is a shorter lead time.
07
What the number actually optimises
Measure the rate at which valuable, adopted outcomes reach production. Everything else is a local dial.
What it optimises
Local output of coding
Theory of Constraints
Can increase inventory if reviews lag.
08
Use it this sprint
Same five steps, four places you will actually meet them. Then a checklist, a cheat sheet, and six questions.
Identify review as the constraint. Exploit it: protect reviewer time, automate style and lint, put high-value pull requests first, cover absences. Subordinate with a WIP limit on in-progress work. Only then elevate — another reviewer, or ownership that is not one person.
Sprint checklist
0/5
Cheat sheet
- Goal
- More valuable outcomes in production, sooner, and more predictably.
- Measures
- Raise throughput. Reduce inventory. Control operating expense — in that order.
- Hour rule
- An hour lost at the constraint is lost for the system. An hour saved elsewhere is usually more inventory.
- Five steps
- Identify, exploit, subordinate, elevate, repeat. Order matters.
- Drum-buffer-rope
- The constraint sets the cadence. A small buffer protects it. The rope controls intake. This is Kanban pull.
- Herbie
- The slowest stage limits the pipeline. Variation accumulates; it does not cancel out.
- Local efficiency
- Maximising how busy a person or a stage looks usually hurts system throughput.
Check yourself
Answer from the system, not from habit. A miss points back at the section.
6 questions. No timer.