Improve in the Right Order
Most teams improve systems backwards. Question the requirements, delete what should not exist, then simplify, accelerate, and automate only what remains.
First, make your requirements less dumb. Your requirements are definitely dumb. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough. - Elon Musk
- Make the requirements less dumb. Requirements are assumptions, not truth.
- Delete the part or process before improving it. The best part is no part, and the best process is no process.
- Simplify or optimize only after the unnecessary work has been removed.
- Accelerate cycle time only after the work is clearly worth doing.
- Automate last. Automation makes bad processes faster, more expensive, and harder to remove.
The common failure mode is doing the steps backwards: automate a process, accelerate the automation, optimize the workflow, then only later ask whether the requirement made sense or whether the process should exist at all. That order wastes effort by making bad work faster, cleaner, and harder to remove.