Delete first, simplify second, and never the other way round

Most engineering failure is doing the five steps out of order. The expensive version is optimising something that should not have existed.

There is a well-known five-step engineering discipline: question every requirement, delete what you can, simplify what survives, accelerate cycle time, automate last. Everyone nods at it. Almost nobody runs it in order.

The out-of-order failure is specific and it looks like competence. You take a process, you make it faster, you automate the fast version, and you ship something that does the wrong work beautifully. Every individual step was executed well. The sequence was wrong, and the sequence is the entire content of the idea.

Deletion is the only optimisation that cannot regress

Every other kind of improvement adds surface. A cache is a correctness risk. A faster path is a second path. An abstraction is a thing to learn. Deletion is the one move where the result is strictly smaller than what you started with, which means it is the one move that cannot come back as a bug in eighteen months.

The corollary is the uncomfortable part: if nothing you deleted has to be put back, you did not delete enough. A deletion pass that produces zero regret is a deletion pass that only removed things nobody was using. The useful pass removes things that were being used, by someone, a little — and then you find out whether "a little" was load-bearing.

We do this on every product surface before it ships. Not as a cleanup phase at the end, which is when deletion is politically hardest, but before the simplification work starts, when nothing is precious yet.

Requirements arrive attached to a name

The first step is the one people skip hardest, because questioning a requirement means questioning whoever wrote it, and usually that person is senior and reasonable and right about most things.

The check we use is small: who asked for this, and what did they think it would do? A requirement with no name attached is a requirement nobody owns, which means nobody will notice when it stops being true. A requirement with a name attached can be taken back to that person, and roughly half the time the answer is "oh — I meant something else."

That number is not a criticism of anyone. It is what happens when a need gets compressed into a sentence and then travels.

Automation multiplies whatever it is pointed at

The last step is last for a reason that is easy to state and hard to feel: automation does not evaluate what it automates. Point it at a lean process and you get leverage. Point it at a mess and you get a mess that runs without supervision, at volume, with nobody left who remembers why any of the steps are there.

This is the failure mode we see most often in the problems our products address. Commission runs are a spreadsheet somebody automated. Sourcing pipelines are a manual process somebody scripted. In both cases the automation worked exactly as designed, and in both cases the design encoded assumptions that nobody had questioned since the process was manual and small.

The order exists to stop that. Ask what it is for. Remove what it does not need. Simplify what is left. Then go fast. Then, only then, let the machine have it.