The Quest for the IT/OT Engineer

Every industrial company today is looking for the same profile: someone who understands machines, networks, data, cloud, and AI. Someone who can connect a PLC, deploy a container, troubleshoot a VPN, and explain why the data pipeline is broken.

And... surprise, surprise... they can't find it.

Job descriptions keep getting longer. Unrealistic requirements keep piling up. They read like fever dreams: 5+ years of OT experience, strong background in cloud-native architecture, expertise in OPC-UA and microservices, CI/CD pipelines, real-time...

And hiring teams are left wondering:

"Why is this role so hard to fill?"

Well, because the IT/OT engineer, as we imagine it today, doesn't really exist.

And I would argue it can't exist.

It's a unicorn.

‍

The Wrong Fix: Retrofitting People

When companies realize they need this profile, the instinct is always the same: Train OT engineers in IT. Train IT engineers in OT. It can't be that difficult, right?

On paper, it makes sense. In practice, it rarely works.

OT engineers have spent their careers thinking in deterministic systems: PLCs, SCADA, fieldbus networks: environments where a 100ms delay is a crisis. Asking them to embrace a world where systems are only expected to be good on average is not going to work. That shift doesn't just require new skills. It requires a different timescale. And a completely different mental model.

IT engineers, on the other hand, are fluent in abstraction. APIs, CI/CD pipelines, horizontal scaling... this is their natural environment. But they've never had to debug a Modbus timeout at 2am on a production line that cannot stop. They don't feel the weight of physical constraints. They've never operated in environments that are, by design, offline, isolated, and hostile to change.

Both are highly skilled. But they are optimized for completely different environments. Trying to convert one into the other often creates mediocre results. You end up with cloud engineers who don't want to set foot on the factory floor, and OT specialists who copy-paste Docker commands they don't fully understand.

We are trying to retrofit people into a role that was never designed for them.

‍

The Third Discipline

Here's an uncomfortable truth:

"The IT/OT engineer is not a hybrid profile. It's a different discipline entirely."

And until we treat it as one, we'll keep failing to build it.

Even the way we talk about it is misleading! We say "IT/OT". With a big slash in between. That slash is doing more damage than we think. It implies separation. It suggests a bridge between two worlds. Somehow irreconciliable worlds.

But what if the problem is not about connecting two domains? What if it's about building a new one? Why not IT&OT — with a big AND in between? Or something else entirely?

In reality, that new domain already has a name. We call it the Edge. Or more precisely, the Industrial Edge.

Then why don't we call this new role an Industrial Edge Engineer? It does make sense, right?

In any case, the name doesn't matter. What matters is the idea:

We are not merging two worlds. We are creating a new one.

We once worked with a machine manufacturer to enable them to collect data from machines, analyze performance, and enable remote diagnostics. They did everything "right": Connected to industrial protocols, built a central data platform, deployed dashboards and analytics tools.

Months after the project was finished, adoption was minimal.

Why? Because no one could operate the system end-to-end.

The OT team could access the machines, but not the data platform. The IT team could manage the platform, but didn't understand the machines. And there was no one in between.

There was no Industrial Edge Engineer (or however you want to call it).

‍

What This Role Actually Looks Like

If this is a new discipline, then it needs its own skill set and mental models. Not a mix. Not a compromise. A purpose-built profile.

Let's try to make it a little bit more concrete:

• Understanding OPC-UA is not enough. You need to extract meaningful data, normalize it, and make it usable in a distributed system. But maybe you don't need to master the entire AWS or Azure ecosystem.
• Knowing Docker is not enough. You need to run containers on devices with limited resources, intermittent connectivity, and no guarantee of remote access. But maybe you don't need to operate large-scale Kubernetes clusters.
• Knowing networking is not enough. You need to deal with NATs, firewalls, segmented industrial networks, and environments where "just open a port" is not an option. But maybe you don't need deep expertise in load balancers or reverse proxies.

This is not IT. This is not OT. This is industrial edge engineering.

And the mental models are also different:

• You design for resiliency: because in industrial environments, the network will go down, and the system must keep running. At the same time, you design for interoperability.
• You think in physical context: a software decision is not just a deployment, it’s potential downtime and production loss. And still, you need to abstract the system.
• You embrace legacy: existing systems are not going anywhere. The job is to integrate around them and resist the urge to “just rewrite everything”.

I'm not proposing anything new here. We've seen this before.

A few years ago, development and operations were separate worlds. Then DevOps emerged, not as a combination of both, but as a new way of working, with its own practices, tooling, and mindset.

What we are seeing now in industrial environments feels similar. Not IT. Not OT. Something else. Maybe we can also call it IndOps (Industrial Operations)?

‍

The Way Forward

The IT/OT engineer should not be retrofitted. It should be designed. That means rethinking how we build capability from the ground up:

• New team structures: Small, embedded teams that live close to the operational environment and own the full stack from edge hardware to data pipelines.
• New internal career paths: Deliberately designed roles that don't report to IT or OT, but to a third technology leadership: the Industrial Edge Manager.
• New educational pathways: University programs and vocational tracks that treat edge engineering as a standalone discipline, not a specialization bolted onto either IT or OT programs.

This will create tension. IT departments will argue they can absorb this. OT teams will claim it as their territory. Both are wrong. And that tension is not a problem to solve — it's a signal! A signal that a third discipline needs its own space to exist.

Until we make room for it, we will keep searching for a unicorn that, by design, cannot exist.

‍

About Barbara

Barbara enables industrial organizations to deploy, orchestrate, and continuously manage distributed applications and AI models directly at the edge — where latency, bandwidth constraints, and data sovereignty cannot be compromised.

Built for complex environments with SCADA systems, PLCs, legacy protocols, and heterogeneous hardware, Barbara helps IT and OT teams move beyond pilots and scale secure edge deployments to thousands of nodes.

If you're working on similar challenges or exploring how edge platforms can support your industrial initiatives, explore more insights on our blog or get in touch with our team to continue the conversation.

Alternatively, you can also start using the platform today.