How to start as an OT Manager with Gregory Grauwels

Richard Beeson wrote one of the two forewords to our IT/OT Handbook. Our book launches on 6 October, so having him on the podcast now felt like the right way to close the loop. What makes the pairing work is that our two foreword writers came at it from opposite ends. Richard brought the OT-first perspective, John Smart the IT-first one. Different starting points, different vocabulary, but… they end up in more or less the same place. Richard describes himself as “a chemical engineer gone bad”. In 1990 he joined a company called Oil Systems Incorporated (yes, that is indeed OSIsoft). About ten people at the time. He’d spend the next three decades there, eventually as CTO, watching the PI System absorb every technology transition the industry threw at it. The origin story of PI is a customer who wasn’t paying attention Before PI was a product, OSIsoft sold optimisation consulting to refineries. A customer asked them to prove the before and the after. So the team captured all the data, went back, and presented how much better things were running. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work.

This is an episode we were hoping for since we started this podcast 🙂 Gene Kim has spent twenty-eight years studying high-performing technology organisations and wrote best-selling books such as The Phoenix Project, The DevOps Handbook, Wiring the Winning Organization, and most recently Vibe Coding. He also runs the conference where the two of us first stood on a stage and tried to explain the IT/OT problem to a room full of technology leaders. Gene set the tone in the first minute: “I’ve been an admirer of your work and I’m so happy for you that you’re done with the book and get to share what you’ve learned with the rest of the world. This is like the perfect timing, as every critical infrastructure provider finds themselves having to do things that they’ve never been asked to do before in this age of AI and AI infrastructure.” Why a book about IT is set in a factory Willem asked the question we’d been sitting on for years. The Phoenix Project is a novel about IT… so why set it in a car parts plant? The answer goes back to 1999, when Gene read The Goal by Dr Eliyahu Goldratt. “It changed my life. It’s a novel about a manufacturing plant manager who has to fix his cost and due date issues in ninety days, otherwise they shut the plant down. I’ve never worked in manufacturing. I’ve read a lot of books about it, but it was such a riveting story just because you could see the problems.” His ‘goal’ (pun intended) was to write The Goal, but for IT. “To say that we copied the book is literally true. Same constellation of characters, same sort of plots, same number of breakthroughs. We deeply studied that book for over a decade getting ready to write it.” The ideas underneath DevOps did not originate in IT. They came out of Toyota, out of lean, out of the theory of constraints — Dr Steven Spear’s Decoding the DNA of the Toyota Production System, the work of Liker and Shook, Goldratt’s constraint thinking. Different traditions, same questions. How do you shrink batch sizes? How do you improve flow? So when manufacturing borrows from DevOps, it isn’t importing something foreign. It’s getting its own ideas back, with a decade of software-industry mileage on them. Gene’s own summary: “In the high performers, everyone is able to do what they need to do because they have independence of action, and that’s enabled because everyone has what they need, when they need it, in the right format, with the right decision rights and the right authority. And the opposite side — what showed up in The Goal — is that no one can do what they need to do because no one has what they need when they need it. It doesn’t matter whether it’s physical transportation of materials or the transformation of information.” The escalation tax Fun fact: our problem statement apparently landed harder on Gene than we realised. “One of the things that you helped me understand and concretise is that when you don’t have what you need, the only way to get it is by escalating. When you talked about how IT and OT only meet at the CEO level, this is terrible, because it means you are routinely having to escalate things all the time to get what you need in your daily work.“ And because nobody wants to be the person knocking on the CEO’s door every week, most of the escalations never happen. Problems just sit there. The dysfunction is invisible precisely because people are too reasonable to surface it. Gene remembers the first time he heard the framing, back when we submitted to the call for papers at what was then DevOps Enterprise Summit: “Imagine the DevOps problem, but it doesn’t go to the head of IT, the CIO. It has to go to their boss, and their boss’s boss, and maybe even their boss’s boss’s boss. I found that problem statement so vivid and beautiful — in a terrible way. You’re sort of doomed to dismal performance.” We can now admit the backstory: getting published by IT Revolution was goal number one from the moment we started thinking about a book. When the call for propos

We went a bit further than usual to talk to Bob van de Kuilen, because New Zealand is roughly the outer edge of what our time zones will allow 😀 Bob is the CEO and co-founder of Thred, and before that he spent twenty-five years in continuous improvement consulting: walking into manufacturing businesses, watching them fumble to measure themselves properly, and slowly realising that the real obstacle was never the sensor. It was context. Or rather, the almost total absence of it once you got past a folder structure. That’s the conversation we wanted to have: not “what is a knowledge graph” as a product pitch, but what ontology actually means once you’re standing in a plant, and why the word has suddenly gone from academic curiosity to something everyone in industrial data seems to be talking about. Before we start…Our next IT/OT Academy kicks off September 18 with an updated program. 🙋 Join the ITOT.Academy (new cohort in September) → And… have you already pre-ordered our IT/OT Handbook? If so, don’t forget to register to receive your exclusive bonuses. 📘 Pre-order the IT/OT Handbook now (+ claim the bonuses!) →

(Our topic, Our tone, Sponsored by Litmus.io *) Two years ago, roughly every second booth at Hannover Messe had the word “AI” on it. This year the tone has shifted. Less about the layer you buy, more about the outcome you’re trying to deliver. That shift is what Vatsal Shah, co-founder and CEO of Litmus, came on the podcast to unpack. It’s also the first time he’d talked publicly about how Litmus rethought its own strategy around this idea. Coming from the CEO of one of the more established industrial data platforms, that’s worth paying attention to. (If Litmus is new to you, we covered them earlier with COO John Younes in our Industrial DataOps series, and wrote about their approach to consolidation in Fighting Entropy.) The $1 trillion question nobody’s asking Here’s the observation that reframed Litmus’ entire 2025 strategy. “If you look at the manufacturing software market, it’s what, like $15 billion? How much is the manufacturing labour market? A trillion dollars plus. It’s a hundred times the software market.” — Vatsal Shah Vatsal’s numbers, not ours, but the ratio is what matters. Every industrial data vendor has been fighting for a share of that small software pie. Meanwhile the vastly bigger prize sits behind a wall we’ve barely tried to cross. To be clear: this isn’t about replacing labour. “In no shape or form can AI replace human workers right now,” Vatsal said, and we agree. We’d add something we’ve argued for a while: in most manufacturing environments today, the constraint isn’t too many operators, it’s not finding enough skilled ones. So the question isn’t “how do we cut headcount?” It’s “how do we make the people we have more effective?” Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work.

(Our topic. Our tone. Sponsored by Cumulocity *) It’s episode 50 (🎉) of the podcast, and we’re only now getting to IIoT platforms. We sat down with Jürgen Krämer, Chief Product Officer and Managing Director at Cumulocity. Cumulocity is an IIoT platform with currently more than 25 million connected devices, three billion messages processed per day, and a roster of customers that includes wind energy operators, healthcare devices, and crane manufacturers. Jürgen has been in the IoT and analytics space for over 20 years, which means he’s lived through every wave of the hype cycle and that made our conversation another super interesting one! He also knows that the term “IoT” is notoriously elastic: it gets applied to everything from smart lawnmowers to offshore wind farms, and that ambiguity is a genuine problem when you’re trying to make a technology decision. So time to demystify some concepts around (I)IoT Platforms! IIoT Platform vs Historian We’ve written before about the power of the process historian, and in a typical manufacturing or process plant, the historian is genuinely well-suited. It is designed for high-density time-series capture in a controlled, physical environment where you own the network, the devices are close together, and the architecture is well understood. The moment you move to distributed assets out in the world: in customers’ facilities, on wind farms, on construction sites, in buildings, data centers, and so many others… the picture changes entirely. Because in those cases, you don’t own the network. You have no physical access. You’re managing connectivity across 30,000 turbines in a dozen countries. Firmware updates need to happen over the air. Security is paramount because the device is sitting inside someone else’s infrastructure. That is where the IIoT platform becomes the right tool. As Jürgen puts it: “You need to connect and manage devices you don’t control, in environments you’ve never seen, at a scale that makes manual management impossible.” The M2M → IIoT → AIoT evolution Time for a history lesson! The first wave, around 2010, was M2M (machine-to-machine). It was essentially about connectivity: get the device online, manage the firmware, enable remote access. Useful, but narrow. The IIoT era, roughly 2015 to 2024, added the layer above: dashboards, analytics, edge computing, application enablement. Operations became more optimised, but the work was still largely human-centric. An alert would fire, and a technician would spend hours diagnosing the situation (reviewing log files, cross-referencing documentation, forming a hypothesis). AIoT (what Cumulocity now positions itself as) is the next step. The vision is that the agent does the diagnosis. The technician receives a package: probable bearing failure on Pump 4, replacement part ordered, repair guide attached, shutdown recommended at 14:00, awaiting your approval. The human is still in the loop, but the cognitive labour of diagnosis shifts from the person to the system. We’ve used the term “virtual operator” in previous articles. This is what it could look like in practice (obviously given the availability of enough data, context and the right understanding of the physical reality!) The part most people still skip: Context Context is the most important thing to get right today. It’s the answer to scaling, it’s the answer to UNS, it’s a necessity for AI. And thus we’d encourage you to slow down here. Every AI initiative in industry eventually runs into the same wall: raw telemetry is not enough. A value arriving every second from a sensor labelled “Reg_004” means nothing to an LLM, and very little to a human who didn’t configure that tag. Feed that data stream to an AI agent without context, and you will get hallucinations. Jürgen’s team has run this experiment directly: same query, without and with a semantic layer. Without it: plausible-looking KPIs that are simply fabricated. With it: accurate, actionable results (take a look at the re