A script that closes two hundred tickets a month is doing the work of a person. It shows up in no headcount plan, appears on no org chart, and has no manager. When it breaks, the tickets come back, and the team absorbs them as though the volume were new.
This is a measurement problem before it is an engineering one.
Count what the automation does
Most teams track ticket volume and resolution time. Neither captures work that never became a ticket.
Password resets that self-serve, access requests that auto-approve within policy, disk cleanups that run before the alert fires, provisioning that happens without a request — all of it is deflected work, and if you do not instrument it, your reported volume drops and looks like reduced demand rather than increased capacity.
Instrument the deflection. Every automated path should emit a count. The number you want is not "tickets closed," it is tickets that never opened.
The staffing conversation changes
Once deflection is visible, the conversation shifts from headcount to capacity.
We are not asking for another engineer. We are pointing out that four of them already exist in the automation, and one of them is unmaintained.
That framing does two useful things. It makes the case for maintenance time as a real budget line rather than something squeezed between tickets. And it makes the risk legible: an unmaintained automation is a resignation nobody scheduled.
Automation needs an owner
Every meaningful automation should have a named owner, a documented failure mode, and a known blast radius. Not because it is fragile, but because it is load-bearing.
The failure pattern is consistent. Someone builds a useful script, it works quietly for a year, that person changes roles, an API version deprecates, and the work silently returns to the queue. Nobody connects the volume increase to the thing that stopped running, because the thing that stopped running was never on any list.
- Owner — a person, not a team alias.
- Failure mode — what happens when it stops, and how you would notice.
- Blast radius — what it touches if it runs wrong rather than not at all.
Three lines per automation in a register. It is not a heavy process, and it converts invisible infrastructure into something a manager can reason about.
The part that is uncomfortable
If automation genuinely replaces the work of several people, someone will eventually ask whether it replaces the people.
The honest answer in every environment I have worked in is that it does not, because the demand was never being fully met in the first place. The queue was triaged, not cleared. What automation buys is not fewer people — it is the same people working on the backlog that never got attention, which is usually where the actual leverage was hiding.
But that only holds if you can show the numbers. Without instrumentation, "automation created capacity" is a claim. With it, it is a report.