Before we automate work, have we understood why the work exists in the first place?

One of the harder things about technology leadership is knowing when not to solve a technology problem with more technology.

A process is slow.

People copy information between systems.

A team maintains a spreadsheet because the official system does not quite support the work.

Staff spend hours producing a report that somebody else then reformats.

These are obvious candidates for automation.

Increasingly, AI can make automating them remarkably easy.

But ease of automation creates a risk.

We can make the workaround faster without asking why the workaround exists.

Sometimes the answer is straightforward. The work is necessary, the process is sound and technology can remove effort that adds no value.

Sometimes the friction is telling us something.

The spreadsheet may exist because the formal system does not reflect how the service actually works.

The report may be produced because governance asks for information nobody uses.

The repeated hand-off may exist because accountability is split badly.

The manual check may compensate for poor data upstream.

The workaround is not always the problem.

Sometimes it is evidence of the problem.

Technology can make a good operating model dramatically better. It can also make a bad operating model dramatically faster.

That distinction becomes more important as execution gets cheaper.

When automation was expensive, organisations had a reason to examine a process before investing heavily in changing it.

If an AI agent can now be built quickly to perform the existing steps, the temptation is to skip that examination.

The result can be impressive local productivity while the wider system remains unchanged.

A task takes five minutes instead of fifty.

But perhaps the task should not exist.

Or the information should have been captured once somewhere else.

Or the decision should sit with a different person.

Or the user should never have been required to navigate that process in the first place.

This is why workarounds can be a form of user research.

They show where the formal design and the real work have diverged.

Watching what people have built around a system can tell us what the system failed to provide.

That does not mean every workaround should be preserved or every process redesigned before anything can be automated.

The economics of certainty matter here too.

If a small automation is cheap, safe and reversible, it may be entirely sensible to try it and learn.

But the learning should include the system around the task, not only whether the automation performed the task correctly.

The leadership question is therefore broader than “What can we automate?”

It is “Why does the work happen this way?”

AI makes the first question much easier to answer.

That makes the second one more important.