Published on LinkedIn May 25, 2026
Organizations have been automating delivery processes at an accelerating pace. Most are automating the wrong things.
The instinct is understandable. Technology promises speed, consistency, and reduced overhead. When a process is slow or error-prone, automation appears to be the logical solution. What that reasoning skips is the question of whether the process itself is sound. Efficiency applied to a flawed process does not fix the flaw. It accelerates it and scales the cost.
This is one of the most expensive patterns in modern delivery environments, and it is almost entirely avoidable.
The automation error starts with a misdiagnosis. When delivery is slow or inconsistent, organizations frequently identify the symptom as the problem. The approval takes too long. The handoff keeps breaking. The intake process creates backlogs. The response is to build automation around the symptom rather than examine the underlying design. The automated version of a broken process runs faster, fails more consistently, and is considerably harder to fix because the automation layer now has to be unwound alongside the process it was built around.
Taiichi Ohno made this argument directly in the Toyota Production System, published in 1978. His position was that organizations must understand and stabilize a process before they improve it. Improvement applied to an unstable process does not produce stability. It produces faster instability. Ohno’s framework was built around manufacturing operations, but the principle applies directly to how organizations design and automate delivery processes. You cannot improve what you have not yet understood.
I have seen this in portfolio environments where intake automation was built before the intake criteria were defined. The automation ran efficiently. It processed requests at pace. It also moved the wrong work forward consistently, because the logic of what should be approved and what should not was never resolved before the system was designed around it. The speed of the automated process made the misalignment harder to catch and more expensive to correct.
The diagnostic question is straightforward: what decision does this process exist to support?
If the team designing the automation cannot answer that question clearly, the process is not ready to be automated. It is ready to be examined. What outcome is this process supposed to produce? Who makes the decision it supports? What information does that decision require? What happens downstream when the process produces the wrong output?
These are not technical questions. They are design questions that need to be resolved before any efficiency discussion begins. Organizations that skip them tend to invest heavily in automation and then discover that the automated process produces outputs that require manual correction, eliminating the efficiency gains and adding a layer of complexity that did not exist before.
First principles thinking in a delivery context means working backward from the decision before designing the process. What does a senior leader, a delivery team, or a governance body need to know or approve, and why? What is the minimum viable process that produces that output reliably? Where does human judgment need to remain in the loop regardless of what automation handles?
That sequence is slower at the front end. It is considerably faster across the full delivery cycle because it removes the rework that follows from automating before understanding.
The organizations that do this well treat process design and process automation as two distinct phases with a deliberate gap between them. The design phase establishes what the process needs to do and confirms it is doing that reliably. The automation phase builds efficiency around a stable foundation. The gap between those phases is where the most important work happens, and it is the phase most organizations skip entirely under pressure to move faster.
Efficiency is a multiplier. It scales whatever it is applied to. When the underlying process is sound, automation accelerates value. When the underlying process is flawed, automation accelerates the cost of the flaw. The question before any automation investment is not whether the technology is capable. It is whether the process it will run was designed to support the right decision in the first place.
If that question cannot be answered clearly before the build begins, the speed gained will not be worth the correction work that follows.
Strategic Signals publishes monthly on strategy systems and execution clarity for senior leaders. Subscribe to receive each issue directly. Subscribe
If this piece resonated, ALIGN: The Leadership Framework for Clarity in Complex Organizations is available on Amazon. Click Here
