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 proposals came in, we brainstormed for the better part of a day about what on earth we could tell a room of technology leaders who had never expressed any interest in manufacturing.
The Art Smalley question
The best story of the episode, and the one we keep coming back to.
At the Enterprise AI Summit in Charlotte on 7–8 October, one of the speakers is Art Smalley — the second American hired by Toyota in Japan, brought in by the famous John Shook of NUMMI fame. Gene describes him as possibly the most switched-on vibe coder he has ever met. He’s in his sixties.
Why? Because in 1986 Smalley was doing engine design at Denso. Extremely high-precision work. And central IT was never going to help him.
“He was a person on his Toshiba laptop, using dBase IV to solve all the frontline problems. He’s a technologist, not classically trained in computer science like many of us. But he was without doubt helping solve problems on the front line.”
Then Gene asked the question that reframes the entire industrial AI conversation:
“How many Art Smalleys are there in the world, in manufacturing flows right now, who have problems that need to be solved? And IT is never going to — they’re just not important enough to make it onto the priority list. What I find very exciting about AI is that Art Smalley is evidence that you don’t have to be an Art Smalley. Any frontline worker can solve their own problems.”
He also pushed back gently on treating this as a small thing. Toyota moving manufacturing to the United States and bringing its entire supply chain with it could not have happened without people like Smalley building the tools to manage flow and replicate a supply chain that did not yet exist.
Writing a Book was more work than we thought
Gene turned the interview around on us near the end and asked what surprised us most.
David’s answer: the naive assumption that you start writing and the words follow, and half a year later you have a book. The reality is that the moment you write things down, you discover you’re missing information, that you’re not sure about things, that some things need validating and others need more time to digest. Going from the first page to the last page, in order, exposes the gaps in your own thinking. That turned out to be worth more than the book itself.
Willem’s answer was more practical and more painful: he writes best at six in the morning and does not enjoy waking up early. And beyond that, knowing when to stop. Writing is a bit like painting — you start with a general idea and discover things along the way — but it’s genuinely hard to say when a thing is finished. You need an editor to tell you. (Thanks, Anna and Leah.)
The substantive learning was about the cooperation models. We started out assuming some forms of IT/OT interaction were simply inferior to others. We finished convinced that every pattern is a good pattern within the right context — and that the real work is describing the context properly.
Gene’s line on this is one we’ll be stealing:
“In order to be able to write clearly, you have to be able to think clearly first.”
And then, on what a book is for:
“Methodologies and books have in common the ability to connect all the dots together — and that often means you have to name all the dots first. My heartiest congratulations for writing a book that makes people see a problem they have that they might not have recognised before, and more importantly, gives them hope that there’s actually something you can do about it.”
Final thoughts
Somewhere in the middle of this conversation, Willem said the thing that ties it all together: manufacturing and IT are both just people trying to solve problems. One with software, one with machines.
Gene’s reply was immediate:
“It’s always about people trying to solve problems. And to what extent are we creating the conditions that enable people to solve problems well? We can make it very, very difficult, or we can do it very well. That’s what we all have in common — trying to make it easier and explainable, so that people can solve problems well.”
Twenty-eight years of research, three decades of industrial digitalisation, two very different books, and it comes down to the same sentence.
Thanks for listening.
Stay Tuned for More!
🙋 Join the ITOT.Academy (2027 cohorts now online) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →
Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.
🚀 See you in the next episode!
Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:
Spotify Podcasts:
Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions.
