Methodology
We simplify a process before automating it, automate the stable core rather than every exception, and decide the failure path during design. Automating a process nobody has simplified preserves every unnecessary step.
Mapping comes first, and it is observed rather than described.
The documented process and the real one differ in almost every organisation, and the difference is usually where the cost sits. It is also where the disagreements surface: two people describing the same process differently is a problem to resolve before any build.
Simplification follows, and it frequently returns more than the automation does. Steps that exist for reasons that no longer apply can be removed outright, which is cheaper than making them faster and leaves less to maintain.
We automate the stable core and route exceptions to a person with the full context attached. Chasing complete coverage is where cost and fragility escalate sharply, and the last few percent of cases are usually the ones that most need judgement.
The failure path is designed, not discovered. What happens when input is unrecognised, a system is unavailable or confidence is low is a business decision, and deciding it during design is far cheaper than learning the default behaviour during an incident.
Every automation gets a named owner and a maintenance expectation, because integrations break when systems change and credentials rotate. Automations without an owner quietly stop working.
We simplify a process before automating it, automate the stable core rather than every exception, and decide the failure path during design. Automating a process nobody has simplified preserves every unnecessary step.
Everything above is how we say we work. Thirty minutes on a real problem is the fastest way to find out whether it is also how we behave — and it costs you nothing to check.
