Key takeaways
- Automation fails early when the team encodes an unstable or disputed process.
- Happy-path demos hide the exception volume and consequence that dominate production.
- A tool without an owner, monitoring, and a manual fallback is already a future incident.
- Broad permissions and ambiguous success states make failures harder to contain and prove.
- Use real acceptance and failure cases, then release gradually with a repair path.
Automation projects fail when they encode an unstable process, optimize a visible click instead of the end-to-end job, ignore exceptions, grant unsafe authority, cannot verify external effects, or launch without ownership, monitoring, fallback, and a change path. Run a pre-mortem before building: assume the tool failed six months later, then identify the process, data, control, dependency, reliability, adoption, and ownership conditions that caused it.
Assume the project failed, then make the causes testable
The internal-tool lifecycle is wider than its interface. A pre-mortem uses that scope while changes are still cheap. Ask each participant to write a specific future failure independently, then group the answers by condition rather than debating whose forecast is most likely.
“Six months after launch, the supplier-approval tool is bypassed. Reviewers stopped trusting its summaries after two stale-data cases. A field change broke one integration silently, the original builder moved teams, and nobody owned the exception queue. People returned to email, but the scheduled workflow kept creating incomplete records.” Each sentence can become a requirement, test, metric, or owner.
Use seven failure families
| Failure family | Early warning | Design response |
|---|---|---|
| Process | Operators disagree on normal path or finish state | Observe work and resolve policy before build |
| Data | Inputs are stale, missing, duplicated, or lack a source owner | Define sources, freshness, validation, missing-data path, and business keys |
| Exceptions | Demo uses only clean cases | Test recent awkward cases and create owned exception states |
| Authority | Shared broad credentials or unclear approval effect | Least privilege, default deny, explicit gates, and evidence |
| Reliability | Success means a function returned | Verify business postconditions, monitor, reconcile, recover, and fall back |
| Adoption | Users cannot correct, explain, or trust the result | Design with operators; expose state, evidence, feedback, and correction |
| Ownership | The builder is the only responder | Name service, decision, security, change, support, and retirement owners |
Automation multiplies the direction it is given
Google's automation chapter calls automation a force multiplier rather than a panacea. A correct stable process gains speed and consistency. A wrong rule, broad permission, or unverified side effect gains reach.
The first release should therefore minimize blast radius: narrow users and data, draft or reversible actions, rate limits, approval before consequence, and an active manual fallback.
Convert each predicted failure into a release test
- 01Make the condition observableTriggerDefine a metric or evidence signal for stale input, exception backlog, denied access, duplicate effect, correction, or fallback activation.
- 02Create a representative caseHuman approvalUse a sanitized real example with expected state, effect, evidence, and owner.
- 03Exercise the controlCodeProve validation, gating, containment, reconciliation, rollback, compensation, or escalation behaves as specified.
- 04Assign the responseHuman approvalName who receives the signal, expected action, clock, and backup.
- 05Retain the caseCodeAdd corrected production failures to the regression set and rerun them before changed behavior ships.
Release when the team can operate a wrong run
- A named owner can explain current behavior, authority, dependencies, and users.
- Normal, boundary, exception, duplicate, stale, denied, timeout, and recovery cases pass.
- A wrong or ambiguous external effect stops, preserves evidence, and has an owned reconciliation path.
- Users know the scope, limitations, correction path, and manual fallback.
- Monitoring measures business outcomes and failure effects, not only technical uptime.
- Changes are versioned, regression-tested, approved, communicated, and reversible where feasible.
Limitations and when not to use this
- A pre-mortem surfaces plausible risks; it cannot identify every failure or replace security, privacy, legal, or domain review.
- The simulated example is illustrative and is not a customer result or product capability claim.
- Do not use gradual rollout to experiment with unacceptable harm. Some actions require controls and qualified approval before any live exposure.
Sources
- The Evolution of Automation at Google — Google Site Reliability Engineering Accessed 14 August 2026
- Testing for Reliability — Google Site Reliability Engineering Accessed 14 August 2026
- Secure Software Development Framework 1.1 — NIST Accessed 14 August 2026
Assess the riskiest action
Score the action whose incorrect execution would be hardest to detect, reverse, or contain, then design its control.
Assess the riskiest actionUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.