Where automation is real, and where it isn't.
Thinking formed in practice, published as part of the Bearing & Course Points of View library.
There is a version of the automation conversation that is genuinely difficult to have at the moment, because two very different things are both true.
Some forms of automation and robotics have moved. In logistics, warehousing, infrastructure inspection and structured service environments, real systems are carrying real workload. Not pilots. Not proofs of concept. Operations. At the same time, much of what dominates the broader conversation, humanoid robots, general-purpose physical AI, autonomous everything, remains years away from being deployable at the scale being promised.
Both things are true. That unevenness is the hard part. Because when the conversation is this mixed, it becomes genuinely difficult for senior leaders to know what to take seriously. The demonstrations are compelling. The vendor narratives are confident. The pressure to do something is growing. The real opportunities sit right next to the real limitations, separated by details that are easy to miss if you are not close to the technology.
A few years ago I spent time inside a programme where the technology itself was sound. The vendor demonstrations worked. The business case had been signed off. What had not been worked through was what would need to change in the operating environment for the capability to hold. Workforce, accountability, assurance, the shape of the service itself. By the time those questions surfaced, the commitment was already public and the room to redesign had mostly closed. The technology was not the problem. The conditions for it to succeed had never been built.
That pattern is not unusual. The underlying issue is that automation keeps being treated as a technology question, when it is really an operating model question. The technology question is whether the system works. The operating model question is where it fits, what it changes, who is accountable for it, and whether it can be sustained. Those are very different conversations, and the second one is where the real work sits.
Get that right, and automation becomes a genuine lever for organisations under pressure. A maintenance team that was losing ground on an ageing asset base starts to catch up. A distribution operation that was struggling to meet demand stabilises. A high-volume service that was failing the people who depend on it begins to respond at the speed they need. A pensioner receives a payment on time. A patient whose records are available when they arrive. A family whose application moves rather than stalls.
Get it wrong, and the consequences land somewhere equally real. A service that becomes less reliable rather than more. A workforce that loses trust in the organisation before the change is even complete. An operational risk that was manageable before, now embedded in a system that is much harder to unwind.
The move from capital-intensive procurement to as-a-service models is lowering the barrier to entry significantly. Organisations that would not have considered automation five years ago can now access it without the large up-front commitments that used to define these decisions. That is an opportunity. It is also a risk. Lower commitment often means less scrutiny. Decisions get made faster, sometimes below the thresholds that would normally trigger proper operating model design. By the time the consequences become visible, the capability is embedded and the optionality is gone.
The organisations that will do well out of automation over the next decade will not be the ones that moved fastest. They will be the ones that understood early that the technology was the easier part. The questions worth asking before any commitment are not technology questions.
What outcome are we actually trying to achieve? Which part of the operation is genuinely constrained, and why? Is automation the right answer here, or is it the easier answer? What has to hold operationally for this to work? What needs to change in accountability, capability and assurance before the system is deployed, rather than after?
These apply whether the organisation is a manufacturer, an infrastructure operator, a logistics business or a regulated service provider.
Automation does not prove itself through what gets deployed. It proves itself through what actually changes.