Most automation pitches come with a promise about time. The support bot will close tickets faster, and the AI agent will cut your mean time to resolution (MTTR) in half.
For any single task, the promise is often true. A chatbot can handle a password reset in seconds, and an agent can pull the logs before you've opened the dashboard but what no one talks about is how the average looks like a year later, once everyone has gotten used to the new tool.
In 2019, Charles Betz and Chris Gardner wrote about the automation paradox they were seeing in some large organisations: MTTR was going up, even though those companies had invested heavily in bringing it down which seems contradictory at the start.
The law of stretched systems
In 1997 Lawrence Hirschhorn described what's now called the law of stretched systems: "every system is stretched to operate at its capacity." When something improves, people use the improvement to do more, faster, until the system is back at its limit.
Fred Hebert has a good post on this with examples from computing. When our machines got more RAM, we opened more browser tabs (if you've ever looked at your own tab count, this one is hard to argue with). Faster networks gave us heavier web pages, and cheap storage gave us bigger files. Decades of productivity gains haven't shortened the working week either.
How the gain gets spent
A mean time is an average over the work you're doing, and that work changes once the tool arrives. I see three ways it changes.
The first is that more work shows up. In the 1860s William Stanley Jevons pointed out that Britain's more efficient steam engines hadn't reduced how much coal the country burned, an effect now called the Jevons paradox. Cheaper power meant people found more uses for it. Software teams get the same effect from delivery pipelines. When deploying is quick and safe, teams deploy more often, and more means that there is an increased number of changes in flight that could fail.
Expectations also rise to meet the tool. In 1983 the historian Ruth Schwartz Cowan published More Work for Mother, a history of household technology. Washing machines and vacuum cleaners made each chore easier, but people's idea of a clean house rose to match, and work that servants or commercial laundries used to do moved back into the home. The hours spent on housework didn't fall the way people expected. Office messaging went the same way: email and Slack move faster than letters ever did, and now an hour without a reply feels slow.
The third matters most for MTTR: automation takes the easy work first, so whatever still reaches a person is the complicated part. Lisanne Bainbridge wrote about this in her 1983 paper "Ironies of Automation", noting that automation "can make the difficult parts of the human operator's task more difficult." If a support bot answers the password resets and "where's my order" questions, the tickets that reach a human are the strange ones. So the average time a human spends on a ticket can go up while the support operation as a whole gets faster.
What this does to MTTR
Say your team adds auto-remediation and an AI agent. The incidents that used to take ten minutes now resolve on their own, and some of them stop being counted as incidents at all. The incidents still left for people are the hard ones, like failures with several causes or a dependency outside your control. Faster resolution also makes shipping feel safer, so the team ships more.
The the automation paradox piece describes this happening. Vendors were reporting that knowledge articles had shorter useful lives and that there were fewer known errors. Fewer incidents could be fixed from a runbook, and more needed a senior engineer to work out. The automation was doing its job, and the people were left with harder incidents than before.
Why MTTR can't show the change
Suppose none of that happened and the tool really did make incidents shorter. MTTR probably still wouldn't show it. Most incidents are short and a few very long ones dominate the average, so it swings from month to month on its own (Lorin Hochstein has simulated this).
Stepan Davidovic reached the same conclusion in Google's report "Incident Metrics in SRE", finding that statistics like MTTR are "poorly suited for decision making or trend analysis." Courtney Nash's research on the VOID, a database of public incident reports, found no correlation between how long an incident lasted and how severe it was, so even an accurate MTTR wouldn't tell you whether things were getting better for your users. Add the stretch on top, and an MTTR chart can rise while the automation helps a great deal, or fall for reasons unrelated to the tool.
If your organisation judges automation by an average
Averages like ticket handling time or MTTR can mislead you about whether automation is paying off. The time a tool saves usually goes into more work or higher expectations, so the gain shows up somewhere other than the average. The work left in the average changes too. Automation takes the easy cases first, and some of them stop being counted at all, so the average can go up while the automation is working. That's what Forrester's clients saw with MTTR.
Some averages are too noisy to read in the first place. When most cases are quick and a few take far longer, as incident durations do, the average moves around from month to month even when nothing has changed. For incidents, duration doesn't even track impact: the VOID found no correlation between how long incidents lasted and how severe they were, so a lower MTTR doesn't mean users had a better time either.
I still think teams should automate the easy work. The support bot and the auto-remediation in this post are doing what they were built to do. What I'd stop doing is judging them by a mean time.
