When not to automate a process
Automating a broken process makes it faster and harder to fix. Three tests we apply before writing a pipeline.
Sofia Ferreira
Delivery Lead
The first question in an automation project is not how, it is whether. Cementing a bad process in code costs more than the manual version, because now changing it requires an engineer.
Test one: does the process still exist for a reason? We find steps that were introduced for a system retired years ago and never removed.
Test two: is the judgement in the step real? Approvals that always approve should be deleted, not automated. Approvals that genuinely gate risk should stay human.
Test three: can the step be run twice safely? If not, that is the work — idempotency before automation, or every retry becomes a duplicate record.