The obligation

Automation is not a technology project. It is a leadership decision.

The leader who treats automation as something the IT department handles, something that arrives on a roadmap, something that requires a business case and a budget cycle and a steering committee, has already made the decision. They have decided to be slower than the organisation that treats automation as an obligation, not a project.

The obligation is simple. If a task can be automated, automate it. If a process step can be automated, automate it. If a response, a routing decision, a data entry, a report, a notification, a check or a transfer can be done by a system instead of a person, it should be done by a system instead of a person. Not eventually. As soon as it is possible.

This is not about cutting headcount. It is about where human effort goes. Every hour a person spends on work a machine could do is an hour not spent on work only a person can do. The organisation that automates aggressively does not have fewer people doing less. It has the same people doing more of what they were actually hired to do.

The leader who waits to be ready to automate will never be ready. Readiness is not the precondition. The decision is the precondition. Make the decision first. The readiness follows.

Key Takeaway: Automation is a leadership obligation, not a technology project. The decision to automate must come before the readiness to automate. Every task left unautomated when it could be automated is a choice, and that choice has a cost that compounds every day it remains unchanged.

If it can be automated, it should be. The question is not whether. The question is when.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Section: The obligation

MarvinPro | December 2025

marvinpro.com

What automation actually frees

People do not want to do work a machine can do. This is not laziness. It is good judgment.

The agent who spends three hours a day copying data between systems knows the machine could do it in seconds. The team leader who manually assigns cases from a shared queue knows a routing rule could do it without human intervention. The analyst who builds the same report every Monday morning knows the system could generate it overnight. They are not unaware that automation exists. They are waiting for someone with the authority to implement it to care enough to do so.

When that work is automated, something changes that no reorganisation or motivational initiative can produce. The people doing it stop spending their attention on tasks that require none and start spending it on tasks that require all of it. The quality of the work that only humans can do improves because the humans doing it are no longer depleted by the work they should not have been doing.

This is also what staff expect from a well-run operation. Not that every inconvenience is removed. That the work they are asked to do is work that is worth doing. The organisation that automates what can be automated signals to its people that it understands the difference between human effort and mechanical effort and respects the distinction. The organisation that does not sends a different signal entirely.

Automation does not reduce the workforce. It changes what the workforce is for. Pay people for what cannot be automated. That is where the value is.

Key Takeaway: Automation does not replace people. It redirects them toward work that requires human judgment, attention and skill. The staff who are freed from mechanical work do not become redundant. They become more capable of doing what they were actually hired for. The return is not a smaller payroll. It is a better one.

Pay your people for what cannot be automated. Everything else is a cost that should not exist.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Section: What automation actually frees

MarvinPro | December 2025

marvinpro.com

The competition will not wait

Every competitor in every market is looking at the same tasks, the same process steps, the same repetitive work. Some of them are automating it now. Some already have. None of them are waiting for permission.

The organisation that automates faster operates at lower cost per unit of output. It handles higher volume without proportional increases in headcount. It responds faster because fewer steps require human intervention. It makes fewer errors in the tasks where errors are most common, the repetitive, high-volume, low-variation work that people do reliably for an hour and unreliably for an eight-hour shift.

The gap between the organisation that has automated and the one that has not is not visible immediately. It is visible in the numbers over time, in the cost structures that diverge, in the response times that separate, in the error rates that compound and in the capacity to grow without the proportional cost increase that constrains the operation still dependent on manual effort for work a machine could do.

Speed of adoption is a competitive variable. Not just speed of deciding to automate but speed of identifying what to automate next, implementing it, measuring the result and moving to the next opportunity. The organisation that treats automation as an ongoing discipline rather than a one-time project builds a systematic capability for improvement that a competitor starting later cannot easily close.

The competition will not wait for you to be ready. Automate at the pace the market requires, which is faster than feels comfortable and slower than will eventually be necessary.

Key Takeaway: Automation is a competitive variable. The organisation that automates faster, more systematically and more continuously builds cost, speed and accuracy advantages that compound over time. The gap between the automated and the non-automated organisation widens every day the decision is deferred.

The competition is not waiting for you to be ready. Neither is the market.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Section: The competition will not wait

MarvinPro | December 2025

marvinpro.com

Design it in, don't add it on

Automation added to an existing process is a patch. Automation designed into a process from the start is an advantage.

The difference is not technical. It is a leadership decision about when to think. The leader who builds a process and then asks where automation could be added has already made the harder version of the problem. The architecture is set. The human steps are load-bearing. Removing them or replacing them requires rebuilding something that was never designed to be rebuilt. The automation that arrives as an afterthought must work around the decisions that were made without it in mind.

The leader who asks where automation belongs before the process is designed makes a different set of decisions. Not how to connect a machine to an existing human step, but whether the step needs a human at all. Not how to speed up the current workflow, but what the workflow would look like if it were built today with full automation capability available. The questions are different. The answers are different. The result is different.

This discipline applies at every scale. A small team designing a new workflow, a department redesigning an inherited one, an organisation building a new operation from scratch. In every case the moment of design is the moment when automation is cheapest to include and most consequential to get right. That moment does not come back. Once the process is running, once the team is trained to it, once the systems are built around it, the cost of changing the design rises steeply and the appetite for changing it drops accordingly.

The leader's job is to ask the automation question at the design stage, before the process hardens, while the decisions are still easy to make and the doors are still open.

Key Takeaway: The design stage is when automation decisions are cheapest to make and most consequential to get right. The leader who asks the automation question before the process is built makes a fundamentally different set of decisions from the one who asks it after. Design it in. The alternative is always a more expensive version of a lesser outcome.

Automation added to a process is a patch. Automation designed into a process is an advantage.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Section: Design it in, don't add it on

MarvinPro | December 2025

marvinpro.com

What cannot be automated

Knowing what to automate requires knowing what not to automate. The boundary between them is where the real work is.

The case that falls outside every routing rule. The customer whose situation does not match any standard response. The complaint that contains something the system flagged as routine but a person reading it would immediately recognise as anything but. The escalation that requires judgment about what the right outcome is, not just which process handles it. The conversation that needs to be had rather than the message that needs to be sent. These are not edge cases to be minimised. They are the work the organisation actually exists to do.

Automation handles volume. People handle complexity. The organisation that confuses these two functions will automate the wrong things and leave the right things undermanned. The routing rule that sends a distressed customer to a standard response queue because the system classified the contact type correctly but missed the context entirely does not save time. It creates a crisis that costs more to resolve than the original contact would have cost to handle properly.

The staff who remain once the automatable work is automated are not the staff who could not be replaced. They are the staff whose work requires what systems cannot provide. Judgment. Empathy. The ability to recognise when the process is the wrong answer for this particular situation. These are not soft skills to be listed in a competency framework. They are the core capability of the human layer of any well-designed operation, and they only become visible when the mechanical layer has been removed.

Automate everything that can be automated. Then invest in the people doing everything that cannot.

Key Takeaway: The boundary between what can be automated and what cannot is not fixed and is not always obvious. Finding it is an ongoing responsibility. The work that cannot be automated is the work the organisation is ultimately judged on. Staff it accordingly. Protect the human layer by removing everything from it that does not belong there.

Automate everything that can be automated. What remains is what your people are actually for.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Section: What cannot be automated

MarvinPro | December 2025

marvinpro.com

A real example

A customer-facing operation handling high daily contact volumes. Experienced team. Strong capability. And a significant portion of every working day spent on work the system could have done.

The leader looked at where the human effort was going and saw the pattern clearly. The work arriving at the team was not uniformly complex. Much of it was routine, predictable and repetitive. The people handling it were capable of far more than the work was asking of them. The operation was paying for judgment it was not using, because the work that required no judgment was arriving at the same layer as the work that required all of it.

The decision was to change where the human layer began. Not by reducing the team but by moving the point at which a person became involved. The work that could be handled without human judgment would be handled without human judgment. The work that reached the team would be the work that needed them.

The result was not a smaller team. It was a better-used one. The contacts that required human judgment received the full attention of people who were no longer depleted by the contacts that had not. The quality of the work the team was actually hired to do improved because the space to do it had been created.

The leader had not installed a system. They had made a decision about what people were for, and built the operation around that decision.

The automation did not reduce the team. It changed what the team was for.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · A real example

MarvinPro | December 2025

marvinpro.com

Chapter Outcome

Automate what can be automated. Not eventually. Now. The decision is the precondition, not the readiness.

Design automation into processes before they are built. The cost of designing it in is small. The cost of adding it on is large and the result is always a compromise. Build routing, responses and classification logic into the design from the start. Reserve the human layer for the work the logic cannot handle.

Pay attention to the boundary between what can be automated and what cannot. The work on the human side of that boundary is the work the organisation is ultimately judged on. Protect it by removing everything from it that does not belong there.

The competition is automating now. The staff are ready for it. The work that cannot be automated is waiting for the people currently doing the work that can.

Make the decision. Design it in. Move the human effort to where it belongs.

Automate everything that can be automated. What remains is what your organisation is actually worth.

Think Simple · Leadership · Here is How to Think · Vol 4: The Future · Philosophy 3: Automate · Chapter Outcome

MarvinPro | December 2025

marvinpro.com