What to automate first, and what to leave alone
Rank candidate automations by the cost of being wrong, not by the time they save. The ordering that produces is unintuitive and it is the one that survives.
Ask a room of engineering leaders which part of the status-keeping problem they would automate first and you get the same answer almost every time: the reporting. The weekly status roll-up, the executive summary, the thing that eats a day of someone’s week and that everyone resents.
It is the worst possible place to start, and the reason is instructive.
A generated status report is read by people who cannot verify it. That is the entire problem. A director reading a summary of forty tickets across six teams has no independent way to know whether the summary is right, so an error does not get caught, it gets acted upon. And the blast radius is large: a wrong report reallocates people, moves dates, changes what gets funded. Meanwhile the feedback loop is nearly nonexistent, because if the report is wrong nobody discovers it for weeks.
Compare that to automatically linking a pull request to a ticket. Tiny time saving. Enormously better properties: the person who sees it is the person who made the change, so a wrong link is caught in seconds, and the fix is a click. Nothing downstream breaks.
That comparison contains the whole framework. Rank by the cost of being wrong, not by the time saved. Time saved is what you optimise once you have earned the right to.
The generated status report
- Largest visible time saving
- Read by people who cannot verify it
- Errors discovered late or never
- Feeds decisions three levels up
- The worst possible place to start
Linking a change to a ticket
- Tiny time saving
- Seen by the person who made the change
- A wrong link is obvious immediately
- Nothing downstream depends on it yet
- One click to correct
The four questions
For any candidate automation, ask these in order. They take about a minute per candidate and they produce a defensible ordering.
One: who sees the output, and can they tell if it is wrong? An action a developer sees on their own ticket is self-checking. An action that surfaces three levels up in a rollup is not. Prefer automations whose output lands in front of someone with the context to catch an error.
Two: how long until an error is discovered? Seconds, days or never. This is the single strongest predictor of whether an automation is safe to enable early, and it is almost uncorrelated with how much labour it saves.
Three: what happens downstream if it is wrong? Does anything read this and act? A wrong evidence comment is noise. A wrong done transition on an epic feeds a portfolio report that feeds a planning decision. Chains matter more than individual actions.
Four: how hard is it to undo? Not just technically reversible, but reversible in practice. Restoring a prior ticket status is trivial if the system captured the old value. Un-sending a notification to forty people is not possible at all. This is why anything that emits a message to humans outside the team belongs much later in the order than its risk profile otherwise suggests.
The order I would actually use
Applying those questions consistently produces roughly this sequence. The tiers matter more than the exact positions.
Tier one: enable in week one
Linking changes to tickets. Associating a branch or pull request with the ticket it implements. Self-checking, instantly visible, trivially correctable, and it is the substrate everything else depends on. If your linking rate is poor, this is also the highest-value single automation available to you, because unlinked work is invisible work.
Posting evidence onto the ticket. The commits, the branch, the review state, who approved, when it merged. Purely additive: it adds information without changing state. The worst realistic failure is clutter. And it does something politically valuable that is easy to miss, which is that it makes the automation’s reasoning visible before the automation is trusted with anything consequential. People watch the evidence accumulate and form a view about whether the system understands their work.
Flagging drift without fixing it. Surfacing “this ticket says in progress but its pull request merged four days ago” as a notification rather than an action. This is the polite middle ground between shadow mode and live writes, and it converts the automation into an advisor whose suggestions a human accepts. Some teams stay here for a month and it is not a bad place to sit.
Tier two: enable once tier one is boring
Forward status transitions. In progress to in review when a review opens. In review to done when the change merges and criteria pass. This is where the actual labour saving lives, which is exactly why it is not first. Errors are visible to the developer, reversible if the prior value is captured, and bounded in blast radius as long as nothing further up the chain moves automatically.
Two conditions before you enable this. Your definition of done for that team must actually correspond to merge, or you must have encoded whatever out-of-band step sits between them. And the prior value must be captured on every write, so that a wrong transition is a revert rather than an archaeology exercise.
Standup and cycle summaries scoped to the team itself. A digest of what actually moved, read by the people who did the moving. They can spot an error instantly, which is what distinguishes this from the executive report. Same underlying capability, radically different risk profile, purely because of who the audience is.
Tier three: enable much later, with a human in the loop
Backward transitions. Moving a ticket out of done because the change was reverted, or reopening on a failed criterion. Correct in principle, and considerably more upsetting in practice: a ticket that un-completes itself feels like the system taking something away, and the emotional response is out of proportion to the actual disruption. Introduce it as a suggestion first and let people accept it manually for a while.
Anything that gates a merge. Blocking on unmet criteria, missing links, absent tests. The moment automation can stop a person from shipping, its error budget collapses to near zero, because one bad block during an incident undoes a quarter of goodwill. If you do this at all, ship an override from day one, make using the override a normal and unpunished act, and review override usage as a signal about your criteria rather than as a compliance problem.
Epic and initiative rollups. These aggregate, and aggregation launders errors. One wrong child status becomes a wrong parent status becomes a wrong programme view, and by the third hop nobody can trace where it came from. Aggregate only from a base you have already verified for months.
Tier four: I would leave these alone
Some things I would not automate, or would automate only under conditions strict enough that most teams should not bother.
Priority changes. Priority is a human judgement about tradeoffs under scarcity. Inferring it from activity confuses what is being worked on with what matters. If your system starts adjusting priority because a ticket got busy, you have built a machine that promotes whatever is loudest.
Estimates. Same category. An estimate is a commitment made under uncertainty, and automating it converts it into a prediction, at which point it stops functioning as a planning tool and starts functioning as a target people are measured against.
Closing tickets nobody has touched in ninety days. Enormously tempting, since the stale-ticket backlog is genuinely a problem. But the cost of wrongly closing the one thing that mattered is high and it is silent: nobody notices a ticket that quietly disappeared until the customer asks. Archive rather than close, and make it a batch a human confirms.
Anything that messages people outside the team. Not because the inference is worse, but because the undo does not exist. A wrong status on a board is a two-second fix. A wrong automated update in a customer-facing channel or a stakeholder digest is a conversation, and possibly several.
Assignment. Automatically assigning work based on who touched a file last is a plausible heuristic that produces terrible outcomes: it concentrates work on whoever is already overloaded, it entrenches knowledge silos, and it removes a decision a team lead should be making deliberately.
The pattern underneath the list
Two generalisations are doing most of the work here.
Recording is safer than deciding. Automations that say “this happened” are fundamentally lower risk than automations that say “therefore this is true.” The first can be checked against reality by anyone. The second embeds a judgement, and judgements compound. Almost every entry in tier one is a recording action and almost every entry in tier four is a deciding action.
Audience determines risk more than accuracy does. The same summary generation capability is safe for a team digest and dangerous for an executive report, at identical accuracy, purely because of who reads it and whether they can tell it is wrong. When you evaluate a new automation, look at the audience before you look at the mechanism.
A practical note on thresholds per action
One thing worth doing that most teams miss: the confidence threshold does not have to be global.
Linking can run at a much lower threshold than status transitions, because a wrong link is cheap. Transitions on the well-understood service can run lower than transitions on the legacy module where the tests are thin. If your tooling supports per-action or per-path thresholds, use them, because a single global number forces you to set it for your riskiest action and therefore to route far too much of your safe work into the human queue. That queue is a finite resource. Spend it where judgement is actually needed.
Where this breaks down
The ranking framework has real weaknesses and here are the ones I would want a reader to hold onto.
Starting with the cheapest actions can mean starting with actions nobody values. Linking and evidence comments are safe precisely because they are low stakes, and low stakes sometimes means low perceived benefit. If you spend six weeks on tier one and a stakeholder asks what changed, “our pull requests are linked to tickets now” is a hard sell. The counter is to pair the safety ordering with an honest expectation set at the start: tier one is about establishing trust and building the substrate, and the labour saving arrives in tier two. If you cannot get the political room for that, you may need to reach tier two faster than this article suggests, and you should compensate with a higher threshold rather than by skipping the trust-building.
“Cost of being wrong” is not always knowable in advance. Some automations turn out to feed a process nobody documented. The ticket field you thought was decorative is read by a monthly billing job. The label you started applying automatically drives a downstream integration somebody built two years ago. You cannot enumerate these from a whiteboard. Shadow mode helps but does not fully solve it, since shadow mode shows you what would change, not who reads it. The mitigation is to ask, for each field you will write to, who consumes this, and to accept that the answer will be incomplete.
And the tier four list is my judgement, not a law. I can construct a team for whom automated stale-ticket closure is obviously correct: high volume, low individual ticket value, a well-understood archive path and a culture that treats the backlog as a queue rather than a promise. If you are that team, close the tickets. What I would hold onto is not my specific list but the discipline of asking the four questions and being honest about the answers, particularly the one about how long an error stays invisible.
The takeaway
Order automation by the cost of being wrong, not by the hours saved. That means linking and evidence first, forward transitions second, gating and rollups much later, and priority, estimates, assignment and anything that messages people outside the team probably not at all.
Recording is safer than deciding. Audience matters more than accuracy. And thresholds should vary by action, because forcing one number to cover both your safest and your riskiest automation wastes the scarcest resource you have, which is human attention on the review queue.
The next piece is about the part of this that no framework solves: getting the developers whose work you are automating to actually want it, without reaching for a mandate.