RFD 0010 · The Goal and Atoms are Cheap, Process is Pricey

Summary

This RFD connects two related operating ideas:

The Goal: doing work and making money are not the same thing. A system should be judged by whether it improves the goal, not by whether every local activity looks busy.
Atoms are cheap, process is pricey: in many engineering organizations, the expensive part is not the physical material. The expensive part is the slow, brittle, over-coordinated process that makes every change costly.

The combined determination is that a high-performing engineering system should optimize for throughput of validated learning and useful output, not for local utilization, ceremonial planning, or perfectly protected intermediate work.

In practice, this means:

identify the real system goal,
find the constraint that governs throughput,
protect the constraint from bad inputs and wasted work,
subordinate surrounding work to the constraint,
use high-volume iteration to turn uncertainty into data,
prefer process designs where failed attempts are cheap, fast, and informative.

Context

This RFD is grounded in two source texts:

James Clear's summary of the book The Goal by Eliyahu Goldratt
Max Olson's "Atoms are Cheap, Process is Pricey"

The first captures lessons from Eliyahu Goldratt's The Goal and the Theory of Constraints. The second captures Olson's framing of SpaceX-style iteration: physical materials can be comparatively cheap, while slow process, supplier waiting, rigid review loops, and low-volume production can make learning expensive.

The useful overlap is not merely that both ideas admire speed. The deeper overlap is that both reject local efficiency as the main thing to optimize. A factory full of busy stations can still fail if the bottleneck is starved, blocked, or fed bad work. An engineering organization full of careful plans can still fail if the process makes each real-world test too expensive to run.

Problem

Most organizations are tempted to optimize visible activity:

every person should look utilized,
every function should improve its own metrics,
every review should reduce local risk,
every prototype should be protected from failure,
every plan should feel complete before action begins.

Those instincts can produce the opposite of a good system. They can increase inventory, hide constraints, delay feedback, and make the cost of learning so high that the organization stops learning quickly enough.

The central problem is confusing work with throughput.

A system can be busy while not advancing the goal. A team can be productive locally while damaging global flow. A process can feel disciplined while converting cheap uncertainty into expensive delay.

The Goal: global throughput beats local utilization

The Goal argues that the relevant question is not whether each part of a system is busy. The relevant question is whether the system is improving the goal.

In a business setting, Goldratt frames the goal through measures such as:

net profit,
return on investment,
cash flow,
throughput,
inventory,
operational expense.

The Goal definitions: throughput, inventory, and operational expense

Goldratt defines the three operational measures this way:

Throughput: "the rate at which the system generates money through sales."
Inventory: "all the money that the system has invested in purchasing things which it intends to sell."
Operational expense: "all the money the system spends in order to turn inventory into throughput."

The important simplification is that everything in the system can fit into these three definitions: it is either generating throughput through sales, sitting in inventory, or consuming operational expense to turn inventory into throughput.

The precise measures vary by domain, but the operating lesson generalizes: a system should be managed as a system.

Important implications:

A non-bottleneck's capacity is governed by the rest of the system, not by its own theoretical maximum.
Activating a resource and using a resource well are not the same thing.
Inventory tends to accumulate in front of constraints.
Quality should be checked before the bottleneck, because bottleneck time is too valuable to spend on bad inputs.
The goal is not to maximize every local station. The goal is to improve global throughput.

Bottleneck time is priced by lost throughput

A minute lost at the bottleneck should not be priced like a minute of local machine operating expense. If the bottleneck governs how much the whole system can sell, then a minute when it is idle, blocked, reworking bad inputs, or working on non-bottleneck orders is a minute of delayed or lost throughput for the entire system.

The cost of that minute is therefore closer to the prorated value of sales the system cannot make while the bottleneck is not producing bottleneck-governed orders. The local labor rate, depreciation, electricity, or machine burden may be visible accounting cost, but it understates the system cost. The real economic penalty is the throughput not generated because the constraint was unavailable for the work that determines sales.

This is why constraint protection matters so much:

bad parts should be caught before they consume bottleneck capacity,
expediting should focus on orders that actually pass through the constraint,
non-bottleneck utilization should not steal time, attention, fixtures, or inputs from the bottleneck,
a bottleneck working on the wrong order can be almost as costly as a bottleneck sitting idle.

Red and green tags make the constraint visible

In The Goal, the plant uses simple visual tags to make constraint priority visible on the floor. The point is not tag ceremony. The point is to prevent local dispatching decisions from accidentally starving or wasting the bottleneck.

A practical tagging model looks like this:

Red tags identify parts that must go through a bottleneck machine.
Green tags identify parts that do not require the bottleneck.
Each tag carries a priority number within its color.
The lowest number has the highest priority inside that color; 1 should run before 2, 2 before 3, and so on.

The color determines the dispatch class, and the number determines the order within that class. A red-tagged order with a low number should usually preempt green-tagged work because it protects throughput at the system constraint. Green work still matters, but it should not consume shared attention, staging space, fixtures, or follow-on capacity in a way that delays bottleneck-bound material.

This tagging scheme also makes inventory more honest. A pile of red-tagged work waiting before the constraint is not just generic WIP. It is a queue of future sales waiting for bottleneck capacity. A pile of green-tagged work may be locally easy to process, but completing it first can make the plant look busy while the real system goal waits.

Yellow stickers mark post-bottleneck urgency

Once red-tagged parts have passed all bottlenecks, they should not disappear back into ordinary priority rules. At that point the constraint has already spent its scarce time on them, and the remaining final operations are the last steps needed to convert that protected bottleneck work into sales.

A yellow sticker on the red tag can mark this state:

the part was bottleneck-bound,
it has cleared all bottlenecks,
it is ready for final downstream operations,
finishing it quickly converts already-protected bottleneck output into throughput.

The yellow sticker changes the question from "should this get bottleneck time?" to "how quickly can we finish and ship what the bottleneck already made possible?" Without that post-bottleneck signal, parts can clear the constraint and then stall in final operations, turning precious bottleneck time back into delayed sales.

This is the Theory of Constraints in practical form:

identify the system constraint,
decide how to exploit the constraint,
subordinate other work to that decision,
elevate the constraint,
repeat when the constraint moves.

Atoms are cheap, process is pricey

The phrase "atoms are cheap, process is pricey" captures a complementary lesson from fast hardware organizations.

The expensive thing is often not the raw material. The expensive thing is a process that makes every physical attempt slow, fragile, over-planned, and politically costly.

A high-iteration organization makes physical experiments cheaper by changing the surrounding process:

produce many articles instead of protecting one perfect article,
test in the real world earlier,
expect failures to generate data,
reduce supplier and handoff latency,
vertically integrate when external coordination dominates cycle time,
make design changes flow into manufacturing quickly,
increase build volume so each individual failure is less precious.

The practical claim is not that atoms have no cost. The claim is that process cost often dominates material cost once process becomes slow enough. A cheap part can become expensive if it waits weeks for approval, months for a supplier, or years for a program milestone.

Combined operating model

The useful synthesis is:

Optimize the whole system for throughput of validated learning and useful output.

That requires both constraint thinking and cheap-iteration process design.

1. Name the actual goal

Before optimizing anything, state what the system is for.

Examples:

ship a reliable product,
increase validated learning per week,
reduce customer-visible defects,
improve gross throughput through a factory,
discover whether a design approach works,
reduce time from idea to field evidence.

Without a named goal, teams default to surrogate goals: utilization, ticket count, meeting completion, local cycle time, or artifact polish.

2. Find the governing constraint

Ask where throughput actually gets limited.

Common constraints include:

test capacity,
manufacturing cycle time,
review availability,
deployment friction,
supplier lead time,
decision latency,
quality escapes that force rework,
lack of realistic fixtures or real-world feedback.

The visible bottleneck is often where inventory accumulates. For knowledge work, inventory may look like stale pull requests, unreviewed designs, untested prototypes, blocked decisions, or long queues of "almost done" work.

3. Protect the constraint

Constraint time should not be wasted on preventable bad inputs.

In a manufacturing system, that means quality checks before the bottleneck. In a software or engineering process, it may mean:

better pre-review checks,
smaller changes,
clearer acceptance criteria,
realistic test fixtures,
earlier failure detection,
fewer speculative handoffs,
not sending half-formed work into scarce expert review.

This is not bureaucracy for its own sake. It is constraint protection.

4. Subordinate surrounding work

Once the constraint is identified, surrounding work should serve it.

That may mean non-bottleneck teams deliberately do less local optimization. It may mean accepting idle time in one place to reduce queueing at the constraint. It may mean sequencing work so the slowest resource receives the right inputs at the right time.

The system is not healthier merely because everyone is busy. The system is healthier when the constraint is continuously fed useful work and the overall goal improves.

5. Make iteration cheap enough to be real

If every attempt is expensive, the organization will pretend to learn through planning. If attempts are cheap, the organization can learn through reality.

Cheap iteration requires process design:

fast build paths,
fast test paths,
low-friction review,
reversible decisions where possible,
smaller batch sizes,
high-volume prototypes or deploys,
tight connection between design and execution,
explicit tolerance for informative failure.

The key is not reckless failure. The key is bounded failure with high information value.

Anti-patterns

Local maximums

A local maximum appears when a subsystem improves its own score while the total system gets worse.

Examples:

engineering maximizes code output while review becomes the bottleneck,
manufacturing maximizes station utilization while inventory piles up,
management maximizes planning confidence while real-world feedback slows down,
quality gates catch issues too late and consume bottleneck time,
procurement minimizes unit cost while lead time dominates learning cost.

Perfect prototype culture

When each prototype is treated as precious, failure becomes politically and financially expensive. That encourages teams to over-plan, under-test, and preserve uncertainty longer than necessary.

A better system asks: how can we make the next attempt cheap enough that testing it is the obvious move?

Busy-work accounting

Counting activity can obscure whether the goal is improving.

Useful questions are:

Did throughput increase?
Did inventory decrease?
Did operational expense decrease without damaging throughput?
Did cycle time to validated learning improve?
Did bottleneck time get protected?
Did the organization learn something real that changes the next decision?

Application to personal and engineering workflows

This RFD is not only about factories or rockets. It is also a useful lens for personal systems, software projects, hardware projects, and agent-assisted engineering.

Practical applications:

Keep work in small batches so review and test constraints do not clog.
Prefer real fixtures and real feedback over abstract confidence.
Design processes where a failed attempt leaves useful evidence.
Do not optimize for the agent, tool, or person looking busy.
Identify the scarce expert or scarce test path and protect it.
Reduce handoff latency between idea, implementation, verification, and decision.
When a process feels expensive, ask whether the atoms are actually costly or whether the surrounding process made them costly.

For agent-assisted work, the bottleneck may not be code generation. It may be verification, realistic fixtures, repo hygiene, review quality, or the human decision loop. If so, adding more generation capacity makes the system worse unless the downstream constraint is protected and elevated.

Determination

The adopted framing is:

Optimize for the system goal, not visible local activity.
Treat constraints as first-class design objects.
Protect bottleneck time from bad inputs and avoidable rework.
Use iteration as data collection, not as vague motion.
Make attempts cheap enough that reality can be consulted frequently.
Prefer process designs that increase validated learning per unit time.
Be suspicious of any process where cheap atoms become expensive because every attempt is trapped behind slow coordination.

Open questions

What metrics best capture validated learning in personal projects?
How should this RFD map onto the RFD repo's own authoring and review process?
Which existing workflows have the most obvious inventory pileups?
Where is the current bottleneck in agent-assisted ECAD review work: generation, fixtures, verification, or human judgment?
What would it mean to increase build/test volume in a way that stays safe and useful?

References

James Clear's summary of the book The Goal by Eliyahu Goldratt
Max Olson: Atoms are Cheap, Process is Pricey
Founders Podcast #414: How SpaceX Works