Beyond Automation: Designing Human-Centred IT Operations

October 26, 2026

IT Operations

Picture an operations team that automates incident triage. Routine routing gets quicker, everyone’s pleased, and then an unfamiliar failure lands with an engineer who hasn’t diagnosed anything unusual in months, in a service whose escalation path has changed since the rules were written. The automation did exactly what it was told. That’s what makes the review awkward, because the fault isn’t in the execution. A proper review looks at the decision built into the rules and at whether the team still has the skill to handle what the rules can’t.

What a 1983 paper saw coming

Lisanne Bainbridge wrote about this in “Ironies of Automation,” published in Automatica in 1983. Her subject was process control, which means plant rooms and not ticket queues, so treat the parallel with software operations as a working hypothesis to test against your own system. Her argument runs like this. Automate the routine work, and you leave a person with two jobs: watching something that rarely goes wrong, which is harder to do well than it sounds, and stepping in when it does. The second job needs exactly the skill that the first job never lets them practise. The rarer the intervention becomes, the more training and rehearsal it takes, and an IT operation that wants the efficiency saving should put the cost of that practice in the business case.

Assumptions go in and don’t come out

Where does the reasoning behind an automated rule live once the people who wrote it have gone?

When a team automates a workflow, it builds in a model of that workflow: which conditions matter, which signals can be trusted, what normal looks like, what a sensible response is. Those are judgements, and on the day of writing they’re held in people’s heads, debated and sometimes argued over at length. A year or two later the people who made them have moved teams, the rule is still running, and its rationale is scattered across code, old tickets and somebody’s memory. A runbook that says what happens and not why leaves the operator guessing.

Say a rule sends anything mentioning payment timeouts to the payments queue, because three years ago every one of those turned out to be a gateway problem. Since then, half of checkout has moved to a new provider. The rule still fires, the payments team still gets the tickets, and the real fault sits in a queue where nobody has the access to fix it. The engineer who wrote the rule is on another team and has no idea it’s still making that call.

Environments change underneath an assumption all the time. A dependency starts failing differently, traffic shifts, a release alters a service, and nobody thinks to revisit its triage rule. The post-incident review then finds automation behaving perfectly against a world that’s gone. Calling that a tooling fault misses the real problem, which is a decision nobody has looked at since it was made.

Reviewing the assumption, not only the fault

A review needs two questions. What happened in the system, and which assumptions made that behaviour reasonable when the automation was designed? Fixing the immediate fault matters, but the fix only holds if it’s recorded alongside the reasoning it changed.

So, ask what the system expected of its environment, and what evidence says that expectation still holds. If nobody can answer, write down the missing rationale and name someone to look after it. A simple register can sit beside the runbook: each material assumption, the condition that would invalidate it, and a named reviewer. Start with the decisions that affect routing or recovery. Judge the register by whether an operator can use it to diagnose and change the process, since a document that exists and helps nobody isn’t worth keeping.

Designing for the intervention

The exceptional path deserves as much care as the automated one, because whoever receives an escalation needs enough context and authority to act on it. Volume makes the routine path the obvious place to put the effort, yet the odd case often carries more risk, and that’s a reason to rehearse the handoff and recovery before anyone claims the efficiency saving.

The escalation route should be spelt out, down to which signals led to the automated choice and which alternatives it turned down, with the system’s own uncertainty shown wherever it can be represented reliably and a way for operators to take over when the classifier can’t cope.

A recovery exercise tests the hidden assumption before an incident does. Hand an on-call engineer an exception the rules can’t classify and watch what they reach for: which logs, which permissions, which colleagues. Note where they must guess. That tells you whether you need a runbook update, a change to escalation or a practice rota, and it puts a figure on the business case for keeping human capability ready.

For a triage system, the register could name the incidents the classifier recognises, the telemetry it depends on and the threshold that sends a case to a person. Next to each entry go the approver and the kind of change that would make the rule unsafe or misleading. A dependency upgrade or a new customer segment can then trigger a check, and the first sign of trouble won’t be an exception at two in the morning. It only works if those changes reach the person who can update the decision.

Practice should cover judgement as well as button pressing. During an exercise, ask the engineer why the system chose a queue, which alternative they weighed and when they’d bypass it. If the interface offers only the final label, you’ll see the missing context. If they lack the authority to reroute an incident, you’ll find a second problem, and a runbook update fixes neither unless the interface and the escalation rights change with it.

The automation owner should go through those exercises with the people who take the calls. A successful routing rate is only one measure of safety, so track false routes, the time it takes to recognise an exception and the effort to recover alongside it.

Then look again later: was the practice time used, and did the register change after the last release? A document written once will age alongside the code unless someone owns the next look, and the practice time belongs in the staffing plan as a cost with a name.

Three signs you’re already there

First, compare escalated and routine incidents by type and severity before you look at time to resolution. Exceptions will take longer. An unexpectedly long delay after the handoff points to missing context or unclear ownership.

Second, look at who gets called when something unfamiliar breaks. If it’s always the same person, you have a knowledge risk. Write down the judgment they supply and let others practise it.

Third, check whether the runbook changed when the system or its dependencies did. An old runbook is a reason to inspect the assumptions inside it, especially if it’s the one an operator reads in the small hours.

These checks need incident records, interviews and a read-through of the runbook. Do them in an operating review, while there’s still time to act.

What the automation budget buys

An automation case usually counts staff time and cycle time. It should also estimate the cost of handling exceptions, of practice, and of keeping the encoded decisions current, with an owner for each before deployment. Headcount and cycle-time savings can be recorded accurately while every one of those costs goes unmentioned.

Before the next automation programme, ask which judgement is going to become rare, how the team will keep it alive, and how the system will explain itself on the day that judgement is needed.