Automate the Reason, Not the Task

Some of the engineers I worked with spent hours handling incidents generated by inconsistencies in the environment they were supporting.

They checked alerts. They copied data from one system to another. They prepared the same reports every week and every month. They resolved tickets by following runbooks they knew by heart. Service-desk staff, operations teams and managers were caught in the same loop.

None of it was idle work. All of it was repetitive. And much of it existed for reasons nobody had questioned in years.

Causes, not symptoms

When we looked underneath the alerts at HP, a pattern appeared. The servers had not been configured to a common standard. Each variation behaved differently, and much of that behaviour looked like a fault to the monitoring tools.

So many alerts were false. Each false alert still raised an incident, and each incident still needed an engineer.

The obvious response would have been to automate the handling of those incidents: treat the symptom faster. The Automation Configuration Framework took the other route. It standardised the configuration of the estate. Once servers behaved consistently, many of the false alerts, and the incidents behind them, stopped.

The same thinking changed how we handled change. Change management was genuinely necessary: systems change, and changes need control. But much of the work around each change existed because of legacy systems, outdated controls, duplicated reporting and workarounds that had become habits.

We stripped that back. We introduced deployment to test systems first, and a four-eyes check, a second-person review, before production. Only then did we automate what remained.

Deployment time fell from three hours to 15 minutes, and operational hours fell by 65%.

The cheapest incident is the one that is never raised.

Engineer-to-Zero

The configuration framework was the predecessor to Engineer-to-Zero, which applied the same thinking more broadly across our global delivery locations. Its intent was to remove repetitive effort, unnecessary operational work and manual intervention. Looking back, the point was never to remove engineering judgement. It was to remove repetitive work that consumed engineering capacity without requiring it.

Where the configuration framework removed the causes of noise, Engineer-to-Zero went after the operational work that remained: the incidents, service requests and manual interventions engineers handled by routine.

Defects fell by 50%. Operational events fell by 82%, and 71% of incidents were resolved automatically.

The numbers were not the most important outcome. Both programmes removed work rather than making the existing process run faster, and that changed how the engineers thought. They began asking whether a task should exist at all before asking how to automate it.

Simplify first, automate second

That experience shaped the sequence I recommend today:

1. Question why the work exists

2. ↓

   Eliminate unnecessary steps and duplicated controls

3. ↓

   Standardise the process and its operating conditions

4. ↓

   Automate the remaining work

Automating a bad process makes it faster, and harder to see, because nobody watches work that runs by itself. Most programmes start at step four. That is why so many automation business cases count tasks automated rather than work removed.

Not every task belongs in the sequence. Some work should stay manual, or under explicit human judgement, because the decision is uncertain, consequential or poorly understood.

What changes with AI agents

Traditional automation follows defined rules. AI agents raise a different question, because they can interpret context, choose actions and interact with systems.

AIOps tools can already review alerts alongside related incidents and service requests, learn from past incidents, match today's symptoms to earlier scenarios and propose a likely cause with a guided fix. That is valuable. It is also a recommendation, not an authorisation.

Diagnosis, recommendation and execution are separate permissions. A system that can identify a probable cause has not earned the right to act on it, and a known symptom does not always imply a safe remedy.

Where the decision boundary sits depends on four things: how confident the diagnosis is, whether the action can be reversed, how large the impact would be if it is wrong, and what controls surround it. Clear-cut, reversible, low-impact fixes can be defined in advance and executed automatically. Uncertain or consequential ones need a human decision.

The old lesson applies with more force. Simplify the process before an agent touches it. An agent working on an unstandardised estate will learn the noise as faithfully as the signal.

Work removed is not value realised

Removing work is the first measure, not the last. Three things need to be kept apart:

• Work removed: the incidents, steps and reports that no longer exist.
• Capacity released: the hours that removal frees up.
• Value realised: what the organisation does with that capacity.

Released hours can be redeployed, absorbed into other work or taken out of the cost base. Unless someone decides which, they tend to disappear.

Before approving automation

Ask three questions:

• What work will disappear?
• What capacity will be released, and how will it be used?
• What decisions will the system be authorised to make?

If the business case answers only how much faster the task will run, the work of transformation has not yet been done.