When we think about automation, we often start with the wrong thing: the task that is closest to us. We look at what we do every day and ask: “How can I automate this?” We don’t always ask whether the task actually matters for the bigger goal of the process or the organisation. That means we risk spending time and effort automating work that does not really need to be done in the first place.

Imagine this chain of work. We decide to automate the programming of a program. That program is supposed to automate the sending of an email. That email is meant to remind someone that there is something they need to do. The person who receives the reminder then has a task: they go through a list of possible problems that have occurred in the last month and pick out which ones it is possible to do something about. This list is collected and reported from across the entire organisation.

If we stop here, it looks like the obvious thing to automate is the programming of the program that sends the email. It is close to us, it is visible, and it feels concrete. But that is only one step in a longer chain. Before we decide to automate, we should trace the chain backwards and ask why each step exists.

Why do we need the email reminder? Because otherwise the person might forget to review the list. Why do we need the monthly review of the list? To decide which problems we should act on. Why do we collect a list of possible problems from across the organisation? To have an overview of issues and opportunities for improvement. Why do we need that overview? To improve how the organisation works and support its overall goals.

When we walk the chain backwards like this, we might discover that some links are weak. Maybe the list is reviewed, but almost nothing is followed up. Maybe the same problems appear every month without any action. Maybe the review is something “we have always done”, but it does not actually lead to decisions that change anything important. In that case, automating the programming of the reminder system does not create much value. We are just making it cheaper and faster to do something that might not need to be done at all.

A more useful approach is to start from the goal instead of the task. What are we actually trying to achieve? Better service for customers, fewer incidents, lower cost, less risk? From there, we can ask which decisions support that goal, which information is needed for those decisions, and which tasks are needed to produce that information. Only then does it make sense to ask what should be automated.

Before automating any task, it can help to ask a few simple questions. What concrete goal does this task support? What would happen if we stopped doing it for a month? Is there a simpler way to reach the same outcome? If the task does not clearly connect to a real goal, or nothing would break if we paused it, maybe it should be changed or removed instead of automated.

Sometimes, when you follow the chain all the way back to the organisation’s purpose, you find that a whole series of tasks — collecting lists, reporting them, sending reminders, reviewing them — is not really needed. Then the best “automation” is to avoid building anything at all.