30 Jul 2026 · 9 min read
Industrial automation doesn't have an innovation problem. It has an incentive problem.
automation · meta · scada
Picture pitching Kubernetes to a bank in 2012. They'd hesitate, ask about compliance, and eventually come around. Now picture pitching the same thing to a chemical plant. They're still hesitating, and they will keep hesitating, and they are not wrong to.
The difference isn't sophistication. It's consequence. When the bank's cluster falls over, customers get a spinner and an apology. When the plant's control system does something unexpected, the failure mode can be a pressure vessel, a runaway reaction, or a person who doesn't go home at the end of the shift. Two systems, two completely different definitions of "acceptable risk," and the whole culture gap between IT and OT falls out of that one fact.
I've spent enough time around control rooms to have heard the lazy version of this story more times than I can count: automation engineers are dinosaurs, the industry is decades behind, they're scared of the cloud, they won't touch anything new. It's a satisfying story if you sell software. It's also mostly wrong. The industry isn't behind. It's solving a different optimisation problem, and it's solving it about as well as anyone could.
Software asks how fast. Automation asks how slow.
Consumer and enterprise software is tuned around a single question: how quickly can we ship? Deploy twenty times a day, catch the regressions in canary, roll back in ninety seconds, move on. The whole toolchain, the whole career-incentive structure, the whole culture rewards velocity. A bug in production is a Tuesday.
The plant floor is tuned around the opposite question: how slowly can we change this without breaking anything? A refinery doesn't deploy twenty times a day. It might have a planned shutdown once every two to four years, and everything that changes has to fit inside that window or wait for the next one. In between, the correct number of surprises is zero. Nobody on that floor gets promoted for migrating the historian to a microservices architecture. They get promoted for the plant running, quarter after quarter, without an unplanned stop.
Software · IT
Plant floor · OT
That's not conservatism as a personality trait. It's conservatism as a job description.
The KPI is a dollar figure, and it's enormous
Here's the number that reframes the whole argument. Siemens' 2022 True Cost of Downtime study put the cost of a single lost hour of production somewhere between about $39,000 and more than $2 million, depending on the industry. Automotive tops it at over $2 million an hour. Oil and gas comes in near half a million. Across the Fortune Global 500, unplanned downtime now burns roughly $1.5 trillion a year, and the per-hour figure jumped more than fifty percent in every sector Siemens looked at over just two years.
Now run the mental arithmetic an automation lead actually runs. A new platform might cut engineering time, might give you nicer dashboards, might unlock some analytics. Against that, weigh a non-zero chance of an unplanned stop at two million dollars an hour. You don't need to be timid to decline that trade. You need to be able to multiply. The maths says the expected cost of the downside swamps almost any upside the vendor is promising, and the engineer who declines the shiny thing is the one doing the sober risk calculation, not the one being a coward about it.
This is why "we'll evaluate it at the next turnaround" isn't a brush-off. It's the only time the risk is bounded.
Every change runs a gauntlet, and one question never makes the list
Watch a real change-request move through a plant and you'll see it clear a fixed set of gates, in roughly the same order every time. Is it safer than what we run now? Is it at least as reliable? Does it survive a power loss or a dropped network? Can whoever's on shift at three in the morning actually fix it? Has it proven itself somewhere that looks like us?
The thing worth noticing is what's missing. Nowhere on that list is "is it new," or "is it modern," or "is it exciting." Those are the only questions a lot of the technology press ever asks, and they're the questions the plant floor has quietly deleted from the form. Not out of ignorance. Out of two decades of watching which questions actually predicted an incident.
It's the downtime that's conservative, not the engineers
The convenient explanation for all this is age. The workforce is greying, the story goes, and old engineers fear new things. There's a real demographic shift underneath that. I just think people draw the wrong arrow from it.
The shift is real and it has a name: the Great Crew Change. More than a quarter of the manufacturing workforce in the major economies is now over 55. In oil and gas, roughly half the workforce is eligible to retire within the decade, and the overwhelming majority of manufacturers name the resulting brain drain as a top-tier concern. That cohort of thirty-year veterans is now walking out the door. (It's also exactly why I won't quote you a hard "median age" for automation decision-makers — nobody has a clean industry-wide number, and repeating a made-up one mostly signals someone learned the industry from a LinkedIn infographic.)
But look at what that experience actually buys. A reactor operator who's run a unit near its limits for twenty years is carrying knowledge that was never written down: how this specific plant behaves on a cold morning, which alarm is the one that actually matters, what the last "harmless" change broke back in 2009. When that person is cautious about a change, it isn't nostalgia. It's the most expensive risk model in the building, and it's about to retire. The caution and the value are the same thing.
So the honest version of the contrarian claim is this: the industry is conservative because downtime is expensive and consequences are physical, not because the people are old. The demographics amplify the caution; they don't cause it. A twenty-five-year-old engineer running that same unit, with that same two-million-an-hour exposure, would learn to be careful inside a month.
What the vendors actually sell
People think the industrial automation majors sell PLCs, HMIs, SCADA licences. They don't, not really. They sell confidence.
Nobody specs a Rockwell or a Siemens controller because the configuration software is a pleasure to use — anyone who's used it will laugh at the idea. They spec it because tens of thousands of plants have run it for twenty years and the failure modes are known, catalogued, and survivable. The installed base is the product. That's why so much of the world still runs DCS platforms designed in the late 1980s and 90s, and why fifteen-to-thirty-year-old control systems are completely ordinary rather than scandalous. A system that has run for two decades has, by definition, survived two decades of everything the plant could throw at it. No demo can compete with that evidence, because the evidence is time, and you can't fast-forward time in a slide deck.
This is also why startups keep bouncing off the sector. The founder walks in with a cloud-native, AI-driven platform and a deployment story measured in minutes. The plant manager asks one question: what happens to this when the network drops, or the power blips, or your company gets acquired and sunset in three years? If the honest answer is a pause, the meeting is over. The buyer isn't rejecting innovation. They're asking the only question that matters in an environment where the software has to outlive the vendor.
The real competitor is doing nothing
Here's the part most people selling into this space never internalise. When you pitch a plant, you are not really competing against the other vendor on the shortlist. You're competing against the option of changing nothing at all, and that option has an unbeatable reference: the plant has worked fine for eighteen years.
"Do nothing" has zero integration risk, zero retraining cost, zero new attack surface, and a two-decade track record. Beating a rival product is a feature comparison. Beating eighteen years of proof that the current setup keeps the lights on is a different and much harder sale, and it's the one every modernisation pitch is actually making whether the salesperson realises it or not.
AI on the plant floor runs into the same wall
The current wave of "AI will transform the factory" runs headfirst into all of the above. It might, eventually. But the first question from anyone responsible for the unit is not "how accurate is the model." It's "what happens when the model is wrong, and who's accountable when it is." An LLM that's right 95% of the time is a marvel in a chat window and a liability on a control loop, because the 5% is where the pressure vessel is. Trust on the plant floor is earned the same way it's always been earned: by running in an advisory seat, next to the existing controls, without causing a single incident, for long enough that the incident count starts to look like the twenty-year track record everything else on that floor already has. There's no shortcut through that, and the vendors who pretend otherwise are the ones who won't be there in three years.
The nearer-term, more honest path runs the other way round: make the control layer itself legible enough that software and AI can safely read it before they ever touch it. That's a slower and less glamorous story, and it's the one I find more convincing — it's roughly what happened when Ignition stopped behaving like SCADA software and started behaving like a platform you could actually build on.
Where the caution genuinely costs, and I won't pretend it doesn't
If I only argued the industry is right to be careful, I'd be doing the same lazy thing as the people who call it stuck, just from the other side. The conservatism has a real bill, and it comes due in a few specific places.
Security is the worst of it. "It's worked for eighteen years" is also the sentence that leaves a Windows XP HMI unpatched on a routable network, an air gap that quietly stopped being a gap a decade ago, and a control system whose entire cyber posture is nobody's tried yet. The same instinct that correctly refuses a risky feature deploy will happily refuse a security patch, and there the risk maths runs the other way. Aging hardware compounds it: when the spare I/O card is only available on eBay from a seller in another country, "reliable" has quietly become "fragile and pretending." And the Great Crew Change is a genuine threat precisely because the caution kept so much knowledge in people's heads instead of in systems anyone else can read. The industry's instinct to not write things down as executable, reviewable, versioned artefacts is going to hurt exactly when the people who hold it undocumented walk out the door.
So the caution isn't free, and the mature position isn't to defend all of it. It's to know which risks are the two-million-an-hour kind and which are the kind you're avoiding out of habit long after the habit stopped paying.
The industry isn't stuck. It's selective.
Put it all together and "stuck" is the wrong word. The plant floor adopts new technology on a delay, but the delay is a filter, not a failure. It waits until the thing has proven itself under conditions consumer software never faces: twenty-four-seven operation, physical consequences, regulatory scrutiny, and a downtime meter that ticks in the thousands of dollars per minute. Most software never has to clear that bar. The stuff that runs a refinery does, every second, for decades.
Which tells you exactly what the next winners in this space will look like. Not the flashiest AI demo, not the slickest cloud dashboard. The companies that win the plant floor will be the ones that make modern software feel as dependable as a twenty-year-old PLC — legible, auditable, boring in the best sense, and still running long after the vendor's Series A is a memory. That's the real problem worth solving here. It was never about building more impressive technology. It's about building technology a plant is willing to bet a shutdown on.
Keep reading
