Book Summary: The Goal by Eliyahu Goldratt

1. 1Identify the bottleneck first: total the market demand (existing order backlog plus forecast for new products and spare parts, including inter-plant transfers) and compare it against each work center's available production hours net of maintenance, lunch, and breaks. Where available hours are equal to or less than demanded hours, you have your Herbie.
2. 2Set the bottleneck's target flow at or a tiny bit below market demand — not above it — so that every hour it runs converts into a sellable, needed part rather than excess inventory.
3. 3Feed the bottleneck only good, needed parts: inspect and clear material before it reaches the constraint so the machine never spends its limited hours processing defects or units that won't ship.
4. 4Eliminate idle time on the constraint specifically. Stagger lunches and breaks so the machine keeps running, and never let it sit starved for material or blocked by a downstream jam.
5. 5Stop measuring the bottleneck by local efficiency; measure it by whether it is producing on-demand, quality parts. Treat every lost bottleneck hour as an hour lost to the whole system.
6. 6Deliberately keep non-bottlenecks running below their own potential — activate them only to the level the bottleneck can absorb, since running them faster just builds inventory against the goal.
7. 7Purge phantom demand from your calculations: verify routings against reality (equipment actually present, machines not sold or retired) before trusting any capacity figure.

Rogo's team sets out to find whether the plant has a bottleneck by calculating demand for every resource. First they compile total market demand from the existing order backlog plus the forecast for new products and spare parts — the complete product mix, including what they sell to other plants. Then they build 'work centers' (any group of identical resources — ten same-skill welders, four identical machines) and calculate the hours each must contribute, dividing work-center hours needed by the number of resources to get effort per resource. Early on they waste two and a half hours calculating demand for milling machines that were sold a year ago, because the routings still listed them — a reminder to ground the numbers in reality. When a resource's available hours (net of maintenance and breaks) are equal to or less than its demanded hours, that resource is the Herbie. The NCX-10 turns out to be the constraint, and Jonah's point lands: making non-bottlenecks do more work than the NCX-10 doesn't raise output, it only builds a mountain of inventory.

• If a resource's available hours are equal to or less than the hours demanded of it, then it is the bottleneck and must govern the flow.
• If the bottleneck is idle, starved, or processing a defective/unneeded part, then treat it as an hour lost to the entire system, not just to that machine.
• If activating a non-bottleneck would push it above the bottleneck's pace, then don't — the extra output is excess inventory, which works against the goal.
• If a part is defective, verify or scrap it before the bottleneck, never after — a rejected part that already consumed bottleneck time is unrecoverable capacity.
• If you are tempted to justify utilization by a target percentage (90%, 60%), then reject it unless the number is derived from the system's constraints rather than local efficiency.

• Confusing activation with utilization — keeping people and machines busy to protect efficiency numbers. The tell: rising inventory and idle-time avoidance cited as justification while throughput stays flat.
• Processing defective or unneeded parts through the constraint. The tell: the bottleneck is 'always running' but shipments still miss dates because its hours went into scrap or wrong product.
• Letting the bottleneck sit idle during lunch, breaks, or material shortages. The tell: the machine stops when people stop, and no one staggers coverage.
• Trusting capacity figures built on phantom resources or stale routings. The tell: hours calculated for machines that were sold or retired — like Rogo's team spending two and a half hours on nonexistent milling machines.
• Setting bottleneck flow equal to or above demand instead of a hair below it. The tell: when market demand dips you keep producing and lose money on inventory that won't sell.

• ▸Constraint resource / work center: name the identified Herbie.
• ▸Available hours (net): production hours minus maintenance, lunch, breaks.
• ▸Demanded hours: hours the market demand requires from this resource.
• ▸Target flow rate: set at or slightly below market demand — record the number.
• ▸Idle-time log: hours lost this period to starvation, blockage, or breaks.
• ▸Defect/unneeded parts processed: count of bottleneck hours spent on scrap or wrong product.
• ▸Pre-constraint quality gate: yes/no — is material inspected before it reaches the bottleneck?
• ▸Break coverage plan: how is the machine kept running during lunches/breaks?
• ▸System hours lost: idle + defective-part hours = throughput lost to the whole plant.

1. 1Time material release to the bottleneck's actual consumption rate, not to keep every work center busy — release only what the constraint can process.
2. 2Cut batch sizes so parts move to the next station as soon as a smaller quantity finishes, rather than waiting for a whole large batch to complete.
3. 3Instruct materials handlers to move partial batches forward instead of holding everything until the full batch is done.
4. 4Establish buffers — the queues in front of assembly and in front of the bottlenecks — and stock them with everything scheduled to be worked, plus work two or three days out.
5. 5Audit the buffers daily for 'holes': jobs that are scheduled but missing from the queue.
6. 6When a hole appears, trace back to the work center where the material is stuck; that gap signals a new bottleneck forming.
7. 7Resolve the hole by telling that foreman which job to run next — do not break setups or light expediting fires.
8. 8Measure success by shipping excess inventory out as finished product and refusing to refill the floor with new work-in-process beyond current demand.

After Alex's plant cuts batch sizes, work flows through more smoothly than ever. Materials handlers used to wait for an entire large batch to finish before moving anything, which starved downstream centers and turned a nonbottleneck into a temporary bottleneck. With smaller batches, parts reach the next station sooner and total idle time actually drops — instead of workers sitting for a couple of hours, they now get a few ten-to-twenty-minute waits scattered through the day for the same volume of work. Inventories fall to their lowest ever: stacks of parts and sub-assemblies shrink to half their former size, as if trucks hauled everything away — which effectively happened when the excess shipped as finished product. Bob's team then times material release to the bottlenecks' consumption and inspects the assembly and bottleneck buffers daily for holes. A hole two or three days out reveals where material is stuck; they respond not by expediting but by pointing the foreman to the job they'd prefer next.

• If a work center sits idle while excess inventory floods the floor, then the cause is upstream large-batch waiting — shrink the batch and move partial quantities.
• If a scheduled job is missing from a buffer (a hole), then a new bottleneck may be forming — trace to where material is stuck.
• If you find a hole, then reprioritize the stuck job at that foreman's station; do not break setups or expedite.
• If material release outpaces the constraint's consumption, then work-in-process piles up — release only at the bottleneck's rate.
• If idle time still occurs at nonbottlenecks after changes, accept it — periodic idleness there is correct, not a failure.

• Holding a full large batch before moving it — the tell: a downstream center sits idle while excess inventory sits everywhere else.
• Keeping every work center busy to protect efficiencies — the tell: a nonbottleneck becomes a temporary bottleneck and starves stations after it.
• Reacting to a buffer hole by expediting or breaking setups — the tell: recurring rush calls and firefighting instead of a calm reprioritization.
• Refilling the floor with new work-in-process after clearing inventory — the tell: WIP creeps back above current demand.
• Checking buffers only for today's scheduled work — the tell: new bottlenecks surface too late because you didn't look two or three days out.

• ▸Buffer location: name the assembly or bottleneck queue being checked.
• ▸Scheduled jobs (today + 2-3 days): list every job that should be present.
• ▸Holes found: mark any scheduled job missing from the buffer.
• ▸Stuck-at work center: record where the missing material currently sits.
• ▸Action taken: note the job you told the foreman to run next (no setup breaks).
• ▸Current batch size: record the quantity being moved between stations.
• ▸Release-vs-consumption check: confirm material released matches bottleneck consumption.
• ▸WIP level today: log floor WIP and flag if above current demand.
• ▸Idle-time pattern: note whether waits are short segments or multi-hour blocks.

1. 1Write the definition verbatim: throughput is the rate at which the system generates money through sales. Do not paraphrase it into 'production'—if you produce something and don't sell it, it is not throughput.
2. 2Test every proposed change or investment against a single question: did we sell more products as a result? If sales did not rise, throughput did not rise, regardless of activity on the floor.
3. 3Handle the three measurements as a group. Whenever you move throughput, check what happened to inventory and operational expense at the same time—changing one forces a change in at least one other.
4. 4Refuse to count value added by direct labor as throughput or inventory. Money only becomes throughput when finished product is sold, so keep labor on the operational-expense side to avoid confusing an investment with an expense.
5. 5Express the goal operationally: increase throughput while simultaneously reducing both inventory and operational expense. Rank actions by whether they push all three in the right direction at once.
6. 6Trace throughput to the exit, not the machine. Ask whether the company would stay in business if it only manufactured product to fill the finished-goods warehouses—if the answer is no, the money isn't in until it ships and sells.

Alex evaluates the plant's robots using Jonah's three questions. First: did we sell any more products because of the robots (did throughput go up)? Alex cannot show any effect—no additional sales are traceable to them, so throughput did not rise. Second: did anybody get laid off (did operational expense go down)? No—people were shifted around, not removed, and the robots added depreciation, so operational expense went up. Third: did inventories go down? No—inventories generally increased over the past six or seven months. Because throughput stayed flat while both inventory and operational expense rose, the robots did not make money for the system, even though local efficiencies looked good.

• If product is produced but not sold, then it is not throughput—leave it out of the throughput count no matter how much activity created it.
• If a change raises throughput but also raises inventory or operational expense, then re-examine it as a group before claiming a gain—one measurement moving is never the whole story.
• If you cannot answer 'yes, we sold more' for an investment, then treat any efficiency gains it produced as unproven and possibly worthless.
• If a dollar's classification as investment-versus-expense is ambiguous, then default to keeping value-added out of inventory to prevent confusion between the two.
• If an action improves a local number but throughput at the shipping door does not rise, then subordinate that action to what actually generates money through sales.

• Substituting 'production' for 'sales' because you're a plant manager—the tell is celebrating output that piles up in finished-goods warehouses instead of shipping and selling.
• Judging robots or new equipment by local efficiency—the tell is rising depreciation and shifted-around headcount with no measurable increase in units sold.
• Counting value added by direct labor into inventory—the tell is arguing 'the labor invested has to be part of inventory,' which reintroduces the investment-versus-expense confusion.
• Reading the three measurements in isolation—the tell is announcing a throughput win while inventory has quietly climbed for six or seven months.
• Treating manufacturing as separate from sales ('that's marketing')—the tell is Bob's objection that 'we've got nothing to do with sales,' ignoring that unsold goods never become money.

• ▸Proposed action or investment: one line describing what changed.
• ▸Units actually sold before vs. after: enter both numbers, not units produced.
• ▸Throughput movement: up / flat / down, based only on sales.
• ▸Inventory movement: up / flat / down, in money terms.
• ▸Operational expense movement: up / flat / down, including any added depreciation.
• ▸Value-added labor check: confirm labor is counted as operational expense, not inventory.
• ▸Warehouse test: would the company survive if this only filled finished-goods warehouses? yes/no.
• ▸Verdict: does it increase throughput while reducing both inventory and operational expense? yes/no.

1. 1Reclassify inventory as a liability, not an asset — every dollar of raw material, work-in-process, and finished goods is cash the system has spent and cannot recover until the product sells. Walk your floor and physically count what's sitting: WIP between machines, filled warehouses, purchasing's stockpiles.
2. 2Quantify the total: sum finished-goods (the $20 million in the warehouses), WIP stacked on the floor, and the raw materials purchasing bought 'cost-effectively' (the 32-month supply of copper wire, 7-month supply of stainless sheet).
3. 3Trace why inventory piles up: material is released on schedule but 'nothing comes out the far end when it's supposed to.' Note that everything ships only after expediting — that gap between release and shipment IS your inventory.
4. 4Test any proposed improvement against inventory: after installing robots or cutting costs, ask 'Did inventories go down?' If they didn't, you did not improve the system regardless of local efficiency gains.
5. 5Separate the local efficiency illusion from system flow: a 36% improvement in one department that ships zero additional product and lowers no inventory is not productivity — it is idle inventory made faster.
6. 6Stop rewarding cost-effective purchasing that buys ahead of need. Renting warehouses to store cheaply-bought material converts a 'good price' into millions of tied-up, non-flowing cash.
7. 7Prioritize converting inventory back into money over local metrics like efficiencies and due-date reports — the goal is making money, and inventory sitting in boxes makes none.

Rogo's plant holds $20 million in finished-goods inventory: quality products of current technology, produced efficiently, sealed in plastic with warranty cards — all sitting in two warehouses waiting for someone to buy them. Meanwhile purchasing has bought a 32-month supply of copper wire and a 7-month supply of stainless steel sheet 'at terrific prices,' with millions more tied up and warehouses rented to hold it. On the floor, stacks and stacks of WIP pile up because material is released on schedule but nothing comes out the far end on time — nothing ships until it's expedited. When Jonah presses Rogo on the robots that gave a 36% departmental improvement, the plant shipped no additional product, laid off no one, and lowered no inventory. So the robots did not increase productivity; they simply added to the pile of things that don't turn into cash. All this efficiency and technology coexists with the plant losing money — because inventory is money frozen, not money made.

• If an improvement raises local efficiency but inventory does not go down, then treat it as no improvement to the system.
• If purchasing buys at a great price but rents warehouses to store the surplus, then the 'savings' are negative — count the tied-up cash as loss.
• If material is released on schedule but products only ship after expediting, then your release timing is manufacturing inventory, not throughput.
• If you have high market share or volume but the goods sit unsold or sell at a loss to 'unload inventories,' then inventory is a liability disguised as a sale.
• If robots or new machines run faster without more product shipping, then you are accelerating the creation of inventory, not reducing it.

• Treating inventory as an asset on the balance sheet while it actually impedes flow — the tell is filled warehouses and floor stacks accepted as normal ('better than many plants I've seen').
• Judging purchasing by price per unit rather than cash tied up — the tell is a 32-month copper supply bought 'cost-effectively' and rented storage.
• Confusing local departmental improvement with system gain — the tell is a 36% efficiency figure that produced zero extra shipments and no inventory reduction.
• Releasing materials on schedule to keep departments busy — the tell is WIP piling up between operations and universal reliance on expeditors.
• Selling at a loss or near-cost to unload inventory and calling it a win on volume/market share — the tell is 'we're losing money but we'll make it up with volume.'

• ▸Finished-goods dollars sitting unsold: total cash frozen in boxed, warehoused product.
• ▸WIP on the floor: estimate dollars stacked between operations awaiting the next step.
• ▸Raw material overbuy: list items and how many months of supply exceed near-term need.
• ▸Warehouse/carrying cost: rent and storage spent to hold surplus inventory.
• ▸Release-to-ship gap: average time between material release and actual shipment (and % expedited).
• ▸Last improvement test: did the most recent efficiency/tech change lower inventory? Yes/No + dollar change.
• ▸Unload losses: revenue sold at or below cost purely to clear inventory this period.
• ▸Cash-recovery target: dollars of inventory to convert back into money next quarter.

1. 1Write Jonah's definition verbatim: operational expense is all the money the system spends to turn inventory into throughput. Precision matters — a measurement not clearly defined is worse than useless.
2. 2Sweep every dollar leaving the system per period: direct labor wages, overtime, supervision, machine service calls, depreciation, and carrying costs on inventory. If it is money spent (not money held), it lands here.
3. 3Treat direct labor as operational expense, not as value added to inventory. Deliberately refuse to roll labor into product value — this eliminates the confusion over whether a dollar spent is an investment or an expense.
4. 4Judge every proposed 'improvement' by whether it reduces this number system-wide, not locally. When you install robots, ask: did people expense actually fall? If no bodies left the payroll, OE did not drop.
5. 5Cross-check against the other two measurements before crediting any gain. If OE didn't fall AND inventory didn't fall AND throughput didn't rise, no productivity was gained regardless of local efficiency figures.
6. 6Count overtime and expediting scrambles as real OE spikes even when they get 'buried.' The order that ships at 11 P.M. on held-over assembly overtime added OE that no efficiency report shows.
7. 7Anchor OE to the whole organization, never to a department. Local optimums — a department looking cheap per part — can raise OE elsewhere and still net worse.

Alex's robot department shows efficiencies averaging above ninety percent and a lower cost per part, so he believes costs went down. Jonah walks it back through operational expense: the union agreement barred layoffs, so people were shifted, not fired — plant people expense did not drop. Inventories did not go down. The company did not ship more product. Because the money the system spends to turn inventory into throughput was unchanged, the 'efficiency' was a local number that never touched OE. Running the robots constantly to hold that ninety percent efficiency actually converted raw materials into unsold inventory, spending OE without generating throughput. The tell is the elevator-cable feeling in Alex's stomach: high local efficiency masking flat system-wide expense.

• If a dollar is spent to convert what you hold into what you sell, then it is operational expense — labor and overhead included.
• If people expense, inventory, and throughput are all unchanged after an 'improvement,' then no productivity gain occurred no matter how good the efficiencies look.
• If you keep a resource busy (robots running constantly) only to protect an efficiency number, then you are adding OE without adding throughput — stop.
• If a change lowers cost in one department but you can't trace its effect on the whole organization, then treat the local saving as unproven — you are chasing a local optimum.
• If you propose reducing OE, check whether it forces inventory up or throughput down — changing one measurement means changing at least one of the others.

• Rolling labor's 'value added' into inventory. Tell: you can't say whether a given dollar was an investment or an expense — the confusion Jonah's definition was built to remove.
• Crediting high machine efficiency as cost reduction. Tell: cost per part 'went down' but no bodies left, inventory held, and nothing more shipped.
• Burying overtime and expediting costs to make an order. Tell: 'I don't know where we'll bury the expense' — the OE is real and untracked.
• Optimizing one department at the plant's expense. Tell: stealing every spare body onto one hot order and hand-carrying parts one at a time — ridiculous output per employee while feeling productive.
• Chanting productivity targets without defining the goal. Tell: fragments like 'hours applied versus standard' and 'direct labor ratios' fly around while nobody asks what the real goal is.

• ▸Period covered — the window you are measuring OE across
• ▸Direct labor spent — all wages paid, judged as expense not inventory value
• ▸Overtime/expediting spent — including costs normally 'buried' to ship late orders
• ▸Overhead spent — supervision, service techs, depreciation on machines
• ▸Carrying cost on inventory — money spent holding what you intend to sell
• ▸Total OE this period — sum of the above, the whole-organization figure
• ▸Throughput change — did the system generate more money through sales?
• ▸Inventory change — did money invested in things-to-sell go down?
• ▸Verdict — gain only if OE fell or throughput rose without OE rising; else no productivity gain

1. 1Reject the intuitive answer that the goal is to produce products, ship orders, or run efficiently. State it plainly: the goal is to make money. Everything else — production, quality, technology — is a means, not the end. Test any proposed goal by asking 'is this an end in itself, or a way to make money?'
2. 2Strip away the textbook vocabulary (total sales, market share, dividends). Ask Lou's question: 'What is the minimum number of measurements needed to know if we are making money?' You are looking for the smallest set, not the longest.
3. 3Establish net profit as the absolute measurement — dollars made after subtracting expenses. This tells you the size of the result but nothing about whether it was worth it.
4. 4Add a relative measurement — return on investment — that relates profit to what you started with. Peach's own words map here: 'I need income.' Absolute profit alone is meaningless without knowing how much money you had to tie up to earn it.
5. 5Add cash flow as the survival measurement — the money actually moving in and out that keeps the plant open month to month. A plant can look profitable on a report and still 'fall into a hole so deep we may never get out.'
6. 6Require all three to move together in the right direction before declaring you are moving toward the goal. Net profit up, ROI up, cash flow up — simultaneously. Any one improving while another sinks is a false signal.
7. 7Re-test every local improvement against these three measures. When someone claims a 36% gain, ask: did net profit rise, did ROI rise, did cash flow rise? If the answer is no on all three, no real money was made.

Rogo brags to Jonah that robots produced a 36% improvement in one department. Jonah reframes it against making money with three questions. First: did the plant ship even one more product per day? Rogo has to admit he'd 'have to check the numbers.' Second: did people expense go down — did you fire anyone? No; the union agreement moved workers to other jobs, so cost held. Third: did inventories go down? They did not. With no more sales, no lower expense, and no lower inventory, none of the money measures moved — so despite the impressive local 36%, the plant did not increase productivity and did not make more money. The department number improved while the things that make money stayed flat.

• If a proposed goal survives the question 'is this an end or a means?' as a means, then discard it and keep asking until you reach making money.
• If you have only an absolute number like '$10 million net profit,' then you cannot judge performance until you also know how much you started with (ROI).
• If a local metric improves but sales, expense, and inventory are unchanged, then no money was made — treat the improvement as cosmetic.
• If net profit, ROI, and cash flow are not all moving upward together, then you are not yet moving toward the goal, regardless of efficiency reports.
• If a 'panacea program' cannot be shown to raise all three money measures, then it will 'never get any better' — refuse to adopt it on faith.

• Confusing activity with the goal: believing 'building the damn products' or high efficiencies equals making money. Tell: managers cite efficiency reports while the plant loses money, as Rogo does against Peach.
• Treating an absolute measure alone as proof of success. Tell: someone announces a big profit number but cannot say what was invested to earn it — Lou's 'how much did you start with?' exposes it.
• Celebrating a local optimum. Tell: a department shows a 36% gain but no additional product ships out the door — the plant-wide money numbers are flat.
• Chasing cost reduction as an endpoint. Tell: 'I've done cost reduction... There is nothing left to trim,' yet the plant still loses money — cutting expense hasn't moved ROI or cash flow.
• Substituting many textbook terms (market share, dividends, sales) for the minimum measurement set. Tell: the answer to 'how do we know if we're making money' becomes a five-minute list instead of a short, decisive one.

• ▸Proposed action/program: name the change being evaluated
• ▸Ends-or-means test: is this the goal itself, or a means to make money?
• ▸Net profit effect: does profit (revenue minus expense) rise? by how much in dollars
• ▸Starting investment: how much money was tied up to earn that profit?
• ▸ROI effect: does return relative to investment rise?
• ▸Cash flow effect: does money actually moving in/out increase?
• ▸All-three verdict: are net profit, ROI, and cash flow all up together? yes/no
• ▸Ship test: did we ship even one more product as a result? yes/no
• ▸Decision: adopt only if all-three verdict is yes; otherwise reject as local/cosmetic

1. 1IDENTIFY the constraint: find the resource whose capacity is at or below market demand. In production, look for the work center with a growing queue of inventory in front of it; the constraint may also sit outside production (marketing's ability to sell) when a resource has excess capacity relative to demand.
2. 2Decide how to EXPLOIT it: extract maximum output from the existing constraint without spending on more capacity. Ensure the constraint is never idle during lunch breaks or shift changes, feed it only good parts (defects at the constraint are irreplaceable lost throughput), and stop it processing anything not tied to real demand.
3. 3SUBORDINATE everything else: choke material release so non-constraints do not run ahead of the constraint. Set the pace of the whole line to the constraint's output; accept idle time at non-constraints rather than building excess inventory.
4. 4Abolish local efficiencies: stop measuring non-constraints on utilization percentages (90%, 100%). Any such number is meaningless unless derived from the system's constraint; running a non-constraint above the constraint only converts raw material into excess work-in-process or finished goods.
5. 5ELEVATE the constraint: add real capacity — offload work to less efficient resources with ample spare capacity, or use other resources of the same type where they exist.
6. 6Adjust and re-cycle: shorten the time buffer once queues shrink; if a constraint is broken, GO BACK to step 1. Explicitly check that no policy, measurement, or habit left over from the old constraint is now inertia holding the system back.

Jonah diagrams two independent flows: Y feeds Product A, X feeds Product B, each with 600 hours available serving separate market demand. Bob claims all of Y's 600 hours can be used; Jonah disagrees. Because Y has excess capacity relative to its market demand, running it flat out produces not throughput but excess finished goods. The rule that emerges: the utilization of a non-bottleneck is not determined by its own potential but by some other constraint in the system. At Alex's plant this is visible in the warehouses — two-thirds of stored inventory is products made entirely of non-bottleneck parts, built far beyond demand by chasing 'efficiency,' while competitive bottleneck-part products sell nearly as fast as they leave final assembly.

• If a work center has a growing queue in front of it, then it is a candidate constraint; if it sits idle waiting for market demand, then the constraint is elsewhere (likely marketing).
• If a non-constraint can run faster than the constraint, then don't — the extra output becomes excess inventory, which is against the goal.
• If you are asked to justify a utilization target (90%, 60%, 25%), then reject any number not derived from the system's constraint.
• If red/late orders exceed 10% of released orders, then increase the time buffer; if below 5%, then decrease it.
• If a constraint has been broken, then return to step 1 and audit for inertia — old rules that no longer fit the new constraint.

• Chasing local efficiencies: keeping every worker busy 100% of the time because idle time 'lowers efficiency.' The tell — warehouses full of inventory far in excess of demand, some obsolete.
• Treating the constraint as always inside production. The tell — a resource with excess capacity is run flat out and finished goods pile up because marketing can't sell them.
• Setting arbitrary acceptable utilization percentages. The tell — numbers like 90% offered with no link to the constraint's requirements.
• Wasting constraint capacity on defects or downtime. The tell — the constraint stops during lunch/shift change, or reworks bad parts, and throughput is permanently lost.
• Letting inertia persist after elevating a constraint. The tell — old release rules, measurements, or offloading habits still applied to a resource that is no longer the constraint.

• ▸Identified constraint: name the resource with the queue or the market limit
• ▸Constraint type: internal (work center) or external (market demand)
• ▸Exploit actions: what keeps it running and fed with good parts only
• ▸Subordinate actions: where material release is choked to its pace
• ▸Non-constraints to leave idle: list, with efficiency measure removed
• ▸Elevate actions: offloading / added capacity, with source resource
• ▸Time buffer status: % red orders (raise if >10%, lower if <5%)
• ▸Constraint broken? yes/no — if yes, restart at step 1
• ▸Inertia check: old rule/measure now removed

1. 1Identify the bottleneck (constraint) first — the resource whose capacity is at or below market demand. In the plant this is the NCX-10 and the heat-treat furnace. Material release is governed by their consumption rate, not by the appetite of every other machine.
2. 2Set the release schedule to the drumbeat of the bottleneck: release raw material into the first operation only at the rate the constraint can process it, offset backward by the lead time needed to feed the buffer in front of the constraint (the 'rope' that ties release to the drum).
3. 3Stop measuring and rewarding non-bottleneck resources on local efficiency. A non-bottleneck kept 'busy' beyond what the constraint can consume produces only inventory. Let non-bottlenecks stand idle when they have no constraint-driven work.
4. 4Place a time buffer of inventory in front of the constraint so it never starves, but size that buffer deliberately — more material than the buffer requires is pure work-in-process cost, not protection.
5. 5Reject the reflex to 'draw against the future forecast' to raise reported efficiencies. When efficiencies dip on a non-bottleneck, that is often correct behavior, not a problem to be solved by releasing more material.
6. 6Reconsider batch size as a release lever: large batches inflate WIP and lengthen the queue at the constraint. Break batches so parts move to the next needed operation as soon as they are done rather than waiting for a full lot.
7. 7Judge every release and batch decision against throughput, inventory, and operational expense — will this release turn into a sold product, or only into a surplus part sitting in the cage?

The welding robots were reported running at about thirty percent efficiency, and Frost would have had Lou's head if the expensive new machines never paid back in the projected time. So Stacey released more materials to all the areas feeding the robots; giving them more to produce pushed their efficiencies up. It looked like a win — 'nobody can find fault with us on that.' But ever since late in the third quarter, the plant ended every month with a surplus of those welded parts, because there were no orders that called for them, or the other components needed to complete an assembly weren't available. The robots consumed material and labor to build inventory that couldn't be sold, so carrying costs (operational expense) rose and real per-unit cost went up, not down. Releasing material to keep a non-bottleneck busy manufactured stacks of unusable WIP while the actual orders still sat late on the floor waiting to be expedited.

• If the resource is not the constraint, then release material to it only at the constraint's consumption rate — never to raise its local efficiency.
• If efficiencies drop on a non-bottleneck, then leave it idle rather than release more material against the forecast to keep it busy.
• If a released part cannot be assembled and sold now — because you lack the matching components or the orders — then releasing it increases cost; do not release it.
• If the constraint is protected by an adequate time buffer, then any additional material released ahead of it is inventory, not insurance — hold it back.
• If cutting batch size moves needed parts to the constraint or to assembly sooner, then break the batch even though it lowers reported per-machine efficiency.

• Releasing material 'on schedule' to every operation regardless of the constraint. The tell: material is released on time but nothing comes out the far end when it's supposed to, and every order must be expedited.
• Chasing local efficiency on expensive machines. The tell: robots run at high reported efficiency while the plant ends each month with a growing surplus of parts nobody ordered.
• Drawing against future forecast to keep people and machines busy. The tell: a year of building inventory 'everybody says we'll use eventually' while the market never materializes.
• Treating rising WIP as normal and unavoidable. The tell: stacks and stacks of inventory on the floor, dismissed because 'every plant our size has the same,' while cash and throughput bleed out.
• Reading falling per-part cost as real savings. The tell: someone claims 'the cost of those parts went down' while ignoring the added inventory carrying cost that pushes operational expense — and true cost — up.

• ▸Constraint resource: name the bottleneck that sets the drumbeat (e.g., NCX-10).
• ▸Constraint hourly consumption rate: parts/units the constraint can actually process per hour.
• ▸Release offset (rope length): lead time from raw-material release to arrival at the constraint buffer.
• ▸Constraint buffer size: target hours of protective WIP in front of the constraint — no more.
• ▸Matching-component check: confirm the parts needed to complete the assembly and a real order both exist before release.
• ▸Proposed batch size: quantity per release, and the smaller size if the batch can be split to speed flow.
• ▸Non-bottleneck idle acceptance: mark which feeders are permitted to sit idle when the constraint doesn't need them.
• ▸Throughput test: will this release become a sold, shipped product? (yes/no)
• ▸Inventory/OpEx flag: note the carrying-cost impact if this material becomes surplus.

1. 1State the goal in one sentence: the organization exists to make money. Write it down and test every other stated goal (quality, technology, efficiency) as a means, not the end — as Alex forces Lou to concede that 'producing products is just a means to achieve the goal.'
2. 2Reduce your scorecard to the minimum measurements needed to tell whether you are making money. Start with net profit as the absolute measure, then add a relative measure, because as Lou notes, '$10 million' means nothing until you ask 'how much did it take to make that?'
3. 3Redefine productivity operationally: every action that brings the company closer to the goal is productive; every action that does not is not. Stop calling activity 'productive' until you can trace it to the goal.
4. 4Audit your current reports and name what each one actually measures. Most tell you only whether a worker 'worked for all the hours we paid' or whether 'output per hour met our standard' — local efficiencies, not money made.
5. 5Distrust cost-accounting efficiency numbers even when they look good. Alex's efficiencies were 'pretty damn good' while the plant lost money; the measurement, not the people, was lying.
6. 6Look for the disconnect between full utilization and profit: if 'just about everybody is working nearly all the time' and you are still not making money, the efficiency measures are misleading you.
7. 7Replace efficiency-maximizing decisions with goal-tested ones: before approving a change (like the robots), ask whether it increased money made, not whether it raised value-added per employee.

Alex justifies his robots by saying they 'increased productivity,' meaning the company formula for value added per employee improved. Jonah rejects this: 'Regardless of how your company defines it, that is not what productivity really is.' He redefines it — productivity is the act of bringing a company closer to its goal — so an efficiency gain that does not move money is not productivity at all. Later Alex climbs the plant stairs and sees the contradiction directly: 'Just about everybody is working nearly all the time. And we're not making money.' His briefcase is full of reports on cost of products, direct labor variances, and output-per-hour standards, yet none answer the real question of whether any action is 'making money for us, or whether we're just playing accounting games.' The efficiency measures were high; the plant was still losing. That gap is the tell that his goal and his measurements were misaligned.

• If a stated objective can be described as a means to money, then it is not the goal — demote it to a means and keep money as the end.
• If a measurement tells you only whether hours were worked or standards met, then it measures local efficiency, not the goal — do not use it to control action.
• If everyone is busy and utilization is high but net profit is not rising, then trust the profit number and treat the efficiency numbers as the thing lying to you.
• If a proposed action raises an efficiency ratio but you cannot trace it to increased money made, then classify it as non-productive regardless of the ratio.
• If you have only an absolute measure like net profit, then add a relative measure, because $10 million on $1 million invested and $10 million on $1 billion are opposite verdicts.

• Accepting the company's efficiency formula without question — 'you've accepted so many things without question that you're not really thinking at all.' Tell: you can recite the formula but cannot explain how it connects to money made.
• Confusing activity with productivity. Tell: you cite 'nearly everybody working all the time' as proof of a healthy plant while profit falls.
• Massaging or trusting efficiency numbers as the scorecard. Tell: your reports look good ('efficiencies are pretty damn good') while cash runs short.
• Chasing more cost reduction as the answer. Tell: you say 'there is nothing left to trim' yet still cannot get orders out the door — the constraint was never cost.
• Treating net profit alone as sufficient. Tell: you announce an absolute dollar figure without stating what was invested to earn it.

• ▸Stated goal (one sentence): write it — must reduce to making money.
• ▸Candidate 'goals' to demote: list each and mark it means or end.
• ▸Absolute money measure: name it (e.g., net profit) and current value.
• ▸Relative money measure: name it (return vs. amount invested) and current value.
• ▸Current reports in use: list each and label efficiency-only or goal-linked.
• ▸Productivity test: for one recent action, does it move money? yes/no.
• ▸Busy-but-broke check: utilization high? profit rising? note the gap.
• ▸Measurement suspected of lying: name the ratio that looks good while money does not.
• ▸Action to stop: one efficiency-driven practice untraceable to the goal.

1. 1State the local metric explicitly: at Alex's plant, the operating belief is that every worker and every expensive machine must always be making parts. Write down which resources you are measuring this way (the NCX-10, the robots, assembly workers).
2. 2Track efficiency as output-of-parts-per-employee and machine utilization, then set policy that treats idle time as loss. Note how this becomes the number Peach will pound on at month-end and the number Granby reviews before deciding.
3. 3Enforce batching and economies of scale: refuse to break the plant onto one order at a time because 'the economies of scale would disappear' and costs would rise. Keep setups long and full so machines stay activated.
4. 4Justify capital purchases by loading them: 'I need high efficiencies to make those things pay for themselves, and I only get the efficiencies if they're making parts.' Keep the expensive equipment busy so it appears to earn back its cost.
5. 5Suppress exceptions like the 41427 order — hand-carrying, robbing workers from other departments, overtime against policy — because they wreck efficiency numbers even when they ship the order.
6. 6Test the belief before continuing: ask 'productive with respect to what?' If the answer is 'to keep the machine busy' rather than 'the goal,' you have confirmed a Local Efficiency Focus, not genuine productivity.

Jonah tells Alex to forget the robots. Alex objects: 'They're some of our most expensive equipment. We absolutely have to keep them productive.' Jonah asks, 'Productive with respect to what?' — and Alex corrects himself to 'in terms of the goal,' but immediately relapses: 'I need high efficiencies to make those things pay for themselves, and I only get the efficiencies if they're making parts.' Jonah then lands the contradiction: Alex has already boasted his plant has very good efficiencies overall, so 'if your efficiencies are so good, then why is your plant in trouble?' The plant has quality products of current technology, all produced efficiently, and yet twenty million dollars of finished goods sit sealed in two warehouses waiting for someone to buy them. Activation was maximized; the goal was not served. That gap is the whole tell of Local Efficiency Focus.

• If a manager answers 'keep it productive' and cannot immediately say 'productive with respect to the goal,' then they are measuring activation, not utilization.
• If overall plant efficiencies are high but the plant is losing money or piling inventory, then the efficiency metric is local and misleading — stop trusting it.
• If the reason to run a machine is 'to make it pay for itself,' then you are loading it to protect a sunk cost, not to make money.
• If shipping an order requires breaking efficiency policy (overtime, stealing people, hand-carrying), and that felt like the only way to win, then your normal efficiency rules are working against throughput.
• If a proposal is rejected because 'economies of scale would disappear,' verify whether the scale actually helps the goal or only improves a per-employee ratio.

• Equating a busy machine with a profitable one. Tell: warehouses full of efficiently produced, unsold goods ($20 million) while the plant is 'on the critical list.'
• Managing to the month-end report instead of the goal. Tell: Alex knows Peach 'would be back here pounding on our heads at the end of the month if we didn't manage the plant for efficiency.'
• Treating exceptional throughput as an aberration to be corrected. Tell: after Donovan actually ships the order, Alex scolds him — 'we can't run the plant by the seat-of-the-pants' — and admits they'd do 'the same damn thing' next time anyway.
• Chasing capital utilization to recover cost. Tell: 'I have to keep them productive... I need high efficiencies to make those things pay for themselves.'
• Confusing many local goals (efficiency + quality + technology) for the goal. Tell: Alex ends up with a list of 'important goals' that 'really isn't saying anything.'

• ▸Resource name: which worker group or machine you are pushing to stay busy
• ▸Current metric: the exact efficiency number reported (e.g., parts per employee, % machine uptime)
• ▸Productive with respect to what?: state the goal this activity is supposed to serve
• ▸Goal linkage test: does running this resource increase sales/throughput now? yes/no
• ▸Inventory created: units or dollars produced that are not yet sold
• ▸Policy override cost: overtime, expediting, or robbed labor hidden to protect this metric
• ▸Sunk-cost trap check: are you running it mainly to 'pay for itself'? yes/no
• ▸Verdict: activation (busy but not serving goal) or utilization (busy and serving goal)

1. 1Map your production as a strict sequence of dependent events: identify which operation must finish before the next can start, from raw material release to the final ship point (the last operation is your throughput).
2. 2For each step, separate the two data types Jonah names: what you can count precisely (chairs/seating capacity) versus what varies instance to instance (time to make an omelet, time to bring the check). Flag every step whose cycle time only holds 'within a range.'
3. 3Stop treating fluctuations as if they average out. Test the assumption directly: watch whether the gap between the first operation and the last operation grows over time even when every step runs at the same average pace.
4. 4Note the asymmetry at each step: a step can slow or stop without limit, but it can only speed up until it 'bumps the rucksack' — it can go no faster than the step ahead of it releasing work. This caps upward fluctuation and lets downward fluctuation accumulate.
5. 5Quantify the accumulation by position: the first station makes up only its own slowness; each downstream station must make up its own fluctuation plus all the slowness accumulated ahead of it. The last operation carries the sum of everyone's slowness.
6. 6Read the growing gap as inventory: the trail (work) between the first station consuming raw material and the last station is inventory until it passes the final operation. A spreading line means rising inventory and lengthening lead time, not balance.
7. 7Refuse the 'balance capacity to demand' move. When capacity is trimmed exactly to market demand with no protection, throughput falls and inventory climbs — carrying cost (operational expense) then rises, defeating the reduction you expected.
8. 8Design against accumulation instead of averaging: put protective capacity at constraint steps and control release so upstream never dumps more work than the constraint can process (the milling-machine lesson: releasing material faster than the bottleneck absorbs it manufactures a new bottleneck).

On the hike, the troop 'produces walk trail': Ron at front consumes unwalked trail (raw material), each boy processes it in turn, and Alex at the back is the last operation — the rate he walks is throughput, and the trail between Ron and Alex is inventory. Everyone walks at about Ron's average pace, yet the column keeps spreading. The cause is exposed when Davey stops for a few seconds to adjust his packstraps: Ron walks on oblivious, a twenty-foot gap opens, and the whole line has now grown by twenty feet that no one downstream can easily close. Herbie only keeps his gap shut by expending extra energy in a constant walk-run routine — proof that going faster than average costs more and is limited, while slowing costs nothing and is unlimited. So the fluctuations do not cancel; slowness accumulates down the line because dependency caps the fast side. That is why Herbie must make up his own slowness plus everyone's ahead of him, and why Alex at the end carries the sum of all the excess space in the line.

• If a step's timing 'varies from one instance to the next' and only holds within a range, then treat it as a statistical fluctuation, not a fixed number — do not plan as if it will hit its average.
• If the gap between your first and last operation grows over time while every station runs at the same average pace, then you are watching accumulation, not averaging — stop waiting for it to even out.
• If you can slow/stop a step without limit but can only speed it up until it hits the pace of the step ahead, then upstream slowness will dominate; protect the downstream, don't rely on it catching up.
• If someone proposes trimming capacity exactly to market demand to cut operational expense, then expect throughput down and inventory (and its carrying cost) up — reject it unless you add protective capacity.
• If you find excess inventory piled behind a resource, then it is being fed faster than it can process (like the milling machines Alex 'turned into' a bottleneck), not intrinsically short of capacity.

• Assuming fluctuations average out over time. The tell: 'the fluctuations should be averaging out' — yet the column keeps lengthening while everyone walks Ron's pace.
• Believing 'a couple extra eggs' covers variation. The tell: you plan to the average and get caught when the chef 'drops one on the floor' — small unpredictables you can't precisely pre-determine.
• Balancing capacity to demand to hit the operational-expense target. The tell: throughput falls and inventory 'goes through the roof,' raising carrying cost so you can't even deliver the OE reduction you promised.
• Releasing work whenever a non-bottleneck runs out of things to do. The tell: green-tagged parts pile up and clog a work center like the milling machines — you 'turned them into' a bottleneck that wasn't intrinsically one.
• Trying to optimize every resource locally. The tell: 'a system of local optimums is not an optimum system at all' — each station busy, yet inventory grows and throughput stalls.

• ▸Step name & sequence position: list each operation in order, first (raw-material consumer) to last (throughput point).
• ▸Precise vs. fluctuating: mark whether this step's cycle time is countable-exact or varies within a range.
• ▸Fluctuation range: record observed fastest and slowest actuals (e.g., check took 2:00 last time, 5:42 before).
• ▸Upside limit: note what caps this step's speed-up (it can go no faster than the step feeding it).
• ▸Downside exposure: note that this step can slow/stop without limit — flag its impact on everyone behind it.
• ▸Accumulated slowness carried: own fluctuation + sum of all fluctuations upstream that this step must make up.
• ▸Inventory between this step and the last: measure the growing gap (work waiting) as it lengthens over time.
• ▸Protective capacity in place: yes/no — is there slack here to absorb upstream accumulation?
• ▸Release control check: is work fed to this step only at the rate it (or the constraint) can process, not whenever an upstream station runs dry?