The build gets attention. The question that decides whether it survives gets asked after something breaks.
The four roles
Owner. Accountable for the outcome the automation exists to produce. Not the tool, the outcome. Usually whoever owns the number it affects.
Operator. Runs it day to day. Handles exceptions, spots the records that look wrong, knows what normal looks like.
Maintainer. Fixes it when something upstream changes: an API version, a field rename, a permission change. Needs access and the ability to deploy a fix without a committee.
Approver. Signs off changes. An automation everyone can edit is one nobody can trust, and change control here is not bureaucracy, it is how you avoid a silent behaviour change three weeks before quarter end.
In most companies all four are silently the person who built it. That works until they are on holiday and stops working permanently when they leave.
The test that takes thirty seconds
Ask: who would notice if this stopped working today?
If the answer is nobody, you do not have an owner. You have a liability that currently happens to be running.
Why automations decay even when nothing breaks
Three forces, all invisible:
The business changes around it. The offer shifts, a stage is redefined, a team reorganises. The automation keeps doing what it was told in a world that has moved.
Upstream systems change. APIs version, fields get renamed, a platform updates its behaviour. This is the one that produces the 2pm emergency.
The definition of done was never written. If nobody can say what correct output looks like, nobody can tell that it stopped producing it.
What has to exist at handover
- A runbook that someone other than the builder has followed successfully. Untested documentation is a wish.
- Access that does not depend on one person's accounts
- An error route and an alert that reaches a human with enough context to act
- Monitoring that alerts on absence. A flow that stops running produces no errors, which is why silent decay is the normal failure
- The list of upstream dependencies, so a platform change has an obvious owner
- A review date
For work done by contractors
The handover plan is part of the engagement or you are buying a dependency with a friendly face.
Minimum bar: a runbook an internal person has followed, a named internal owner from day one, and credentials that survive the contract ending. Anyone unwilling to work that way is telling you something about the rest of the relationship.
The review that prevents most of this
Once a quarter, per automation: is it still running, is it still producing the outcome, has anything upstream changed, is the owner still the owner, and does the runbook still match reality.
An hour per quarter. It is the difference between a system and a collection of things that used to work.