Over-automation: when write-back makes things worse
A board that updates itself is better than a board nobody updates. Except when it is not, and the failure mode of an automated record is meaningfully nastier than the one it replaced.
Six weeks after the automation went in, the board was immaculate. Tickets moved when pull requests merged. Statuses reflected branch activity. Nothing sat stale. The delivery manager stopped chasing people for updates and the standup got four minutes shorter.
In week seven, a stakeholder asked why a feature that the board said had been delivered in week four was not visible to customers.
The trail took most of a day to reconstruct. A pull request had merged with a ticket reference in the branch name. The automation moved the ticket to done. The pull request was one of three that the work needed. The other two were still open, blocked on a decision, and neither of them carried the reference because they had been branched from a different base and named differently.
The automation had been right about what it saw. The rule was “merged pull request closes referenced ticket,” and a referenced pull request had merged. There was no bug. There was a rule that was correct in the ninety percent case and silently wrong in the rest, applied uniformly, at speed, with nobody watching, because the whole point of installing it had been that nobody would have to watch.
Here is the part that should worry anyone considering this: the manual process had the same failure. People closed tickets prematurely all the time. The difference is that when a human closes a ticket wrongly, someone tends to notice, because a human closing a ticket is an event with a person attached, and people ask people things. When automation does it, the ticket is simply correct-looking. There is no author to ask. The record has authority precisely because it is systematic.
Automating a record does not just change who maintains it. It changes what being wrong looks like, and it changes it in an unhelpful direction.
The trust asymmetry
The core problem is that a manual record and an automated record fail differently, and organisations respond to those failures differently.
Everyone knows the board is a bit wrong. That is the ambient assumption in every team that has ever used one. It produces a healthy defensive behaviour: people check. Before a stakeholder call, the delivery manager pings a couple of engineers. Before planning, someone confirms that the three tickets marked done are really done. That checking is friction, and it is also error correction, and it exists precisely because nobody fully trusts the artefact.
Automate the record and the checking stops. Not by decision, but because the justification for it evaporates. Why would you verify a system that updates itself from source control? The whole pitch was that it does not drift.
So you have replaced a record that was wrong ten percent of the time and checked constantly with a record that is wrong two percent of the time and never checked. Whether that is an improvement depends entirely on what the two percent contains and how long it survives, and the honest answer is that automated errors survive much longer, because the mechanism that used to catch them was suspicion.
I do not think this argues against automation. I think it argues that anyone deploying it should expect the error profile to get thinner and longer-lived, and should plan for that rather than being surprised by it.
A manual record
- Wrong maybe ten percent of the time
- Everyone assumes it is a bit wrong
- So people check before it matters
- Errors are caught by ambient suspicion
An automated record
- Wrong maybe two percent of the time
- Nobody assumes anything is wrong
- The justification for checking evaporates
- Errors are thinner and live much longer
Where write-back is genuinely wrong
Some specific cases where I would advise against automated write-back even where it is technically possible.
Anything where the automation’s model is coarser than the concept. “Merged means done” is a model. Done, for most teams, means merged and deployed and flag-enabled and verified. If your automation cannot see three of those four, it should not be writing the state that implies all four. Write what you know. A field that says “code merged on Tuesday” is honest and useful. A status that says “done” is a claim the system cannot support.
Anything that closes a conversation. Moving a ticket to done does not just record a fact, it ends a thread. It removes the item from the queue people scan, it stops the reminders, and it signals to everyone watching that they can stop thinking about it. Automation that ends conversations is far riskier than automation that starts them, because a wrongly-started conversation costs a minute and a wrongly-ended one costs however long it takes for someone to independently rediscover the problem.
Anything where the write is the input to someone else’s decision without a human in between. Ticket state feeds forecasts, feeds capacity models, feeds stakeholder reports. A single wrong transition can propagate into a reprioritisation. The further the write travels before a human evaluates it, the higher the bar for automating it should be, and most teams do not think about propagation distance at all when deciding what to automate.
Anything in a low-signal situation the automation cannot recognise as low-signal. This is the deep one. Most automation is confident everywhere or nowhere. A rule engine does not know that this particular ticket is unusual. If your system cannot express “I am not sure about this one,” then it will apply the same confidence to the clear case and the ambiguous case, and the ambiguous cases are exactly where you needed judgement.
The gradient nobody walks
There is a spectrum between “nothing is automated” and “the system maintains the record,” and most teams jump straight from one end to the other because that is how the tooling is packaged.
The intermediate positions are better and underused.
Detect and display. The system computes divergences between the record and ground truth and shows them. Nobody’s data changes. A human looks at a list of twelve disagreements and resolves them in five minutes, which is dramatically less work than discovering them and about as accurate as anything gets. This alone captures most of the value of the whole exercise, because the expensive part was never the click, it was knowing which click to make.
Propose and confirm. The system suggests transitions and a human approves in bulk. Slightly more efficient than the above, slightly more dangerous, because bulk approval becomes rubber-stamping quickly. Still, the human remains in the loop and, crucially, remains aware that the system is making claims rather than stating facts.
Write with reversal. Automatic writes with a visible attribution and a one-click undo, plus a digest of everything written. The undo matters less than the digest: what you want is that someone sees the volume and shape of what the automation did this week, because that is the only way anyone notices when it starts doing something odd.
Write silently. The end state most products aim for. Justifiable only where the rule’s accuracy has been measured against reality over a meaningful period, in the actual repository, with the actual team’s conventions. This is what shadow mode is for, and I would treat any vendor that lets you skip it as not serious. Including us: GroundTruth ships shadow mode not as a trial feature but because a write-back rule whose accuracy on your codebase is unmeasured is a rule nobody should be running.
Most teams should stop at the first or second position and stay there longer than they want to. The marginal value from the third and fourth is real but small, and the marginal risk is not.
The case against my own category
I should be direct about something, since this article is published by a company that sells a delivery intelligence product.
There is a coherent argument that the entire category is treating a symptom.
Boards drift because they are a parallel record of work maintained by people who get nothing from maintaining them. The industry response has been to automate the maintenance. An alternative response would be to notice that if the record is so useless to the people doing the work that it can only be maintained by a machine, perhaps the record should not exist in its current form.
Some teams do exactly this. They run planning from a short document, track work as pull requests, and hold status conversations rather than reading boards. They have no drift problem, because they have no parallel artefact to drift. They also have real limitations: it does not scale past a certain size, it makes cross-team visibility hard, and it produces nothing an auditor recognises. But within those limits it is not a worse solution, it is a different and often cheaper one, and it does not require buying anything.
There is a second argument that cuts deeper. Automating the record makes the record cheap to maintain, which removes the pressure that would otherwise force a team to confront why they have so much ceremony in the first place. Pain is information. A board that is constantly wrong is telling you something about the distance between your planning apparatus and your actual work. Automating the symptom lets you keep the distance and stop feeling it, and I genuinely do not know how often that is a good trade. Sometimes the friction was the only thing prompting a necessary conversation.
I still think the tooling is worth building, for the reason that most organisations above a certain size cannot actually abolish the parallel record: they have stakeholders, auditors, dependencies, and people who need to know things without asking. But “you cannot get rid of it, so make it honest” is a much weaker claim than “this is how software should be built,” and I would rather make the weak claim accurately than the strong one dishonestly.
The competence trap
One more effect worth naming, because it does not show up for a year and then it is hard to reverse.
When a system reliably keeps the record straight, people stop building the mental model that used to keep it straight. The delivery manager who used to know, roughly, where everything was, because she had to reconstruct it constantly, now reads it off a screen. That is a real efficiency gain and it is also a loss of a capability, and the loss is invisible until the system is wrong or unavailable.
This is the standard automation-dependence story from aviation and process control, and there is no reason software delivery would be exempt. The mitigation in those fields is not less automation, it is deliberate practice at the manual task and design that keeps the operator engaged rather than merely supervising. The software equivalent is something like: periodically reconstruct the delivery picture by hand and compare, keep the underlying evidence one click away rather than three, and be suspicious of interfaces so clean that nobody ever looks behind them.
When a system reliably keeps the record straight, people stop building the mental model that used to keep it straight. The delivery manager who knew roughly where everything was no longer needs to, so eventually cannot.
Aviation and process control found the mitigation is not less automation. It is deliberate, scheduled practice without it.
Where this breaks down
I have argued hard against automation in this piece, so here is the argument against the argument.
The manual baseline is much worse than nostalgia suggests. I described a healthy culture of checking, where people verify the board before decisions. That culture is rare. The common case is a board that everyone knows is wrong, that nobody checks, and that decisions get made from anyway because there is nothing else. Compared to that, an automated record that is wrong two percent of the time is a clear improvement even with no checking at all, and refusing it on the grounds that it might be trusted too much is letting the perfect defeat the considerably better.
“Detect and display” degrades on its own. A list of twelve divergences a week gets resolved. A list of eighty does not, and at high change volume you will get eighty. The intermediate positions I recommended are stable only at moderate scale; past that, the human in the loop becomes a bottleneck who approves in bulk without reading, which is write-back with extra steps and a false sense of oversight. If you are going to end up bulk-approving, it is more honest to automate and audit than to pretend there is a human gate.
Errors of omission are errors too. This piece treats automated wrong writes as the risk and manual non-writes as the safe baseline. That is not fair. A board that understates progress by a week causes real misallocation, real over-commitment, and real damage to a team’s credibility, and it does so continuously rather than occasionally. Both directions cost. I have spent this article weighing one carefully and the other barely at all, which is a bias worth flagging in myself.
And some of this is genuinely just risk-aversion dressed as wisdom. Every argument in this piece could have been made, and was made, about continuous deployment, about automated dependency updates, about infrastructure as code. In each case the caution was reasonable at the time, the failure modes described were real, and the teams that automated anyway ended up in a better place than the teams that did not. The pattern of “automation creates unmonitored failure modes, therefore proceed carefully” has a strong track record of being right about the failure modes and wrong about the conclusion. Take the specific warnings seriously. Be suspicious of the general posture, including mine.
The takeaway
Automating a record does not eliminate its errors, it changes their shape: fewer, thinner, longer-lived, and stripped of the human suspicion that used to catch them. That is a real trade and it deserves more thought than “the board updates itself now.”
Write only what you can actually observe, be extremely reluctant to automate anything that ends a conversation, and spend much longer than feels necessary in detect-and-display before moving to write-back. Measure the rule against reality in your own repository before you trust it anywhere. And keep an open mind about the possibility that a record which can only be maintained by a machine is a record that should have been redesigned instead.
The next piece looks at what none of this bookkeeping can recover once it is gone: the reasoning behind a change, why it disappears faster than it used to, and what it costs the person who has to touch that code in eighteen months.