The short version
- Most technology budgets run about 70/30 in favour of "run". Every CIO reports the ratio; almost nobody itemises what sits inside the run half.
- Incident toil is a large, measurable slice of it — and unusually, it is one of the few slices that can be attacked without a migration, a reorganisation or a platform rewrite.
- The honest saving is not headcount. It is capacity released: the same team absorbing more services without the rota degrading. That number survives the first outage the automation does not handle. A headcount promise does not.
- You can measure your own starting point in a fortnight with data your ticket system already holds. Three questions are at the end of this post.
Every technology organisation above a certain size reports a run-versus-change ratio, and every one of them wants to move it. The figure quoted most often is around seventy per cent run, thirty per cent change — and whether yours is 65/35 or 80/20, the direction everyone is pushing is the same.
What makes the ratio so stubborn is that "run" is not one thing. It is a bucket containing licences, infrastructure, compliance work, patching, upgrades, vendor management and operational labour, and those have wildly different elasticities. You cannot decide to spend less on patching. You can decide to spend less on some of the others — but only if you know which line is which, and most organisations do not itemise below the bucket.
What is actually inside "run"
When we ask technology leaders to break the run half down, the conversation usually arrives at something like this. The percentages vary by industry and by how much legacy is carried, but the shape is consistent.
Incident and problem management is consistently the second-largest line, and it behaves differently from the largest. Infrastructure spend is contractual and slow to move. Incident labour is operational — it responds to how the work is done, not to what was signed three years ago.
It has one other property that matters to a CIO more than its size: it grows with the estate whether or not anything else does. Every new service, every acquisition, every migration to a new platform adds alert volume. Unless something changes about how each alert is handled, headcount has to track estate growth, and that is the curve that eventually forces the conversation.
The part of it that is toil
Not all incident labour is a candidate. The distinction that matters is between work that requires judgement and work that is repeated lookup, and it is sharper than most people expect.
We timed a single production incident end to end in another post in this series. Forty-one minutes total; twenty-one and a half of them spent locating and reading information that already existed in systems that were already running. Not diagnosing — fetching. Seven minutes were genuine judgement, and those seven are why you employ senior engineers.
That ratio is not universal, but the fetching share sits between forty and sixty per cent almost everywhere we have looked. Applied to the twenty-two per cent slice above, it means something in the order of nine to thirteen per cent of the entire run budget is repeated lookup — work with a correct answer that does not depend on who performs it.
Why this line is invisible
No cost centre is called "looking things up". It is distributed across every engineer's week in five- and twenty-minute fragments, it never appears on a project plan, and it is specifically the work that does not get logged because logging it would take as long as doing it. Its invisibility is the reason it survives budget scrutiny year after year.
What moving it actually looks like
Here is where most transformation narratives overreach, so let us be precise about the mechanism.
evidence from 6 tools"] B2 --> B3["Engineer judges"] B3 --> B4["Engineer acts"] B4 --> B5["Two-line ticket"] end subgraph After["With the gathering automated"] A1["Alert fires"] --> A2["Runbook assembles
the same evidence"] A2 --> A3{"Does the evidence
settle it?"} A3 -->|"yes, and confidence
is above the floor"| A4["Closed, with a record"] A3 -->|no| A5["Engineer judges,
from a full picture"] A5 --> A6["Engineer acts"] A6 --> A7["A record that
survives the night"] end style B2 fill:#fde8e8,stroke:#e57373 style A2 fill:#e4f7f2,stroke:#22c1a4 style A5 fill:#f4f6ff,stroke:#a78bfa
Two things change and one deliberately does not. The assembling moves from a person to a system. The incidents the evidence clearly settles stop consuming a person at all. And the judgement — the seven minutes — stays exactly where it is, because that is the part you are paying for and the part an automated system should not be trusted with.
The three ways this shows up financially
| Mechanism | How it lands | How defensible |
|---|---|---|
| Capacity released | The same team handles more services without the rota degrading. Shows up as headcount not added as the estate grows. | High. Provable against your own growth curve, and it survives a bad quarter. |
| Escalations avoided | Incidents that stop at L1 because the information needed to be sure is now on the ticket. Each one removes a whole handoff. | High. Directly measurable in your ticket system, before and after. |
| Sourcing leverage | If L1 is contracted out, per-ticket handling time and escalation rate are contract variables. Moving them moves the contract. | Medium. Real, but it lands at renewal rather than immediately. |
| Reduced outage minutes | Customer-facing time, not engineer time. For revenue-bearing services this usually dwarfs the labour line. | Varies. Large if you already price outage minutes; hand-wavy if you do not. |
| — | Avoid. See below. |
Why not to promise headcount reduction
It is the number finance will ask for, and committing to it is the most common way these programmes fail politically rather than technically.
The first reason is practical. Automation handles the procedural share of incidents well, the known-shaped share partially, and the genuinely novel share not at all. Cut headcount against the first category and the first genuinely novel outage arrives with a team too thin to handle it — at which point the automation is blamed for an outcome the business case caused.
The second reason is organisational, and it is the one that actually kills programmes. The moment your support organisation understands the business case as a headcount case, you have made the people who must adopt the system its opponents. They will not sabotage it. They will do something more effective: they will escalate everything, cite every error it makes, and decline to write the runbooks that make it work. Adoption is not neutral to how you frame the funding.
The framing that holds
"We will absorb the next three years of estate growth without growing the on-call rota, and our senior engineers will spend materially less of their week on work that does not need them." That is honest, defensible against your own data, and it does not make your own organisation the adversary of the thing you are buying.
Measuring your own starting point
You do not need a consulting engagement for this, and you should be sceptical of one that is proposed. Three questions, answerable in a fortnight from systems you already have.
- What proportion of incidents that reach L2 were escalated without a change being made at L1? Your ticket system knows. This is the escalation the information gap caused, and it is usually the largest single surprise in the exercise.
- What is the median gap between escalation and first action at the receiving tier? Measured separately from handling time. This is pure waiting, it belongs to no team, and therefore nobody currently reports it.
- What share of incidents close with no change made to anything? If it is a third, you are paying full incident cost for alerts that only needed someone to watch a number come down.
Then time three incidents by hand, with a stopwatch. Not a survey of what people think they spend — an observation. The fetching share you get from three real incidents will be the most useful number in the business case, and it will be yours rather than a vendor's.
Three ways to read this
If you own the ratio
This is one of the few run-side lines that moves without a migration or a reorganisation, which makes it unusually cheap to attempt and unusually easy to reverse if it disappoints.
Fund it as capacity, measure it against your own growth curve, and keep the headcount question out of the business case entirely.
If you run the support org
Get the three numbers above before anyone else does, and bring them yourself. This conversation is far better to lead than to receive.
Question three is usually the one that reframes the discussion in your favour.
If you will implement it
The finance framing determines your integration deadline. "Capacity released" gives you room to start read-only and earn trust; "headcount by Q3" does not, and you will be asked to switch on write access before the evidence justifies it.
Next in this series
When your best SRE leaves, what does the organisation still know? — the transformation argument that has nothing to do with cost, and the one that tends to matter more in three years.