Controlling flow under uncertainty

Above a certain load, output does not level off; it falls off a cliff.

On a highway, a network or a busy engineering team, extra load past the peak makes everything slower, so less work leaves the system per hour. A test lab that accepts every request ends up with engineers chasing, re-queueing and re-running stale builds, and fewer tests finish per week than when it was less loaded.

In systems that can congest, regulate occupancy so you stay at the load that gives the highest throughput.

Throughput is speed × density, and speed drops as density rises, so throughput peaks at an intermediate occupancy. Ramp meters do this for freeways; a WIP limit on a review queue does it for a team: hold excess work outside, where it does no harm.

Make congestion visible by publishing a forecast of how long new work will take to get through.

Drivers re-route when the sign says '35 min to downtown'; nobody re-routes on a raw queue count. Show requesters the expected flow time ('a new lab request today finishes in about 9 days') so they can choose to wait, reprioritize or go elsewhere.

Charge more for capacity at congested times so that demand that can move, does.

A modest price for peak capacity shifts flexible demand into the shoulders, where capacity sits idle. Internally this can be a priority surcharge on an expedite, or a budget charge for using the shared prototype shop during crunch weeks.

Use a regular cadence to stop variance from piling up.

Without resynchronization, schedule slips add up like a random walk and grow with the square root of time. Re-aligning plan and reality every period, as in a fixed-length sprint or release train, keeps deviations bounded to what happens within one cycle.

A cadence only holds if there is enough spare capacity to absorb each cycle's variation.

A bus can depart on time only if the schedule has slack for slow traffic. A two-week sprint loaded to 100% cannot absorb surprises, so lateness rolls into the next sprint and the cadence becomes fiction; plan sprints with a margin.

Use cadence to make waiting times predictable.

If the architecture review happens every Tuesday, nobody waits more than a week, and everyone knows it. An on-demand review has no ceiling on wait: it depends on whether the reviewers' calendars line up.

A regular cadence lowers transaction cost, which makes small batches economical.

Pre-scheduled events cost almost nothing to convene, so you can hold them often and handle a few items each time. Weekly releases on a fixed train are cheaper per release than ad-hoc releases that must be negotiated, so batches shrink.

Hold frequent meetings on a predictable schedule instead of convening them on demand.

A short daily or twice-weekly slot where the right people are already present removes the scheduling overhead and the multi-day lead time of finding a common free hour. Questions wait at most one interval.

Synchronization only works if each participant has enough capacity margin to show up on time.

If the handoff is at 10:00 and upstream sometimes finishes at 10:15, those items miss the pickup and wait a full cycle. Leave enough margin (or offset the pickup) to cover upstream variation.

Synchronize work from several projects to share fixed costs and gain scale.

One combined design review, one shared prototype build or one test-lab slot that serves several projects at once spreads the fixed setup cost. Projects that align their milestones to a common cadence get these economies without large batches.

Use synchronized events that bring every function together to make cross-functional trade-offs quickly.

A trade-off between firmware, hardware and manufacturing is resolved in minutes when all three are in the same room at the same time, and in weeks when it is negotiated by sequential handoffs and email.

Align the batch size and timing of adjacent processes to shrink the queue between them.

If upstream finishes a batch just before downstream pulls one, work barely waits. Mismatched cycles or phases leave finished work idle in an inventory between the two stages, even when both have plenty of capacity.

Make nested cadences whole-number multiples of each other.

Daily stand-ups inside two-week sprints inside quarterly releases line up every time. A 3-day cycle feeding a 4-day cycle drifts in and out of phase, so waits are irregular and synchronization is lost.

When every job has the same cost of delay, do the shortest job first.

Finishing short jobs first means fewer jobs sit waiting behind long ones, so the total delay paid is smallest. Quick bug fixes before a long refactor, if they are equally urgent.

When every job takes the same time, do the job with the highest cost of delay first.

With equal durations, the only lever is which delay cost you pay the longest; make the cheap-to-delay jobs wait. Among equally sized features, ship the one that unlocks the biggest customer first.

When durations and costs of delay both vary, use weighted shortest job first: rank by cost of delay divided by duration.

Cost of delay divided by duration (CD3) is the delay cost avoided per unit of scarce capacity. Sorting by it minimizes total delay cost on a single resource; SJF and HDCF are its special cases.

Priorities are local: they belong to a queue at a moment, not to a project for all time.

A 'priority 1 project' does not need to go first in every queue it touches; at a given resource, what matters is the CD3 of the waiting jobs right there. Global rankings applied everywhere make the wrong call at many queues.

When you cannot know how long tasks will take, share capacity in short time slices.

Round-robin keeps one unexpectedly huge job from blocking all the short ones behind it: each job gets a quantum in turn, so short jobs finish early. Pick a quantum long enough that switching costs stay small.

Interrupt work in progress only when the cost of switching is low.

Preempting makes sense when a new job's cost of delay is far higher and the switch is cheap. Every interruption costs setup and context, and frequent preemption can cost more than the delay it saves.

Use sequencing to match each job to the resource best suited for it.

When a specialist frees up, pick the waiting job that benefits most from that specialist instead of the next in line. This only works if the decision is made when the resource frees up, not when the job arrives.

Choose and adjust the sequence of process steps to suit each job.

A one-line config change should not travel the same 14-step path as a new subsystem. Let low-risk work skip steps that add no value for it and send high-risk work through extra checks.

Route each job through whatever path is currently the most economical.

The best path changes as queues come and go. Like a router or a GPS, decide the route at run time from current congestion, not from a fixed plan made months ago.

Build and maintain alternate routes around points of congestion.

A second qualified test vendor, a backup reviewer, or a simulation that can stand in for a hardware test: alternates absorb surges. They must be exercised regularly or they will not work when needed.

Use flexible, cross-trained resources to absorb variation.

Even a little cross-training, such as each engineer able to cover one neighbor's area, captures most of the benefit of full flexibility because it links all the queues into one chain.

The later you commit a job to a specific resource, the smoother the flow.

Assigning work to a person at arrival locks it into that person's queue even if someone else frees up first. Keep a shared queue and bind work only when a resource is actually free.

Make tasks and resources reliably visible to adjacent processes.

Flexible routing and late binding need to see where the queues are and who is free. A visible board of the next process's queue lets upstream route work to an idle path instead of a blind guess.

If you need fast responses, plan and pay for flexibility before you need it.

Cross-training, pre-qualified alternate suppliers and modular architectures take time to build. Flexibility bought in advance is cheap insurance; flexibility improvised in a crisis is slow and expensive.

Centralized resources, managed correctly, reduce queues.

Pooling demand from many sources onto a shared pool of servers smooths variation, so a central pool needs less capacity for the same wait time than dedicated per-team resources. It fails only if central allocation becomes slow or bureaucratic.

Reduce the variability of the flow before it reaches a bottleneck.

Queue size at a bottleneck grows with the variability of arrivals into it. Smooth the arrivals upstream, where capacity is cheap, so the expensive bottleneck runs at high utilization without a large queue.