Eliminate first, simplify second, automate last — never automate waste or complexity
Follow the automation hierarchy of eliminate-simplify-automate in strict order, because automating waste entrenches it and automating complexity makes it brittle.
Why This Is a Rule
The automation hierarchy — eliminate → simplify → automate — must be followed in strict order because each step is prerequisite to the next. Automating a wasteful step entrenches waste: the step now happens faster and more consistently, making it harder to question and remove. Automating a complex process makes it brittle: the automation encodes current complexity into rigid logic that breaks when conditions change.
Eliminate first: does this step need to exist at all? Many process steps were added for historical reasons that no longer apply (see If an approval step changed nothing in 20 instances, eliminate it as waste). If the step can be removed entirely, no simplification or automation is needed.
Simplify second: if the step must exist, can it be made simpler? Fewer inputs, fewer branches, fewer dependencies? Simplification reduces the surface area that automation must cover.
Automate last: only after elimination and simplification should you automate what remains. The automated version should be as simple as possible, operating on the simplest possible process.
This is Ford's assembly line principle applied to knowledge work: Ford didn't automate the existing craft-shop process. He eliminated unnecessary steps, simplified the remaining ones, then automated the simplified flow.
When This Fires
- Planning any automation project — scripts, workflows, integrations
- When someone suggests "let's automate this" as a first response
- During process improvement when deciding what to do about a repetitive task
- Any time the impulse to automate arises before the impulse to simplify
Common Failure Mode
Jumping straight to automate because it's the most exciting step. You build a complex automation for a process that shouldn't exist — now the waste is automated, running faithfully every day, and questioning it feels like questioning a significant investment. "We spent two weeks building this automation, we can't just turn it off." The automation becomes a sunk-cost anchor that prevents the elimination step that should have happened first.
The Protocol
Before any automation effort: (1) Eliminate: list every step in the process. For each, ask: "If we removed this entirely, what would break?" If nothing → eliminate. (2) Simplify: for remaining steps, ask: "Can this be made simpler — fewer inputs, fewer branches, fewer dependencies?" Simplify before encoding. (3) Automate: only the simplified, necessary steps. The automation should be simple because the underlying process is simple. If the automation script is complex, the process probably wasn't simplified enough.