All 175 principles

Choose between actions by their quantified effect on overall economics, not by their effect on a single proxy goal.

Proxies like 'hit the date', 'cut unit cost' or 'stay on budget' conflict with each other, and only money lets you add them up. Build a simple life-cycle profit model and ask how much each option moves it.

You cannot change one variable in isolation; every action shifts several economic variables at once.

Adding a feature raises value but also adds schedule, expense and risk. Express all the side effects in the same unit so the trade-off is visible instead of argued.

If you quantify only one thing, quantify the cost of delay.

Cost of delay drives queue sizes, batch sizes, priorities and how much you should pay to go faster, yet Reinertsen found about 85% of product developers do not know it, and gut estimates for the same project varied 50:1. A rough number beats a confident feeling.

An activity adds value only to the extent that it raises the economic value of the work product.

Value-added is measured by what a buyer would pay for the design after the activity versus before it. A test that removes a large risk can add more value than weeks of coding, and work that changes nothing about expected profit adds none.

Watch the work product, not the worker: queued work, not idle people, is where most waste hides.

In development, inventory is invisible design-in-process. When every engineer is busy, the work product spends most of its life waiting in queues, and that waiting is pure cost of delay.

Important trade-offs usually have U-shaped total-cost curves with an interior optimum.

When one cost rises and another falls with the same choice (batch size, test effort, decision timing), the total has a minimum in the middle. Extremes are rarely optimal.

Even imperfect answers improve decisions; the flat bottom of a U-curve forgives estimation error.

Being 50% off the optimum on a U-curve typically costs only a few percent. So a rough cost-of-delay estimate is enough to move decisions in the right direction — waiting for precision is the expensive option.

Most economic value is decided by the many small decisions, so influence those rather than only the few big ones.

Hundreds of daily trade-offs by engineers outweigh a handful of executive gate decisions. Equip the people making them with economic decision rules.

Economic choices must be made continuously as new information arrives, not once at the start of a project.

The right trade-off shifts as markets, costs and risks change. A plan fixed at kickoff locks in yesterday's economics; a decision rule lets the team re-decide every day.

Many economic choices are more valuable when made quickly; their value decays while they wait.

An opportunity to save two weeks of schedule is worth nothing if approving it takes two weeks. Fast, local decisions capture value that escalation lets rot.

Inside every bad choice lies a good choice: decompose an option and keep its good parts.

A feature that loses money as a whole often contains sub-features with high value per cost. Splitting it and keeping only those turns a rejection into a profitable decision.

Build a system that captures the cheap economic opportunities early, before they disappear.

Early in a project, schedule and cost can be traded cheaply; later the same trade is expensive. Pre-authorize small trades (e.g. 'spend up to $X to save a week') so engineers can harvest them the moment they see them.

Use economic decision rules to decentralize control without losing economic alignment.

A rule like 'a week of delay costs $150k' lets anyone make a correct trade-off without a meeting. Boeing's 777 program let engineers trade up to about $300 of unit cost per pound of weight saved.

Make sure decision makers feel both the cost and the benefit of their choices.

A team charged for expense but never for delay will always save budget and lose schedule. Pricing scarce resources and delay makes local choices match global economics.

Every decision has an economically optimal moment; neither as early nor as late as possible is right by default.

Deciding early is cheap to execute but uses poor information; deciding late uses better information but costs more to change course. The total forms a U-curve with an optimum you can reason about.

Always compare marginal value with marginal cost, not totals or averages.

Keep improving a feature only while the next increment of value exceeds the next increment of cost (including cost of delay). The optimum is where the two marginal curves cross, usually well before 'complete'.

Ignore money already spent; only future costs and benefits matter to a decision.

Whether a project has burned $1M or $10M, the question is the same: does the remaining spend buy more value than it costs? Past spend explains history but cannot change the comparison.

Information is worth what it changes in expected economic outcome; buy it when it costs less than that.

A prototype or test is valuable only if its result could change a decision. Information is worth most when uncertainty is highest and the stakes are large, and cheap early information is the best buy.

Don't pay more for insurance than the expected loss it prevents.

Parallel backup solutions are insurance against a technical failure. Add another path only while its cost is less than the reduction in expected loss it buys.

A high probability of failure does not imply bad economics when the payoff is asymmetric.

Like a newsboy stocking papers, judge an option by expected value, not by its odds. A bet that fails 90% of the time but returns 20× on success is a good bet, especially in a portfolio.

To influence financial decisions, speak the language of money.

Executives who control resources respond to dollars, not to cycle-time charts. Translate 'we'll be three weeks late' into '$450k of lost life-cycle profit' and the conversation changes.

Product development inventory is information, so it is invisible both physically and on the balance sheet.

A factory sees its work-in-process as piles on the floor and dollars on the books; a product team's queue is specs waiting for review, branches waiting for QA, and tickets in a backlog. Because nobody trips over it, nobody manages it. Make it visible: count the items waiting at every hand-off.

Queues are the root cause of most of the economic waste in product development.

Every item waiting in a queue adds cycle time, and with it more risk (the market and technology drift while it waits), more variability, more overhead to track and re-plan it, lower quality (feedback arrives late), and less motivation (no urgency for work that will just wait downstream).

Queue size grows explosively, not linearly, as capacity utilization approaches 100%.

For an M/M/1 queue the number of items in the system is ρ/(1−ρ): going from 80% to 90% utilization more than doubles it (4 → 9), and 95% doubles it again (19). A team planned to 100% loading has, in theory, an infinite queue.

Most of a queue's damage comes from rare high-queue states, not from typical ones.

Queue size follows a geometric distribution: long queues are improbable, but each one delays many items at once, so the low-probability tail carries a large share of the total delay. Watch for, and react to, those states rather than to the average.

Variability in arrivals and in service times increases queue size roughly linearly.

Kingman's approximation multiplies the M/M/1 queue by (Ca² + Cs²)/2: halving the variability of task durations (e.g. M/M/1 → M/D/1) halves the queue. Useful, but utilization is the bigger lever because it acts exponentially.

At high utilization, small changes in load produce large swings in queue size and cycle time.

The slope of the queueing curve, dLq/dρ, rises steeply near 100%. At 95% loading a 1-point change in load moves the queue by several items; at 70% it barely moves. Highly loaded processes amplify the variability fed into them.

Serve pooled demand with reliable, high-capacity servers.

One shared queue feeding several engineers beats a separate queue per engineer, because no one idles while another's line grows and one long job cannot block everyone behind it. A single fast server is even faster, but becomes a single point of failure.

Adjacent queues see either the arrival variability or the service variability of the upstream process, depending on how loaded it is.

A lightly loaded upstream stage passes its arrival pattern straight through; a heavily loaded one releases work at the rhythm of its own service times. Look at the whole chain: smoothing a high-variability upstream step can shrink the queue at a downstream bottleneck.

The right queue size is an economic trade-off between the cost of capacity and the cost of delay.

More capacity costs money but cuts queues; less capacity saves money but delays everything. Add the two costs and pick the utilization at the bottom of the U-curve. The higher the cost of delay, the lower the economic utilization.

The cost of a queue depends on the order in which its jobs are served.

When jobs differ in cost of delay and duration, first-in-first-out is rarely optimal; serving the highest cost of delay per unit of capacity first (WSJF) minimizes total delay cost. Sequencing matters most when queues are large; making queues small is better still.

Use cumulative flow diagrams to monitor queues.

Plot cumulative arrivals and cumulative departures over time: the vertical gap is the current queue, the horizontal gap is the time an item spends in it, and the slopes are demand and throughput. Emerging queues show up as a widening gap long before deadlines slip.

Average wait time equals average queue size divided by average processing rate.

Little's Law (W = L / λ) holds for any stable queue regardless of distributions. If a test team finishes 10 builds a week and 40 are waiting, a new build waits about four weeks; you can forecast cycle time from a queue count.

Don't control capacity utilization; control queue size.

Utilization is hard to measure and, near 100%, tiny errors in it mean huge differences in queues. Queue size is easy to count, and it is what actually causes delay, so set limits on it and act when they are exceeded.

Don't control cycle time; control queue size.

Cycle time is a lagging indicator: you only learn it when items finish, long after the queue built up. Queue size is a leading indicator that moves the moment arrivals outpace capacity, so it lets you intervene earlier.

Over time, queues randomly drift into seriously out-of-control states and can stay there for long periods.

A queue is the running sum of random differences between arrivals and departures, a random walk whose spread grows with the square root of time. Even with balanced average load, some paths wander far from zero and take a long time to come back.

Randomness won't reliably fix a queue that randomness created; intervene quickly when it gets large.

Because a random walk has no memory, a large queue is as likely to grow as to shrink. Set a queue limit and, when it is hit, act: add capacity, shed or block low-value demand, or purge work. Fast, small interventions keep queues bounded.

Variability can create economic value, so it should not be eliminated by reflex.

A design project whose outcome is certain teaches you nothing; the value of development comes from uncertain experiments that might succeed. Manufacturing-style variance reduction (Six Sigma on every task) suppresses the very innovation you are paying for.

When upside gains are larger than downside losses, more variability raises expected value.

A product bet usually loses at most its investment but can win many times that, like a call option. Under such a convex payoff, widening the spread of outcomes adds more to the upside tail than it costs on the downside.

The right amount of variability is an economic optimum, neither the minimum nor the maximum.

Generating variability (radical designs, more risky experiments) has costs that grow faster than its benefits eventually. Find the point where the marginal value of extra spread equals its marginal cost instead of minimizing or maximizing it.

Tests generate the most information when their chance of failure is about 50%.

Information per test is the entropy of its outcome, which peaks at a 50/50 pass/fail probability. A test suite that always passes, or an experiment you are sure will work, produces almost no information; design experiments that genuinely might fail.

Combining many uncorrelated sources of variation reduces relative variation.

The standard deviation of a sum of N independent tasks grows only with √N while the mean grows with N, so the coefficient of variation shrinks by √N. Hold one schedule reserve for the whole project instead of padding every task.

Forecasts become dramatically more accurate as the time horizon shrinks.

Errors compound: market needs and technology drift, and forecast error grows faster than linearly with horizon. Shorter release cycles and rolling plans let you commit only over horizons you can actually predict.

Many small experiments produce less total variation than one big experiment of the same size.

Splitting one large bet into many independent smaller ones lets their outcomes pool, so the total result is far more predictable. Ten two-week experiments are less risky than one twenty-week program, even at the same total spend.

Doing something repeatedly reduces its variation.

Repetition builds routine, tooling and learning, so the spread of task times narrows. Frequent small releases make deployment a well-practiced, predictable operation instead of a twice-a-year adventure.

Reusing proven designs reduces variability.

A reused component has known behavior, cost and schedule; only the new parts contribute large uncertainty. Reuse where novelty adds no value, and spend your variability budget where it creates differentiation.

You can reduce variance by introducing a counterbalancing effect that moves opposite to the disturbance.

Variance of a sum includes twice the covariance, so a negatively correlated term cancels swings. Cross-trained engineers who move to whichever stream is behind, or scope that shrinks when the schedule slips, create negative covariance.

Buffers buy reduced variability of outcome, at the price of time or money.

A schedule buffer turns an uncertain finish into a later but more certain one; you pay its cost every time, even when it is not needed. Size it economically: add buffer until the cost of one more day equals the expected lateness cost it avoids.

Reducing the consequences of variability is usually a better lever than reducing variability itself.

The cost of variability is the product of how often deviations happen and how much they cost. Fast feedback that catches a drifting design early truncates the loss tail at a fraction of the cost of preventing every deviation.

Operate in the linear range of system performance, where variation has small consequences.

In a nonlinear region (a queue near 100% utilization, a structure near its limit) symmetric swings produce asymmetric damage, so average performance is worse than performance at the average. Back away from the knee of the curve.

Accept variability in something cheap to protect something expensive.

When schedule slips are costly, let budget or low-value scope flex instead: paying for overtime or dropping a minor feature is cheaper than missing a market window with a high cost of delay.

Improving iteration speed usually pays more than improving the defect rate.

Time to reach quality = iterations × cycle time. Halving cycle time always halves the total, while halving an already-low defect rate removes only a fraction of an iteration. Invest in fast builds and fast tests before perfect first passes.

Move variability to the stage of the process where it costs the least.

Air traffic control holds flights on the ground, not in the air, because waiting at the gate is far cheaper than circling. In development, absorb variation in the unstarted backlog rather than as half-finished work or a slipped launch.

Shrinking batches shortens cycle time.

An item in a batch waits for every other item in that batch to be processed before it moves on, so time in queue grows roughly in proportion to batch size. Halve the batch of features per release and the average feature reaches users about twice as fast — without adding a single engineer.

Smaller batches make flow smoother and less variable.

Large batches arrive as lumps that swamp a downstream process and then leave it idle. Many small transfers turn a spiky arrival pattern into a nearly steady stream, which lowers queues at every following stage — e.g. a QA team receiving 3 stories a day instead of 30 every other week.

Smaller batches deliver feedback sooner.

You cannot learn whether work is right until the batch reaches the next step. A pull request of 50 lines is reviewed in an hour; a 5,000-line branch waits days, and every line written meanwhile is built on unverified assumptions.

Smaller batches lower risk.

Risk falls because cycle time is shorter (less exposure to change), feedback is faster (errors are caught before they propagate), and a failure affects fewer items. A failed deploy of one change is a quick rollback; a failed quarterly release is a crisis.

Smaller batches cut overhead.

It feels like big batches save overhead, but the overhead of large queues dominates: more status meetings, more re-prioritization, more tracking of stale items, more merge conflicts. Teams that move to small batches routinely find their coordination load goes down, not up.

Large batches lower efficiency.

Slow feedback means more work is done on top of a mistake before the mistake is found, so rework grows faster than batch size. Engineers also lose context: fixing a bug found the same day is quick; fixing one found three months later means re-learning the code first.

Large batches drain motivation and urgency.

When the deadline is a year away, a day's slip feels irrelevant and nobody sees the result of their work. Small batches give each person fast, visible results and a near deadline, so effort and ownership rise.

Large batches make cost and schedule grow exponentially.

Long projects have more time for requirements and technology to change, and every change triggers more rework and more delay, which invites more change. That is why a 6-month project slips a few weeks while a 3-year program slips by years.

Large batches tend to grow even larger.

A big, slow project is the only train leaving the station, so every stakeholder piles on scope; the extra scope delays it further, which attracts still more scope. Big projects also become too important to cancel, absorbing the best people and starving small ones.

A whole batch moves only as fast as its worst element.

If a release bundles 40 changes, the release ships when the slowest or riskiest change is ready — and the most sensitive change sets the review and testing rigor for all of them. The bigger the batch, the more likely it contains a slow or risky outlier.

The economic batch size is a U-curve trade-off between transaction cost and holding cost.

Each batch carries a fixed transaction cost (a release, a test campaign, a review meeting), which favors big batches; every item waiting in a batch carries holding cost (mostly cost of delay), which favors small ones. Their sum is a U-shaped curve with a flat bottom, so batch size is a continuous variable you can tune, and being somewhat off the optimum costs little.

Driving down transaction cost per batch lowers total cost and moves the optimum toward smaller batches.

The U-curve is not fixed: invest in test automation, one-click deploys or standing review slots, and the transaction cost falls, so the optimal batch shrinks and total cost drops. This is how continuous delivery became economical — not by ignoring transaction costs, but by eliminating them.

Reducing batch size saves much more than the simple U-curve predicts.

The classic U-curve counts only transaction and holding cost; it ignores slower feedback, extra rework, higher risk, overhead and lost motivation, all of which grow with batch size. Add them and the true optimum lies further left — and the first moves down from a huge batch pay off enormously.

Small batches let you fill capacity more precisely.

Packing a sprint or a test rig with a few big chunks leaves large unusable gaps — a 5-day item can't fit in 3 free days. Small work packages fill the gaps, so you can run at a chosen utilization instead of being forced over or under it.

Loose coupling between subsystems enables small batches.

If modules depend tightly on each other, changing one forces a coordinated big-bang change to many. Stable interfaces, modular architecture and backward-compatible APIs let each team ship small changes independently and in any order.

The transport batch matters more than the production batch.

A production batch (a setup-heavy operation) may need to stay large, but the transport batch — how much work is handed to the next step at once — can usually be cut to one item. Write the spec as one document if you like, but release it to developers section by section as each is done.

Proximity makes small batches possible.

When people sit together, the transaction cost of a conversation is nearly zero, so they exchange questions one at a time instead of batching them into a weekly meeting or a long email. Co-location (or always-on chat with overlapping hours) shrinks the batch size of communication.

Shorter run lengths reduce queues.

Alternating frequently between work types — short runs of each — keeps every type's queue small. A team that spends a whole quarter on features then a quarter on tech debt builds a large backlog of each; interleaving them every week keeps both flowing.

Good infrastructure enables small batches.

Small batches only pay when each transaction is cheap, and infrastructure is what makes it cheap: CI pipelines, automated test suites, feature flags, staging environments, and test fixtures that let a subsystem be verified without the whole product.

Sequence first the work that adds the most value for the least cost.

Within a batch, order matters: run the cheap tests most likely to fail first, and attack the riskiest unknowns early, so the batch reveals bad news at the lowest cost. A five-second lint step should never wait behind a forty-minute integration suite.

Cut batch size before you attack bottlenecks.

Adding capacity at a bottleneck is expensive and slow; reducing batch size is usually cheap and reduces queues everywhere, including at the bottleneck, by smoothing the flow into it. Shrink batches first, then see which bottlenecks still matter.

Change batch size as the economics change.

The optimum depends on transaction and holding costs, and both move during a project. As launch nears and cost of delay rises, the holding cost per waiting item goes up, so the right batch size shrinks — e.g. daily test cycles near release instead of weekly ones early on.

Limit the amount of work-in-process to control cycle time and flow.

By Little's Law, cycle time is WIP divided by throughput, so capping WIP caps the average cycle time. Queueing math shows the price is small: a limit at about twice the average unconstrained queue cuts the worst queues and the long cycle times while rejecting only a percent or two of demand.

WIP constraints force the rate of starting work to match the rate of finishing it.

When a downstream stage is full, upstream cannot push more into it, so the system admits work only as fast as it completes work. Without the constraint, a fast upstream stage keeps feeding a slower one and the difference silently becomes a queue.

Use a global constraint on total WIP when the bottleneck is predictable and permanent.

Theory of Constraints' drum-buffer-rope releases new work only as the bottleneck finishes it, capping the whole line's WIP with one simple rule. It works well in a factory with a stable bottleneck; in product development the bottleneck moves with the work mix, so a single global cap reacts slowly.

Where you can, constrain the WIP of each local pool instead of only the total.

A kanban limit at every hand-off (like TCP's window at every connection) stops the stage just upstream of a jam within one item, and the back-pressure propagates step by step. Local limits react faster and need no knowledge of where the bottleneck currently is.

Use a WIP range, not a single number, to decouple the batch sizes of adjacent processes.

If design hands work over in batches of five and test consumes them in batches of three, a fixed WIP target can never be met exactly. Let WIP float between an upper and lower bound so each process can use its own economic batch size while the total stays controlled.

When WIP reaches its upper limit, block all new demand until it falls.

The blocked work does not vanish; it waits outside the system in a cheap, uncommitted state (a backlog nobody has started, a request not yet accepted). This is the simplest response and the one a kanban card or a full TCP window applies automatically.

When WIP is too high, kill the lowest-value work in process.

Money already spent is a sunk cost; the question is whether the remaining work is worth its remaining cost plus the delay it imposes on everything behind it. A queue crisis is the moment to cancel the marginal projects that should have been cancelled anyway.

Reduce WIP by shedding non-essential requirements when the queue is high.

Cutting a feature from every item in the queue reduces the work content of the whole queue at once. Decide in advance which requirements are expendable so you can drop them quickly, the way a release train drops the stories that don't make the cut.

Apply extra resources to an emerging queue quickly, while it is still small.

Queues grow and drain asymmetrically: a little extra capacity early prevents a big queue, while the same capacity added late needs a long time to drain it. Speed of response matters more than the size of the response.

Use part-time resources on high-variability work so they can surge when a queue forms.

Someone loaded at 50% on a project can jump to 100% the day a queue appears, with no ramp-up because they already know the work. A full-time person already at 100% has no surge capacity at all.

Pull high-powered experts onto emerging bottlenecks.

A senior expert can clear in days a problem that would take a team weeks, so keep your best people lightly loaded and on call for queue emergencies rather than buried in routine work they would be fully utilized by.

Develop people who are deep in one specialty and broad across many.

A T-shaped engineer adds value on their own specialty and can still help usefully wherever a queue appears. Pure specialists are efficient but cannot move; pure generalists move but lack depth.

Cross-train people at adjacent processes so they can absorb each other's queues.

The most useful overlap is with the stage next door: a developer who can write and run tests can help when the test queue grows, and the hand-off between them gets better too.

Change the mix of work released upstream to regulate the queue at a bottleneck.

When the test queue is high, start the jobs that need little testing and hold the test-heavy ones; when it is low, do the reverse. The total work is unchanged, but the bottleneck's load is smoothed by sequencing upstream work.

Watch the age of items in WIP; the outliers carry the problem.

An average cycle time hides the few jobs that are stuck. Tracking the age of every item in process exposes them early, because an item that has been in a stage far longer than usual is almost always blocked, not just slow.

Have a pre-planned escalation process for items that exceed an age limit.

Decide in advance who gets told and what happens (more people, an expert, a decision from management) when a job crosses the aging threshold, so the response is automatic instead of negotiated each time.

Throttle demand gradually as the queue approaches its limit instead of slamming it shut at the limit.

Internet routers using random early detection drop a growing fraction of packets as the queue rises, so senders slow down before the buffer fills. Gradual throttling avoids the oscillation of on/off blocking and keeps the queue short.

Give different classes of work different WIP limits and priorities according to their cost of delay.

A single queue treats a high-cost-of-delay expedite like routine work. Separate workstreams with their own WIP constraints and priority give fast service to the urgent class, as Internet DiffServ does for voice versus email traffic.

Adjust WIP constraints as the capacity of the system changes.

TCP grows its window slowly while things flow and cuts it sharply at the first sign of congestion, constantly tracking the capacity it can actually get. A fixed WIP limit set for last quarter's team is too high when people leave and too low when they join.

Prevent individual work items from expanding without limit.

Some tasks grow the longer you work on them: research that never converges, a refactor that keeps finding more. Under a WIP limit an expanding task also holds a slot hostage, so set a time or effort box and force a decision when it is reached.

Constrain WIP in the part of the system where queueing is most expensive.

Not all queues cost the same: a queue of committed, half-built work ties up money and decays, while a queue of unstarted ideas costs little. Hold excess demand where it is cheapest and keep the expensive queue short.

Small, repeated reductions in WIP add up to large reductions in cycle time.

Ratchet the WIP limit down a little at a time, fix whatever problem the tighter limit exposes, then ratchet again. Each step is cheap and the effects on cycle time compound, much like reducing inventory to expose the rocks in lean manufacturing.

Make WIP continuously visible to everyone.

Product development inventory is invisible information, so represent each item as a physical or digital card on a board. Once people can see the pile in front of a stage, they self-organize to clear it.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Push control down to the people closest to the work for problems and opportunities that lose value quickly.

A perishable problem — a failing build, a customer about to churn, a test rig that just broke — is cheapest when it is handled in hours, not after a weekly review. Escalating it adds queueing delay at the decision maker, and the cost of delay keeps accruing the whole time.

Keep control central for problems that are rare, large, or that benefit strongly from economies of scale.

Choosing a cloud provider, a chip foundry or a company-wide auth library happens rarely, is expensive to reverse and pays off when done once for everyone. A central decision maker sees the whole system and is not overloaded by such infrequent decisions, so its queue stays short.

Choose the level of control as information about the problem emerges: start local, and escalate when it proves big.

Like a fire department that sends one engine and calls more when the fire grows, a team handles a bug locally and escalates only if it turns out to be a security breach. Triage rules (severity levels, spend limits) make the hand-off automatic instead of political.

Adapt the plan to obstacles and opportunities that the plan did not anticipate.

A plan is a hypothesis built on old information. When a customer interview reveals a better feature or an API turns out to be unusable, the team that can change course without a re-approval cycle captures the value while it still exists.

Be able to pull decentralized resources together quickly when a problem needs concentrated force.

Distributed teams handle everyday work locally, but a pre-agreed mechanism — an incident commander rotation, a swarm protocol — lets them mass on a severe outage within minutes. You get local speed most of the time and central power when it is needed, without a permanent central staff.

Decentralized control is less efficient, but that waste can cost far less than the value of a faster response.

Two teams may solve the same problem twice, and local decisions are sometimes slightly worse. That is acceptable when the alternative is a central decision maker running at high utilization, where queueing delay multiplied by cost of delay dwarfs the duplication cost.

Aligned effort across the whole creates more value than excellence in isolated parts.

Three teams each optimizing their own component can still miss the launch if their work does not converge on the same goal. Decentralization only works if units pull in the same direction, so alignment mechanisms are the price of local autonomy.

State the desired end state and its purpose, and impose as few constraints as possible on how to get there.

The Marines' commander's intent tells units why they are doing something, so they can improvise when the plan breaks. 'Cut checkout abandonment 20% by Q3 so we hit the revenue target' survives a vendor API being deprecated; a task list that says 'integrate vendor X' does not.

Define clear roles and boundaries so that independent units neither collide nor leave gaps.

Military units have sectors; teams need clear ownership of services, interfaces and decisions. Boundaries let a team act fast without coordinating every step, because it knows what is — and isn't — its call.

Name a main effort and make every other activity subordinate to supporting it.

Not every front deserves equal resources; the main effort is where concentrated effort produces decisive results. When a support team must choose between two requests, the one that helps the main effort wins — a decision rule that needs no escalation.

Be ready to shift the main effort quickly when conditions change.

Marines move the main effort to whatever unit finds a weakness. In product work, when one experiment shows ten times the expected lift, resources should flow to it within days, not wait for the next annual plan.

Beyond agreeing on the plan, agree on how you will stay aligned when the plan stops fitting reality.

The first agreement is the plan; the second is the shared intent and set of rules everyone falls back on once events overtake it. With that second agreement, teams that lose contact with each other still make consistent choices instead of waiting for new orders.

Coordinate tactical issues directly between peers rather than routing them through a central node.

Routing every interface question through a project manager doubles the message hops and turns the manager into a queue. Adjacent teams that talk directly resolve issues faster and leave the manager free for the few cross-cutting decisions.

Prefer simple, modular plans that can be reconfigured easily.

A plan with tight dependencies collapses when one step slips; a plan made of independent modules lets units substitute a different route to the same objective. Detailed plans are not useless, but their value is in preparation, not in faithful execution.

Keep some reserve capacity decentralized, close to where problems arise.

A reserve held at headquarters arrives late. A team that keeps 10–20% of its capacity uncommitted can absorb surprises — an urgent customer bug, a failed test — immediately, without pulling people off the main effort.

Engage the real problem early and meaningfully to uncover what the plan does not know.

Marines probe to find where the enemy actually is. Early prototypes, customer tests and integration spikes do the same: they reveal the true difficulty and the true opportunity while there is still time to shift the main effort.

If decisions are decentralized, make the information they need widely available.

Local decision makers can only make good economic decisions if they see priorities, cost of delay, and system state. Visible dashboards, open roadmaps and shared economic decision rules replace the request-for-information round trip to the center.

A system cannot respond to changes faster than its control loop can cycle.

If your observe–orient–decide–act loop takes a month (monthly steering committee), you cannot track a market that changes weekly; you are always acting on stale information. Shorten the slowest stage — usually the decision approval — to raise the frequency response.

When response time matters, measure response time.

Organizations that measure the efficiency of decision makers drive them to high utilization and long queues. If speed of response is what creates value, track time-to-decision and time-to-resolve explicitly, the way support teams track a service-level agreement.

Use internal and external markets to decentralize control.

Prices let people decide locally: if a shared test lab charges a premium for jump-the-queue service, a team decides for itself whether its cost of delay justifies paying, with no central arbiter. Buying outside capacity when internal capacity is congested is the same idea.

Initiative grows when it is used and supported, and withers when it is punished.

People who see their initiative rewarded take more of it; people who are criticized for well-intentioned mistakes stop taking it. Initiative is a capability the organization must cultivate continuously, not a switch it can flip when the plan fails.

Use the speed and bandwidth of face-to-face communication.

A conversation resolves an ambiguity in one round that an email chain needs several days and many messages to settle. Co-location, video calls and short daily meetings keep the coordination loop fast enough for decentralized teams.

Trust is built through experience.

Managers delegate more authority to people whose past decisions they have seen work out, and teams trust peers they have worked with before. Small batches, frequent interactions and stable teams generate many such experiences quickly, which expands the space of decentralized decisions.