Automation Is Not About Removing People

Automation conversations have a habit of sprinting towards the wrong argument.

One side treats every manual task as evidence of human inefficiency. The other hears automation and reasonably wonders which part of their job is about to be described as a saving. Meanwhile, the actual workflow is still copying attendee data between two spreadsheets because nobody asked what the system was for.

Useful automation isn't about removing people. It removes repeated friction, hidden admin, and fragile handovers so people can spend their attention where judgement actually matters.

Not all manual work is valuable

Some manual work matters because it involves:

• judgement
• interpretation
• negotiation
• accountability
• nuance

Other manual work exists because the system is unfinished and a person has been quietly hired as its integration layer.

That includes copying data between tools, chasing status updates, cleaning exports, sending routine reminders, rebuilding the same summary every week, or reformatting information so one system can tolerate it.

Automating that kind of work isn't dehumanising. It is basic respect for people's time.

The real distinction is where judgement lives

I tend to separate automation into three layers:

1. Automate retrieval.
2. Automate formatting and routing.
3. Support judgement without pretending to replace it.

The first two are usually straightforward. The third is where a system either becomes genuinely helpful or wanders into overconfident nonsense.

Take an abstract review workflow. Automation can:

• gather submissions
• identify duplicate structures
• suggest likely categories
• surface confidence levels
• route unclear cases to human review

That is useful. It gives reviewers a clearer queue and reduces the administrative work around the decision.

What isn't useful is pretending the system should make the final academic judgement with no visible reasoning and no obvious route for a reviewer to intervene.

Good automation makes responsibility clearer

A well-designed automated system should make four things easier to see:

• what happened
• why it happened
• what is still pending
• who needs to decide next

This is why the interface matters as much as the automation behind it. If the system hides its state, swallows an exception, or makes ownership ambiguous, the team feels less in control. The work may be moving faster, but the anxiety has merely been automated too.

The useful measure is whether work becomes calmer

If an automation project produces opacity and confusion, it has probably been framed badly, designed badly, or both.

If it gives people better visibility, fewer repeated tasks, and a clear point at which human judgement takes over, it is doing the right kind of work.

Automation isn't a philosophy of subtraction. It is a way of moving effort away from repetition and back towards responsibility.