IT/OT Cooperation Models: A Field Guide (Part 1)
Patterns and Anti-Patterns on IT/OT Cooperation.
After publishing our IT/OT Cooperation Models article, we had no clue it would become so immensely popular. But the article doesn't help you when you want to move to a better cooperation model.
There is no fixed recipe for your specific situation. Instead we can help you with some (anti-)patterns to move away from a siloed organization to a more responsive one.
Up this week: What not to do.
Make sure to subscribe to be the first to receive Part 2 with things you should do.
Converging two organizations is not a management decision
Let’s directly dive into the first anti-pattern:
Anti-Pattern 1: IT/OT Convergence as a top-down decision by management
When we have a desire to converge organizations, we are not engineering a new production line. Quite the contrary, we are now dealing with socio-technical systems where both IT and OT: (1) employ people with specific capabilities, (2) follow their own processes, (3) use (partially shared) technology and infrastructure, (4) have their own goals and (5) share certain cultural assumptions and norms.
We already covered the bureaucratic (and totally outdated) idea that thinking and doing should be separate. It was a way of working from the years when the smart boss told the workers what to do right.
However, most management teams today still ‘accidently’ apply this anti-pattern. They don't do it consciously because it is so deeply ingrained in how many ‘bosses’ still think and act.
When someone with a typical engineering or operations background gets promoted two things can happen: (1) they apply their old way of thinking onto digital projects (problem! 🙁) or (2) they are real leaders, open up to other points of view and create room to experiment, grow and be successful (opportunities ahead! 🎉).
Converging two organizations (or maybe you only want to make them work better together) is not just about scaling technology and building value-added applications together. We need to organize ourselves in a way to deal with diversity without getting stuck in complexity.
IT/OT convergence has more to do with how we are going to:
Improve our technology so that we can work smoothly with IT and OT data without having to overthink it (and we are far from there)
Adapt our ways of working to deal with the complexity of building and interconnecting digital systems without drowning in governance and silos that will stifle innovation.
Divergence might happen sooner than you think
When done wrong, efforts to converge will quickly lead to quite the opposite: divergence.
By default people will prefer to work within their own sphere of comfort. Often it’s because ‘they understand the problem better’ or ‘we need to go fast’ . The truth though is often that collaboration is hard and uncomfortable. As they progress, friction with the other side increases and things start to escalate even more.
Anti-Pattern 2: IT/OT Convergence is about making OT become more like IT (or vice versa)
IT/OT convergence can be misinterpreted as if OT will become more like IT (or vice versa: IT will become more like OT). People who believe this anti-pattern is something to really ‘go for’ will start making claims towards the other: “We know this better because…” or “Our technology is better/more advanced because …”.
This is not going to work, on the contrary, this insinuates that one is better than the other and that will only create resistance, people will start tuning out and eventually will leave your organization.
Side note: If innovation is going to come from anywhere, it is IT. OT is far too little engaged in adapting new ways of working and their scale/talent pool is many orders of magnitude smaller. If you want to know where OT is going in a couple of years, look to IT (but not because IT is "better").
When claims are being made in one or both directions, friction will lead to mistrust and divergence is waiting around the corner.
You do not want to end up in this state for many reasons, not only because your organization will be dead in the water, but mainly because at this point in time your best people will already have quit.
Make sure to subscribe to be the first to receive Part 2 with things you should do.
Continue reading in Part 2:
The images in this post are based on work at devopstopologies.com - licensed under CC BY-SA.
Further Reading
Shareable image:
