Full Circle: The Gene Kim Interview

Speaker 1 (00:00) Very, very special guest today. Speaker 3 (00:02) I've been studying high-performing technology organizations for 28 years. Why did you write a book about IT set in a manufacturing plant? Speaker 1 (00:13) There's a book I suspect you've heard of called The Goal. It changed my life. I mean, it's a novel about a manufacturing plant manager. Who has to fix his cost and due date issues in 90 days, otherwise they'll shut the plant out. 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, at the right time, in the right format, with the right decision rights and the right authority to do what they need to do. And then the opposite side that we tried to describe in the Phoenix Project was absolutely what showed up in the goal was, Speaker 2 (00:52) Welcome to the IT-OT Insider podcast. Very, very special guest today. Willem, who did we bring? Speaker 3 (01:03) We finally have Gene Kim in our podcast. I didn't think I was going to say that a couple of years ago, but look, here he is. So welcome, Gene. Speaker 1 (01:14) I'm so glad to be here. And by the way, I've been an admirer of your work. And I'm so happy for you that you're done with the book and they get to share what you've learned with the rest of the world. And for reasons I'll discuss later, I mean, I think, boy, it is like the perfect timing as every critical infrastructure providers find themselves having to do things that they've never been asked to do before in this age of AI and AI infrastructure. Speaker 2 (01:40) I couldn't have said it any better. However, maybe for those, because there will be people who don't know you yet, Gene, although you sold, what, like a million copies of the Phoenix Project, I don't know. Anyways, especially in our world, in the manufacturing world, you won't be known to everybody, so why don't you kick off with a short introduction so people know who they're listening to. Speaker 1 (02:06) Yeah, for sure. I've been studying high performing technology organizations for 28 years. And that was a journey that started back when I was the CTO and technical founder of a company called TripR and the information security and compliance space. And so our goal is always to understand like how And so in my journey, I wrote a book called The Phoenix Project that you had mentioned, you know, the DevOps Handbook, which I think is so much like The OT IT transformation, but it's a smaller silo that often technology leaders have to do when you have developers and operations constantly at odds with each other. And I think when I first learned The only place where IT and OT meet is literally the CEO, which is what we know doesn't cause the greatest, or not the conditions that enable great outcomes for anybody. As part of that journey, in fact, where I met you was I've been running a conference for technology leaders, originally called DevOps Enterprise, then Enterprise Technology Leadership Summit, and now Enterprise AI Summit, where the goal is just to get experience reports from technology leaders, You know, here's our organizations, here's how we compete, here's a business problem we set out to solve, here's where we started and why, what do we do, tools and techniques, objective evidence of value set by other people, right? And problems that still remain. And so that's actually where I, Learned about your work after reading about your work on LinkedIn many, many years ago. And so I'm just, my heartiest congratulations on completing the book and making a difference to an industry where this really matters. You know, like this Speaker 2 (03:53) is just a small sidetrack, but the two people who are actually most happy with us having finished our book are our wives. Speaker 1 (04:04) Yes, in fact, that resonates with me. In fact, when you met my wife, Marguerite, and my boss, the CEO here at IT Revolution, I think she would deeply resonate with that. I would say very few summer holidays where we took off where I wasn't working on a book. That's almost over 20 years. And one time for the Vibe Coding book that I did with Steve Yegi, I think I started it without asking her first, which got me in so much trouble. Speaker 3 (04:36) She's been a phenomenal supporter. So yeah, thanks to Katrine and Tine in that case. Probably they won't hear this, but thanks anyway. Okay, now Gene, I definitely resonate with what you said about similar problems, because the reason that David and I were attracted to the ideas in the Phoenix Project, I think one of the books you wrote, is because although it is 100% based in IT, We just saw one-on-one the similarities with manufacturing. And on top, and that brings me to my question, it's set in a car manufacturing plant, in a car parts manufacturing plant. So can I ask, why did you write a book about IT set in a manufacturing plant? Because for us, it's the other way around. Tech are the ones with the advanced ideas. Speaker 1 (05:32) Yeah, and actually, I should have mentioned this before. For people who haven't heard of The Fiends Project, there's a book I suspect you've heard of called The Goal, written by Dr. Eliyahu Goldratt. And especially in plant manufacturing, across every industry, it's taught in almost every MBA curriculum. It's taught in almost every operations research curriculum. And I read it in 1999. It changed my life. I mean, it's a novel about a manufacturing plant manager who has to fix his cost and due date issues in 90 days. Otherwise, I shut the plant down. And so I've never worked in manufacturing. I've read a lot of books about it, but it was such a riveting story to me just because you could sort of see the problems. It to be one of the three sort of main reasons for the popularization of lean, right? So the toy depression system that was actually deeply studied by Dr. Stephen Spear, who was my co-author on the Wiring the Winning Organization book. So he wrote the Decoding the DNA of the toy depression system that came out in 1999. I had read that in 2000, blew my mind. The other is the lean movement, often sort of captured by Dr. Leiker, Dr. John Shook and so forth. Then there's another group and the theory of constraints, but I think they're all in many ways seeking the same thing, right? How do you shrink batch sizes? How do you improve flow? And so really our goal for writing The Phoenix Project was write the goal, but for the IT context. And to say that we copied the book is literally true. I mean, it's the same constellation of characters, same sort of plot, same number of breakthroughs. I mean, we deeply studied that book for over a decade. You know, getting ready to write the book. In fact, my co-author, George Spafford and I, we actually took a Constraints Management course, a series of Engineering Management graduate courses, three of those over, I can't remember, 2004, by one of the kind of disciples of Dr. Eliyahu Goldrath. So anyway, sorry, long story. Speaker 2 (07:41) No, it's super interesting. Speaker 3 (07:43) So just in case the people who are listening and reading about this, you definitely, these ideas about DevOps, they're just not born out of IT worlds. You really feel the lean essentials really built in there. So it's not so weird that they inspired us in the end, David. Speaker 1 (08:05) Yeah. In fact, just to react to that, I mean, I think really what I've learned over the book came out in 2013. I mean, I can't tell you just how much I've learned since then, but I mean, I think kind of the big surprise, especially working with Dr. Stephen Spear, is really just kind of two extremes. There's, you know, in the high performers, you know, you really have 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, at the right time, in the right format, with the right decision rights and the right authority to do what they need to do. And then the opposite side that we tried to describe in the Phoenix Project was absolutely what showed up in the goal was no one can do what they need to do because no one has what they need when they need it in the right format. And so it doesn't matter whether it's Physical manufacturing processes of transportation of materials or the transformation of information and the achievement of goals through technology. So those things are absolutely universal. And I know those are problems that you attack directly head on in your works and in your great book. Speaker 2 (09:10) It's very interesting because for us, this was something which we discovered while doing it. It's not that we read the Phoenix Project. And I went like, oh yeah, now we're going to take those concepts and apply them to the IT-OT world. It's something which just started happening in, I don't know how many years it took us between reading the Phoenix Project and other books, like Team Topologies, for example. Team Topologies is also highly influential. Speaker 3 (09:44) I think maybe something people also don't know, like IT Revolution, The publishing company where we're publishing also published several other books that also inspired us talking about stuff like how do you cooperate, which also heavily influenced one third of our book, which is about discussing just about cooperation because it's just that important. Speaker 1 (10:08) Yeah, in fact, I think one of the things that you helped me understand and concretize, right, is that When you don't have what you need, when you need it, and so forth, the only way to get it is by escalating. And so when you talked about how IT and OT only meet at the CEO level, this is terrible because it means that you are constantly, routinely having to escalate things all the time to get what you need in your daily work. And I think the fact that the information flows are so disconnected was just kind of a wonderful description and embodiment of when you're sort of wired the wrong way. Speaker 2 (10:42) Yeah, no, exactly. And because nobody wants to be that guy who goes to the CEO every day, what basically happens is you only escalate when it's really, really, really needed. Speaker 1 (10:58) Already too late. Speaker 2 (11:01) Absolutely. Now, so here is a bit of a backstory. I don't know whether we actually talked about it in the last years, but so when the idea came, our idea came to write the IT OOT Handbook, this one, I have it here in my hands, early copy though, but I have it here. So when we had this first idea of starting to write a book, like, Getting published by IT Revolution was absolutely our number one goal to reach. So we were thinking like, but how are we going to get in that club? How are we going to convince you and your wife and the other people in the group? So when the call for presentations for ETLS Two years or so ago, yeah, two, no longer, two and a half years ago. Yeah, Speaker 1 (12:02) three years ago. Speaker 2 (12:03) Maybe already three years ago. So when the call for proposals came in, like me and Willow went like, this is like, This is our chance. We have to come up with something. So we really brainstormed for, I don't know, half a day, a day. What on earth are we going to tell this bunch of people which we don't know yet and we don't even know whether they are interested in manufacturing? And that's maybe an interesting question to you because then you came back to us, Jean. With this genuine interest, and we went like, wow, we didn't really know the manufacturing, the critical infrastructure world was also something which is, I would say, from your perspective, interesting to take a look to. So what was that thought process? Speaker 1 (12:50) Yeah, interesting. I mean, so one of the things that I don't talk a lot about, but one of the things that in my late tripwire days and early afterwards, I actually thought I wanted to be a board director. And now I realize that's like the worst job for me. Yeah, I got trained as a NISD, whatever the certification is to go through that, so you have to learn about financial reporting and all this stuff. I mean, it was interesting, but ultimately not a good fit for my temperament. And so I got involved with a bunch of people who were in the energy sector and I learned a lot about the IT-OT divide and the fact that you have critical infrastructure where you have SCADA devices that are impossible to update. I remember that was almost 15 years ago and over the years I got involved with some people who Wanted to see to what extent could DevOps be used, this kind of fast flow. We don't deploy once every five years, we do it multiple times a week, or maybe multiple times a day, or maybe even Amazon 136,000 times a day. Would that be possible to do in the OT domain? And that was my first real appreciation for just how difficult these things are to update. Sometimes even physically impossible updates. And so I gained a bit of appreciation, a little bit of appreciation for it. And so like when I saw your call for paper submission come in, it was instantly familiar and I actually want to learn more. And I remember very vividly our first conversation when you said, imagine the DevOps problem, but it doesn't go to the head of IT, the CIO. It has to go to their boss and the boss's boss and maybe even the boss's boss's boss, right? To be able to go down the next silo, which is around the manufacturing organization. I just found that problem statement so vivid and beautiful in a terrible way. But I mean, the implications of that is that you're sort of doomed to dismal performance. And so, yeah, I was very grateful for you submitting because that sort of began our adventures together. Speaker 2 (14:55) Yeah, absolutely, absolutely. And then one thing led to another and here we are with this thing in our hands. The manufacturing world is definitely a world where the ideas of bringing in flow, bringing in these new ways of working, et cetera, has always been a problem. What we see now is that problem is now getting intensified with AI for many reasons, but I think the most important one is nobody wants to get left behind. You also want to be that company who invests in AI, who tries new ways of developing, new ways of finding process optimizations, Speaker 1 (15:40) et cetera. Yeah. In fact, I have a story, two stories to tell you, right? I mean, I think one, so I was thinking about you guys when I was, I got a tour of a satellite manufacturing plant. And I mean, it was crazy. I can't go into too much detail, but let's just say there were scores of satellites that were being developed. And so these were, you know, not multi-billion dollar satellites, but, you know, many of them, you know, smaller, right? Like tens of millions of dollars. And it was interesting because they had totally overhauled their MRP systems and they were using off-the-shelf commercial software and they were using every bit of technology advantage that they could get. And it was done in conjunction with and in cooperation with the central IT organization. That was a wonderful example where it wasn't manufacturing stuck in the dark ages. That was number one. Number two is, oh my gosh, yeah. And I wrote a book called Vibe Coding with Steve Yeggi. So he spent 20 years famously at Amazon and Google. And I met him in June 2024. So that was almost two years ago. It was crazy. And so we wrote a book together. The book forward was by Dari Amadei, the co-founder and CEO of Anthropic. I fell in love with it early in terms of coding with AI. And I think I got to see the firsthand exponential increase in the need for tokens. And we need more electricity, we need more data centers, we need more. And as I got to meet some of these energy suppliers, and I've learned that some of them They can't even, they're getting incredible amounts of money, right? But they can't spend it fast enough because, and so these data center projects are years late. And so the bond like is not money, they have the money, they can't get shovels in the ground. And so it's just amazing to see What these pioneering energy companies are doing to get to a point where they can actually deliver what the world needs, which is more gigawatts of energy to make these data centers churn out more tokens. I know it's a little bit political in some areas, but it's something that nothing upsets me more when I get a rate limit from the Frontier AI lab saying, you exceed your rate limit because we don't have any more data setting capacity. Does that resonate with you, with what you're seeing? Speaker 3 (18:07) I also don't like that message, but I think even in compute, just some places are constrained in terms of network of electricity, and they're like, I'm sorry, we're gonna deploy, the cloud is full. Speaker 1 (18:18) Right, the cloud is full. Someone told me that in the UK, you couldn't get more compute, I'm like, Bullshit. Speaker 3 (18:25) Impossible. No, actually, no. Some places, some regions, you cannot get more compute, for example. Speaker 1 (18:29) Absolutely. No, I thought firsthand, pairing with the developer there, it was like, we ended up going to US, I'm sorry, we went to Sweden 1 because they had so much more capacity than the UK South. I was stunned. Speaker 2 (18:40) The downside of that is also, and maybe also a link to output outcome service, so the new book by which is just released, if I'm correct, One of the downsides of this thing is like we spin up so many agents and we let the thing do stuff and we let it burn tokens and we try to engineer new ways of, you know, whatever, but then we're stuck with all these new outputs and like, and what next? Speaker 1 (19:18) Yeah, it's funny you bring that up, and just very briefly, Swix, he's famous for Latent Space, his Code AI Summit, I learned so much from his podcast and stuff, he ran a contest called Kill My SaaS, software service, and he offered a $10,000 prize to replace the SaaS software that was costing him $40,000 a year, right? And when I learned Saturday morning, we're supposed to take a weekend, right? And I kind of looked in the morning, I found out it was a conference call for presentation software, which is how we met. And so having over the last 12 years run 24 plus conferences, it was run on, I don't talk about it very much, but it's like we use five software packages that I mostly hated. I mean, I just hated them. And I wrote a new front end for one of them by scraping all the submissions from this not bad website, but as terrible as a reviewer. And so, I mean, I was all in, and he extended, it was supposed to be a weekend, kill my SaaS on a weekend, and he extended to seven days, and my wife was not very happy because I spent every waking hour, going to bed at 4 a.m., 5 a.m., trying to replace it, and I killed our, not just one SaaS, but like three of them, right? Our CFP process, our scheduling software, and some things that we use for social media. Anyway, so, And the biggest challenge was just like, once coding is free and instantaneous, you know, the bottom is everywhere else is merging and integration and then deployment and then feature specification. And it's just, it was a very challenging Mind-blowing, weak. So does that resonate with anything in your world of IT-OT? Does any of that resonate with you? Speaker 3 (21:09) I think another good example, with AI it's becoming easier than ever to get to that software, to create synthesis of information that you would never combine together in a reasonable timeframe. I'm just thinking about the alpha folds, for example. I like to look at the link between AI and the physical world. AI is not going to make a chocolate bar, but where does it sit on the road to making that chocolate bar? With AlphaFault, suddenly you have hundreds of thousands of protein structures available. Now, I don't know how many years it's going to take all those biochemists to make applications from that. The deluge of information is so much. Where do you start? How do you process it? The bottleneck is moving away from IT, from the data side of things. And that brings it back to manufacturing. Speaker 1 (22:09) Manufacturing the physical side of things. Yeah, in fact, I mean, one, there are some smart people who say kind of as the cost of software delivery goes to zero, you know, essentially all the real constraints of the organization now get elevated. So it's not about moving, what is it? Moving electrons is actually moving atoms, right? That is really where value is created. And I remember listening to a podcast of Cognitive Revolution by Nathan LeBenz, and he was actually interviewing a bunch of people in... Sort of alpha-fold and adjacent is, I think, if I hear correctly, there's a lot of the pharmaceutical R&D processes that involve a lot of wet work, basically stuff in the laboratory where you're actually doing pipette work and whatever, that's vanishing because you can actually do a better job in simulation and reduce the search space for novel molecular interactions. Apparently, it's happening very fast in certain domains. Speaker 2 (23:08) Yeah, you now even have body parts on a chip, right? So where you can actually start simulating the effects of certain drugs. Yeah, chip-based, super, super interesting. Now, if we look to the, let's say, the physical manufacturing world, the process world, we see... But mainly two very big domains coming in our direction. There is obviously the domain where we're using Let's not use the word AI, let's just use the word clever algorithms, whether that's simple mathematics or very advanced whatever neural networks to optimize our processes, to run our processes in a better way, faster, using less energy, better product quality, less scrap, maybe even partly autonomous. That side of things, Has been in development for the last decades and it will continue to grow. There might be a small uptake in that. There are new ways of working, but there is not really like a very big step change in my opinion. But then there is this other side where we can leverage the generative AI capabilities we now have. And this is really, really interesting because Willem already mentioned it. Starting to use knowledge, which is spread across an organization, and trying to use the parts to understand that knowledge to do clever things, to help operators, to help technicians. So that's the domain. Another domain obviously is the coding part, where OT engineers also do lots of coding. Actually, I don't know, we did an interview with somebody who said like, yeah, aren't you afraid that's, you know, also from people tell about how AI is gonna take our jobs. Now, in our world, we are unable to find enough skilled OT engineers, so we very much welcome these tools to make our work faster, easier, et cetera. Those are, I think from my opinion or from my perspective, the two big domains. And I think if we just look at what generative AI is now bringing to us, that's a massive new domain to tap into. Speaker 1 (25:42) Oh my gosh. In fact, it triggers a memory. So at the Enterprise AS Summit in Charlotte, that's on October 7 and 8, there's a gentleman there presenting named Art Smalley. And so when I was introduced to him, it fired a memory. I had read his book and... He is probably the most switched on vibe coder I've ever met. I mean, so he's in his, let's say, 60s. And he was the second American to be hired in Japan at Toyota. So he was hired by the famous John Shook. So John Shook was in This American Life about the famous NUMI joint venture between Toyota and General Motors. So John Shook hired Art Smalley. It was very baffling to me because how does someone like him become a really amazing vibe coder? And it turns out that in 1986, he was doing engine design at Denso, which was the power plant spin-out from Toyo. It's a very high precision work and central services, IT would never help them. And so he was a person on his Toshiba laptop, using Dbase-4 to solve all the frontline problems. And so he's a technologist, not classically trained in computer science like many of us, but he was without doubt helping solve problems on the frontline for everything that involves not One engine every 55, not one complete car every 55 seconds, but high precision, handcrafted, beautifully designed engines, high performance. And I think with the vision you paint is how many art smallies are there in the world who are in manufacturing flows right now where they have problems that need to be solved, right? And IT is not ever going to They're just not important enough to make it onto the priority list. And so I think 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. And I think that's just very, very energizing. That's what he's going to be presenting on. I love that story that you're telling me because I know Shadow IT gets a bad rap. Speaker 3 (28:11) Like, oh, Shadow IT is evil. But honestly, those people are the ones on the front line. They know the problems that need to be solved. And just like IT, they're engineers. They're not afraid of technology. They love it. They like to geek out on stuff like that. And they'll learn how a database works. And I'm pretty sure that they'll also learn quickly how AI works to generate code. So I think the next thing is going to be Shadow AI. And if done properly, I just think it's going to be great. Speaker 1 (28:39) Oh yeah, in fact, I will even one-up that. I don't think the story he's going to share is for Toyota to move manufacturing and start that up in the United States and bring their entire supply chain with them could not have been done if it weren't for people like Art creating tools to manage flow and replicate a supply chain that simply did not exist before So it's difficult to overstate the impact of the work that he and others did. Speaker 2 (29:15) It's a bit like, I'm not sure whether I, I think it's something you wrote down in writing The Winning Organization, but like, if we would just use the procedures, the things, you know, which are already written down, like, this is the way you're going to do this. This is the way you're going to solve this problem. It's not gonna happen. You need people like him to color outside the lines. Speaker 1 (29:41) Yeah, I think it's a bit nuanced, right? Yeah, I think what I learned out of the Toyota production system is, I still remember when Steve Speer wrote, you know, what's magical about the Toyota DNA is that you have a community of scientists all working together to solve problems every day, right? And so, you know, part of it is really the application of the scientific method where you explicitly state hypotheses, You routinely experiment with things that can improve it, right? And then, you know, it's like an AI, we call it hill climbing, right? So you want to climb the hill to find the Optima. But once you find the local Optima, you stick to it, right? You want to sort of make sure that the methods are being widely known and used everywhere. So it's not to starve innovation, it's really to enable innovation. And so exactly what you're saying. And it's, as Willem said, Speaker 2 (30:30) that's also why our third pattern in the book, our third cooperation pattern in the book is called Shadow IT. And to probably the surprise of many people, we indeed don't say it's a bad thing. There are things to consider though, like you can't keep on running Shadow IT for years without, that's not gonna happen. But it is actually really powerful when done right. Speaker 1 (30:56) Yeah. And I think what you do so well is, and what I've, it reinforces something I've learned, which is the people best able to solve problems are the people doing the work, right? Always. Someone who is like eight levels up in the organization, eight levels down, right? And there's actually no direct path between the, in fact, Kent Beck, you know, famous in the software space, he said, it's always been about, you know, so he created extreme programming, he was one of those agile signatories, he created developer unit testing, he said it's always about Two people, the person who has a problem and the person who can fix it. And the closer you can get them together, the better off we are, the better the outcomes will always be. If you can get those two people sitting side by side solving a problem, or better yet, with our Smalley's case, he solved the problem himself. He didn't have to explain to someone else what the problem was, which has advantages. Speaker 3 (31:56) Gene, I think it's clear that the link between manufacturing and IT actually is quite... I mean, there's lots of overlap. Speaker 2 (32:04) I mean, it's all about people Speaker 3 (32:05) trying to solve problems, I have the impression. Speaker 1 (32:07) One with software, one with machines. Yeah, exactly right. In fact, that's exactly right. I would say, to reflect that back at you, is it's always about people trying to solve problems, right? And to what extent are we creating the conditions that Enable people to solve problems well. We can make it very, very difficult, which I think forms the basis of The Phoenix Project, the basis of the IT-OT Handbook, or we can do it very well, which is I think what we all have in common, trying to make it easier and explainable what we need to do so that people can solve problems well. So I have to ask you, writing a book is a multi-year journey. Speaker 3 (32:42) I remember what you said. Yes, David didn't expect it. Speaker 1 (32:46) What was the biggest surprise in your journey? Speaker 2 (32:51) What was the biggest surprise? I'm going to say something and willem, you can think about the answer while I'm saying something. I really thought in my naive mind, not having written a book yet, besides my master's thesis, that I would just start and the words will follow. And then half a year later, we have a book. And the reality is that Once you start writing things down, you come to the conclusion that you're missing information, that you're not sure about things, that you want to validate things, that some things might not be relevant, some things might need more time to digest. It's this cognitive process. And I think that was my main takeaway, that by doing that, by taking the time, needing to take the time to give these all extra thoughts, it's not just a better book, it's better for myself, for my own storytelling, for Speaker 1 (34:16) Yeah, and I have found that there are certain points in the writing process that fill you with self-loathing disgust, like a feeling of futility. I hope you didn't have too much of that. Well, let's say Speaker 3 (34:31) I learned, for example, that I write best at six o'clock in the morning, but I don't like waking up early. So that combination was very unfortunate. But if I would say what I learned is like writing is a bit like, for the people listening, Gene has a painting in his background. So it's a bit like painting. Like you might start like David says, With a general idea, then you start during the way you discover new things. But what I also found very special is, it's really hard to say when it's finished. It's like you always want to continue. And at a certain point, you have your editor, who is like the teacher saying like, this is not good, let's change that, change that. Also very useful. Who says like, it needs to finish. And that was a really hard moment to say, okay, now it's done. It was really hard. Speaker 2 (35:22) But big shout out to Anna and Lia, who did a brilliant job in helping us. Speaker 3 (35:27) I think the book became 100 times better with the help of IT Revolution, of the editors, absolutely. Speaker 1 (35:37) I love the saying, in order to be able to write clearly, you have to be able to think clearly first. And so it does clarify a lot in writing a topic. So what did you learn about this domain that you spent Yeah, majority of your career studying and getting very good at. What did you learn in the writing process? Speaker 3 (35:58) Oh, I think especially about the... I spent a lot of time writing the second part on the corporation models. And if you would compare it to the first one, it's been expanded in every possible dimension. And while in the beginning, We had the idea that maybe this type of interaction is inferior to the other. We came to the conclusion all types of interaction are great within a certain context and then you need to describe that context. So I think that was a really big, painful learning, many early mornings of writing and thinking. Speaker 2 (36:41) No, absolutely. I think the same answer is when you're just in a job and you go from meeting to meeting, you give a presentation left and you have a few slides right. I think the interesting thing here is that when you start writing it down, when you go from A to Z, from the first page to the last page, you're starting to identify gaps in your thinking process. And I think that is the most important thing for me is finding those gaps in your own thinking and then trying to close them. Yes. Speaker 1 (37:17) In fact, that is very familiar to me. I think methodologies, books, what they have in common is the ability to connect all the dots together. And that often means that you have to name all the dots first. My heartiest congratulations for writing a book that makes people see a problem that they have that they might not have recognized before. And more importantly, you know, give them hope that there's actually something you can do about it. My heartiest congratulations to both of you. Speaker 2 (37:46) Thank you so much, Gene. Also, well, A, thank you for being on the podcast. Really good conversation. Super interesting. B, also thank you for publishing this thing. And with that, I think it's time to come to an end to close this episode. Willem, Jean, thank you very much. To our listeners, thanks for tuning in again. Where can you find all the information? Ordering the book, you go to itotbook.com for all links, go to your favorite online bookseller. If you want to explore the topics together with us, we have our ITOT Academy. So go to itot.academy, super fun, you know, learning not just from us, but also from your peers, highly interactive, super interesting, or just subscribe to our blog or podcast. And with that, thank you very much. And until we meet again, take care. Bye bye.