Fast feedback and control
Manufacturing control tries to keep a repeatable process on a fixed target. Product development is different: the target moves, the process is noisy, and variation has upside as well as downside. Reinertsen reframes control in economic terms. Choose control variables by their economic leverage, not by how easy they are to count. Make feedback loops short, local, and low in noise. Then use them both to correct deviations and to exploit opportunities.
The common thread is delay. Every day between an action and its verdict adds untested inventory, makes errors more expensive, removes learning cycles, and makes the control loop itself unstable.
Candidate control variables
Click up to 4 variables to put on your dashboard. Circle size = weeks of early warning; blue solid ring = leading indicator, dashed grey = lagging.
Your dashboard
- % of tasks complete vs plan10
- Expense vs budget9
- Hours booked / utilization7
- Lines of code / pages written3
Leverage = influence × efficiency. Launch date and unit cost matter most, but by the time they move it is too late and too expensive to steer them — so control the cheap, leading variables that drive them.
Where do the tripwires go?
Tripwire → pre-agreed relief valve (FF13, FF15)
- Schedule slip > 4.0 wk= $600k lost→ Drop the lowest-value feature from the release
- Unit cost overrun > $20.00= $1.0M lost→ Value-engineering sprint on the top-3 BOM items
- Performance shortfall > 10.0%= $400k lost→ Fall back to the proven design for the subsystem
- Dev expense overrun > $200k= $200k lost→ Release contractor budget; no approval needed
The dollar conversion is itself a second decision rule: a team that knows a week is worth $150k and a dollar of unit cost is worth $50k can trade them off locally, without escalating. The relief valve is decided before the crisis, so crossing a tripwire triggers action, not a meeting.
Output vs. target over time
Try: delay 1 → smooth convergence. Delay 4 → overshoot and ringing. Delay 6 at the same gain → past the stability limit: a sustained oscillation where the loop fights its own stale corrections.
Error vs. feedback delay
Even with the gain re-tuned for every delay (green), error keeps rising: slow loops must be timid, so they react late. A short turning radius beats a long forecast (FF10).
24 bets × 12 weeks — one draw
Green = truly a winner, red = a loser (the team cannot see colors, only noisy weekly results). Blue dashes = review points. Bright segment = second team added, earlier launch.
Expected net value vs. review interval
Model: 20% of bets are winners worth $600k, the rest return $30k; each costs $10k/week for 12 weeks. Raise σ and the advantage of frequent reviews fades: feedback buried in noise cannot tell winners from losers (FF12).
Cost of an error vs. when you find out
Cost = 1 h to fix + up to 4 h to rebuild lost context + 0.45 h/day of work built on top of the mistake that must be reworked. Exact numbers vary; the shape does not.
Learning cycles per year, by loop
Log scale. A test pyramid is a stack of nested loops (FF16): most errors should be caught by the minute-scale loops at the bottom, so only the rare surprise reaches the slow, expensive outer loops.
To see a small signal, reduce the noise
FF12Daily metric (change ships on day 30)
Estimated effect ± 95% interval
Halve the noise and you need a quarter of the samples: required sample size scales with (σ/δ)². Stable test environments, one change at a time, and cleaner metrics buy detection speed directly.
A design question that needs back-and-forth
Distance kills conversation (Allen curve, approx.)
Beyond a few tens of meters, people on the same floor talk about as rarely as people in different cities. At 30 m you talk 8.1× less than with a neighbor 2 m away.
Hurry up and wait (FF21)
- takeawayControl the variables with the most economic leverage (influential, cheap to change, leading), not the easy ones. Set tripwires at equal dollar impact and pre-agree the relief valve.
- takeawayDelay destabilizes control. Short, local, nested loops converge, follow moving targets, and keep excursions small enough to fix before people over-react.
- takeawayFast feedback shrinks queues, cuts the cost of errors, multiplies learning cycles, and lets you kill losers and feed winners. Small batches, low noise, and colocated people are how you get it.
All 24 principles of fast feedback
book chapter 8- FF1The Principle of Maximum Economic Influence
Aim your control effort at the project and process parameters that move the economics the most.
Attention is scarce, so spend it where a change in the variable changes profit the most. Use the economic model to rank candidates: a week of cycle time on a product with $200k/week cost of delay matters far more than a 5% overrun on a $300k expense line.
↑ see it in the visualization - FF2The Principle of Efficient Control
Prefer control variables that are both economically influential and cheap and easy to act on.
Influence alone is not enough: unit cost may matter enormously but be nearly impossible to steer late in a project. Queue size or batch size have high influence and can be changed this week, which makes them excellent control levers.
↑ see it in the visualization - FF3The Principle of Leading Indicators
Pick control variables that predict where the system is going, not ones that report where it has been.
A growing queue in front of the test lab predicts a schedule slip weeks before the milestone is missed; the missed milestone itself is a lagging indicator that arrives too late to act on. Leading indicators buy reaction time.
↑ see it in the visualization - FF4The Principle of Balanced Set Points
Place tripwires on each project parameter at the deviation that causes the same economic damage, not the same percentage.
A uniform '10% variance' rule treats a 10% unit-cost overrun (perhaps $1M of lost margin) the same as a 10% expense overrun (perhaps $200k). Converting every tolerance into dollars makes escalations fire when they are equally worth a manager's attention.
↑ see it in the visualization - FF5The Moving Target Principle
Know when the goal itself is moving, and switch from conforming to a plan to tracking a dynamic target.
Customer needs, competitors and technology shift during development. Treating the original specification as fixed means flawlessly hitting a target that is no longer there; a fast loop can follow the target as it moves.
↑ see it in the visualization - FF6The Exploitation Principle
Use feedback to seize unplanned economic opportunities, not just to suppress deviations from plan.
Variation has an upside: a test may reveal a feature customers love, or that an experiment is a clear winner. Fast feedback lets you shift money toward the winners and away from losers while it still matters.
↑ see it in the visualization - FF7The Queue Reduction Principle of Feedback
Fast feedback lets you run with smaller queues.
Work that is waiting for a verdict is inventory: by Little's Law, untested work equals the rate you create it times the time until feedback. Cut the feedback time from two weeks to two hours and the pile of unverified changes shrinks proportionally.
↑ see it in the visualization - FF8The Fast-Learning Principle
Shorten feedback loops to learn faster and more cheaply.
Learning comes from cycles of hypothesis, test and observation. A loop that closes in an hour gives thousands of learning cycles a year; a loop that closes in a quarter gives four. Faster loops also make each error cheaper, because less work has been built on top of it.
↑ see it in the visualization - FF9The Principle of Useless Measurement
Measuring something does not mean anyone will act on it.
Dashboards full of lagging, uncontrollable or economically trivial metrics consume effort and create no corrective action. Measure what someone can and will change, and connect each metric to a decision.
↑ see it in the visualization - FF10The First Agility Principle
When you can turn quickly, you do not need to see far ahead.
A boat with a short turning radius needs a short lookahead; a supertanker needs miles. Teams with fast feedback and the ability to change course quickly can rely less on long, brittle forecasts and simply correct as they go.
↑ see it in the visualization - FF11The Batch Size Principle of Feedback
Small batches produce fast feedback.
Feedback cannot arrive until a batch is finished and tested. Integrating one change at a time gives a verdict in minutes and points directly at the culprit; integrating a month of changes delays the verdict and buries the cause.
↑ see it in the visualization - FF12The Signal to Noise Principle
To detect a smaller signal, reduce the noise.
The samples needed to see an effect grow with the square of noise-to-signal. Cutting noise (stable test environments, fewer simultaneous changes, smaller batches) lets you detect small effects quickly instead of waiting weeks for statistics to accumulate.
↑ see it in the visualization - FF13The Second Decision Rule Principle
Control the economic logic behind decisions rather than the decisions themselves.
Instead of approving every trade-off centrally, give teams the decision rule (e.g. 'one week of delay is worth $150k') so they can make thousands of correct local decisions quickly and consistently.
↑ see it in the visualization - FF14The Locality Principle of Feedback
Close feedback loops as locally as you can.
A loop that routes through a monthly management review carries a month of delay; the same correction made by the engineer who sees the problem closes in hours. Local loops are faster and more stable.
↑ see it in the visualization - FF15The Relief Valve Principle
Decide in advance on a clear relief valve that is opened when a limit is reached.
When a tripwire fires there should be no meeting to decide what to do: a pre-agreed action (drop the lowest-value feature, add a contractor, slip one milestone) restores the system immediately and prevents slow, political responses.
↑ see it in the visualization - FF16The Principle of Multiple Control Loops
Nest fast control loops inside slower ones.
Fast inner loops (a developer and CI, a daily stand-up) handle small, frequent deviations; slow outer loops (quarterly planning) handle strategy. Each loop deals with the disturbances whose timescale it matches.
↑ see it in the visualization - FF17The Principle of Controlled Excursions
Keep deviations small enough that the control system can still pull them back.
Every control system has a limited range of corrective force. A small slip can be absorbed by overtime or scope trimming; a large one exceeds what any lever can fix and the project lurches. Detect and correct early, while the excursion is still inside the control range.
↑ see it in the visualization - FF18The Feedforward Principle
Warn downstream processes early about heavy incoming load so they can prepare.
Feedback reacts after the fact; feedforward acts on known future disturbances. Telling the test lab that ten prototypes arrive next week lets it add capacity before the queue forms instead of after.
↑ see it in the visualization - FF19The Principle of Colocation
Putting people physically together improves almost every aspect of communication.
Face-to-face conversation is fast, rich and two-way; a question answered in two minutes instead of a day multiplies the number of feedback cycles. Communication frequency drops sharply with distance even within the same building.
↑ see it in the visualization - FF20The Empowerment Principle of Feedback
Fast feedback gives people a sense of control over outcomes.
When the effect of an action is visible quickly, people connect cause and effect and feel ownership; when results arrive months later, they feel like passengers. Fast loops are motivating as well as efficient.
↑ see it in the visualization - FF21The Hurry-Up-and-Wait Principle
Large queues make it hard to create urgency.
If finished work will sit two weeks in a queue before anyone looks at it, finishing a day early is pointless and people know it. Small queues make each day of speed visible and therefore worth caring about.
↑ see it in the visualization - FF22The Amplification Principle
People tend to amplify large deviations rather than damp them.
A large slip triggers panic: added staff, extra meetings, priority thrash. Each reaction disturbs the system further, turning a big excursion into an oscillation. Keeping excursions small avoids triggering the overreaction.
↑ see it in the visualization - FF23The Principle of Overlapping Measurement
To align behavior, reward people partly for the results of others.
If engineers are measured only on their module and testers only on bugs found, each optimizes locally. Overlapping measures (everyone shares the system-level cycle time or the product's profit) make helping a neighbor pay off.
↑ see it in the visualization - FF24The Attention Principle
Where managers spend their time signals priorities more strongly than where they spend money.
Teams watch what leaders ask about. A manager who reviews the queue in front of the bottleneck every morning communicates that flow matters far more convincingly than any budget line or poster.
↑ see it in the visualization