Journeying Through Complexity: Gene Kim's Insights on Leadership and Innovation

Gene Kim and Charles Humble demystify the complexities of organizational dynamics, offering a comprehensive guide to navigating challenges and fostering success through his five ideals, backed by real-world stories and expert discussions.

Creating a Learning Organization

Charles Humble: Hello, and welcome to this episode of the "GOTO Podcast." I'm Charles Humble. I'm a freelance techie editor, author, and consultant. And this is the third in a mini-series of podcasts that I'm doing for GOTO, talking to engineering leaders. I'm aiming for each episode to have actionable insights and suggestions for further research, such as books and papers to read, conference talks to watch, and so on. And for this episode, I'm particularly thrilled to be joined by Gene Kim, because I think he is one of the very best communicators, teachers, and explainers we have in our industry. I have personally learned so much from both his writing and his conference talks. Gene is a "Wall Street Journal" best-selling author, researcher, and multi-award winning CTO. He has been studying high-performing technology organizations since 1999, was the founder and CTO of Tripwire for 13 years. He is the author or co-author of six books, including, "The Unicorn Project," "The Phoenix Project," "Accelerate," and "The DevOps Handbook."

Since 2014, he's also been the founder and organizer of DevOps Enterprise Summit. His most recent book is, "Wiring the Winning Organization," which he co-wrote with Dr. Steven Spear. Spear is perhaps best known for his work, "Decoding the DNA of the Toyota Production System," and "Learning to Lead at Toyota," both of which were published originally on "HBR." And which have become sort of part of the vocabulary, I think, for high-performing organizations. Between them, Gene and Steven have spent some 60 years studying organizations across every industry vertical, including surveying 36,000 organizations, and gathering case studies from over 500 of them, which is in itself, I think, just astonishing. Gene Kim, welcome to the show.

Gene Kim: Charles, I'm so delighted to be here. And I'm just so pleased to be in such an amazing company of this amazing series. So, thank you for having me.

Charles Humble: It's an absolute honor. I'm fascinated by how you and Steven ended up working on this book together. What brought the two of you together?

Gene Kim: I remember reading that famous "Harvard Business Review" article, in... I think it must have been the early 2000s. And I remember being actually a co-author of "The Phoenix Project," by Kevin Behr. I remember we were in Atlanta together. And we were studying the paper together, reading it...actually, listening to an audio version of it. And we were just dazzled by it. I actually got to meet him in person when I took a workshop from him at MIT Sloan School of Business. And it changed my life. I mean, in fact, sometimes I joke that "The DevOps Handbook" was a year later than it should have been, just because there was so much I had learned that I felt was so important that needed to get into the book.

And so we had been corresponding and interacting for some years. And this notion of writing a book together really came from this quest that we'd been on, that we both want to understand why do organizations work the way they do, both in the ideal and not ideal? And then what is in common between things like agile, and DevOps, the Toyota Production System, and lean. And for that matter, resilience engineering, safety culture, Westrom, and organizational topology model. And what was so fun... And our conclusion is that they're all incomplete expressions of a far greater, but also far simpler whole. And it was just such an exhilarating experience working with Steve because we come from such different backgrounds. I mean, you know, I don't think this made it in the book, but like, to oversimplify, I come from software, he comes from hardware. You know, he studied manufacturing, and safety cultures. He has a training in economics.

It was just so fun to be able to really try to study, what are the mechanisms at work? And, you know, why is there such convergent evolution in all of these domains? You know, to something that, despite a different background, we can recognize there are similarities, and common forces at work. So it was such a fun project. It was the most intellectually challenging thing I've ever worked on in my whole career, but also one of the most rewarding, just because I just learned so much.

Recommended talk: Remote Working Approaches That Worked (And Some That Didn’t) • Charles Humble • GOTO 2023

Charles Humble: It's always joyful, I think, working with someone who thinks a bit differently from you, and maybe gets your own brain working in a slightly new way or stimulates it. I'd characterize a lot of your work as being around how you create a learning organization, so things like psychological safety, which is...you have as the fourth of the five deals in "The Unicorn Project." And, you know, reducing the cost of running experiments and all that sort of thing. Would you kind of agree with that as a broad characterization? And if you do, how does that sort of fit with Steven's work?

Gene Kim: It's a stunning and startling question, because I think you put your finger on really, some of the most surprising commonalities when you look at, say, DevOps and the Toyota Production System, is that you do have this characteristic of psychological safety, but really meaning that everyone is able to be solving tough problems all the time, and really fully supported by leaders. There is a system that's loosely coupled, so that you have a low cost of experimentation. And that's actually some of the core concepts. And I think for me, the things I'm just most proud of in the book is that there's a couple of metaphors that we use that really describe these kinds of sometimes, you know, difficult concepts. For example, coupling, right? I've spent 25 years just trying to understand what is coupling, really? And why is it so bad to be tightly coupled? And what are the properties that allow you to be loosely coupled?

Gene Kim: Can I just give you, like, a two-minute performance art version of, like, how I finally started to understand why coupling is bad, and what constitutes it. Yeah, so, you know, the metaphor that we use in the book is Steve and Gene Kim moving a couch. And I love this because at first glance, it's kind of trivial, right? It's all brawn work, there's no problem-solving. It's not cognitive problem-solving. And yet, you know, Steve and Gene have to solve a couple not obvious problems. Like, where exactly is the center of gravity? Around which axis do you have to rotate to get through a narrow doorway, or to get through a narrow winding staircase? You know, who should go first? And, you know, should they face forward or backward? And, you know, they don't need focus groups or consultants. You know, just by picking up the couch, fast feedback, experimentation, and most importantly, communication and coordination. Right? They will figure out answers to those problems.

And yet, as leaders, we can do many things to make their work difficult or maybe even impossible, like, turning off the lights, right? Certainly, it will take longer, it's more dangerous. They can damage the couch themselves, right? It will take longer. So, that's not so good. But what's also interesting is that, we can also introduce a lot of background noise, like a loud siren, loud music. And this actually introduces a different dimension of difficulty, which is that, you know, they now have difficulty, Steve and Gene now have difficulty communicating and coordinating. And so we can even put in an intermediary, right, that prevents Steve and Gene from talking directly with each other, right? Say, going to Jira work tickets, or work orders, or account managers, or lawyers. And suddenly, it is not so preposterous to think that Steve and Gene will not be able to move that couch. You know, and I think this is exactly what caused the DevOps movement, right?

Is that, you know, the information flow required so far... You know, between Dev and Ops, to do, say, a deployment, so far outstripped the communication channel between them, that it forced this kind of reorganization where, Steve and Gene, instead of going through work tickets, now work directly with each other. And I think this is really the couch of the metaphor for joint cognition and joint problem solving. And really, the key notion here is coupling. Steve and Gene moving a couch, they are inherently coupled together, right? Whatever affects Gene affects Steve, and vice versa. And so that's the nature of many types of work. But often, you know, when you're having to have, say, 3000 people also coupled to the couch, no one has independence of action. And so the best thing you can do is, you know, cut the couch into smaller pieces, right, so that you liberate them to work independently of each other.

And then that's very familiar to us in software architecture. But it turns out, this is actually common. And this is what enables the Toyota Production System to work. You know, the famous Toyota Andon cord, right, the reason why you can pull the cord and you don't stop the entire line, right? It's not all coupled together. It stops the line segment. And if it's not fixed within 55 seconds, it will stop a larger segment, right, because it is a hierarchical system. And so that is the decoupling of the work system that allows such massive experimentation and resilience of the production line. Anyway, so, I think for me, I'm hoping that this will… and now everywhere... I've thought of problems about, is it too large of a couch? Or is it too small of a couch? Right? And, you know, so the cousin of coupling is coherence. If things are not adequately coupled together, you don't have people are able to work as a unified whole. Anyway, so that's one of the key ideas.

Can I give you one more, Charles, just because you had mentioned psychological safety. Yeah, so I'm a huge fan of Dr. Ron Westrom. And he's one of those people who, when I met, it was just so great, because he did so much to inform the state of DevOps research that I got to work on with Dr. Nicole Forsgren, and Jez Humble. And the whole notion of, like, pathological cultures, bureaucratic cultures, and general cultures, you know, so great. But, you know, as he said, culture is often viewed as gossamer and ethereal. Right? And so it's kind of difficult to know what to do with it. And so the metaphor that we use in the "Wiring the Winning Organization" book is that, we say it's all about signals. It's something that engineers can understand. It's about signal generation, transmission, most important, reception, right? Communication, you always measure success by the receiver, right? And then corrective action is taken, and then confirmation that it solved the problem.

And I love this because it can articulate all the ideas, you know, that the Westrom organizational typology model, but it's easier to diagnose, right? Is it a signal generation problem? Or is it a transmission problem? Is it a reception problem? Or, like, you know, if it's not safe to tell bad news, right? No one's going to transmit those signals, right? Is it a prioritization problem? Is it a confirmation problem? And I think this has just a lot more power. And it's also something that engineers are very familiar with. And so, we, as software professionals. And I think it gives us a lot of tools to solve very, very important problems. Charles, how am I doing?

Decoding Organizational Success

Charles Humble: I think that's great. I also found, as I was reading the book, I was making connections to one of the other ideals from "The Unicorn Project," which is the locality and simplicity. And that, to me, seems to kind of connect to the book as well in quite a sort of strong way, if you see what I mean.

Gene Kim: Without a doubt. In fact, you know, I think that you had mentioned "The Unicorn Project" before. And for me, "The Unicorn Project" was so fun, right? So, many people, they are familiar with "The Phoenix Project." Really, that's really kind of told from the story of the ops leader, right? And "The Unicorn Project" is the same story we told from the perspective of a developer. And it was just so fun. It was like really meant to be a grand thought experiment, about how bad of an architecture can we create, where you can take the best 10X engineer, right, the best engineer in the organization, you know, maroon them in "The Phoenix Project," and suddenly, they can't do anything. Can't build, can't test, doesn't have license keys, doesn't have approvals, can't get logs, can't get... Everything is so difficult. And I think it was really just this amazing thought experiment of what prevents people from doing their work easily and well. Right?

And I think that's the hallmark of great architecture, and the hallmark of great leaders, is that, they create these systems that allow people to be productive, to do their work easily and well, to have independence of action. So they're not coupled to everyone else in the organization. And it also allows them to do their work safely. I think I'm so glad... I'm not sure if I could have...you know, the "Wiring the Winning Organization" would have been...I would have known enough, had we not gone through the whole experiment of, like, really understanding what are the things that prevent us from doing the things that we want to do, even small things now require heroic effort. 

Charles Humble: That's good, I think. Something that I particularly loved, because although I'd experienced it firsthand, I didn't think I'd ever really thought about it, was the idea of applying locality and simplicity to data. So I think we've got very used to the idea of spending a huge amount of time and effort on developer productivity at the code level, but maybe rather less at the data level. That was a real lightbulb moment for me actually.

Gene Kim: I've been playing with LLMs. It actually looks like ELT transformations, right? And so, my favorite scene in "The Unicorn Project" is like, you know, during the disastrous deployment, there's a byte order mark in the file, which Jez Humble did that to me, on the state of DevOps research, where basically, all the data went missing because... Or was it Dr. Nicole Forsgren? She gave me a file with, like, a byte order mark, which basically means all of the columns disappear. So that happened in "The Unicorn Project," and basically, all the prices disappear from the E-commerce site. That never happens, right?

Recommended talk: DevOps Next • Nicole Forsgren • GOTO 2015

Charles Humble: In the "Wiring the Winning Organization" book, you talk about these three layers. You have layer one, which is the technical object being worked on, or as it may be studied. Layer two, which is the tools used to do the work. And then layer three, which you talk about as being social circuitry. And that, as I understand it, is essentially the processes and procedures through which ideas and information flow. I really enjoyed that analogy, but I was interested in kind of how you arrived at it and why you used circuitry as your analogy for that.

Gene Kim: Yeah. So that was Steve's. I was initially a bit skeptical. I was, like, why are we talking about this? But then he repeated something that he had told me once before, and just my head blew up. And it's this, it said, hospital systems were actually... Like, right now, notorious, you know, emergency departments are notorious for long wait times, missed handoffs, accidents, injuries, and fatalities. And this apparently wasn't the case in the 1950s. And his observation was this, is that, in the 1950s, a hospital system was actually somewhat simple, right? You had basically two silos, doctors and nurses. And you didn't have much technology, right? So there was no layer two, you had basically x-rays and so forth, but not a lot more. And so you could get away with a very simple layer three circuitry, right? Because the responsibility of integrating those functional disciplines wasn't too challenging.

Fast forward 70 years. And now, there are hundreds of functional specialties. Just among clinicians, you have about 20 functional specialties and growing. You have doctors, nurses, a pharmacy, supply chain. And just a lot more technology. So it used to be called radiology, right, x-ray. But now it's CAT scans, and MRI machines, and then, like, blood tracers. And so, now you have a lot more layer two. And so think about how much more sophisticated and how much more that layer three social circuitry must do. And so I love this Winston Churchill quote. "We shape our buildings, and thereafter they shape us." You know, we shape the architecture and the layer three wiring. Forever after, without dramatic intervention, right, forever after, it shapes us.

And so one of the top findings in the state of DevOps research was that, architecture was one of the top predictors of performance. And so architecture is a manifestation of this layer three wiring. What the three layers did is isolate. You know, like, whenever you have a longitudinal case study, where an organization goes from worst to first. Layer one and layer two are the same, same people, same technology, same floor space. The only thing that changed, that resulted in just dramatic difference in performance is all in layer three, in the manager system, in the layer three wiring that leaders create. And so it became very... Suddenly, it went from, "Ah, Steve, I just don't know about this." To, "Oh, how incredible that is to be able to isolate, you know, what changed in these organizations, right, that allows for such difference in outcomes."

I think one of the lessons that we really tried to put in the book is that, you as a leader, are responsible for the layer three wiring that everyone works within. And so if you have to create an organization where, you know, even small efforts require super heroic efforts, massive escalations, lots of cajoling and scavenging, right, that is really your fault, right? It's your responsibility, you know, to create one where people can get the right things, at the right time, from the right people, in the right format, when they need it. And these are all kind of hallmarks of great wiring. So that's, I think, one of the things that I'm just super proud of that made it into the book that just clarify so much.

Charles Humble: Yes, I agree. And I think it's one of those things where we talk a lot about sort of organizational culture, but that always feels a bit kind of wooly and ill defined. And one of the things I really liked about the circuitry sort of analogy is, suddenly I know what I'm looking at now. It's a really lovely clarification, I think. I do think that insight you have of, you know, essentially, leaders who pay attention to that circuitry, are the ones whose organizations will do best. I think that's such a key insight, it's really worth emphasizing.

Gene Kim: Maybe just two things I just found really kind of amazing working with Steve. One, he had this kind of logical proof points, that really proves what you just said. You don't have to get too very large of an organization, where the leader's role is not the kind of direct contribution of kind of labor or problem solving. Right? You know, it's a pretty screwed up organization, when the leader is doing all the work and all the thinking, right? That defeats the whole purpose of an organization. So if that's true, you take it to its logical conclusion, it means that the leader is responsible for creating the conditions for people to do their best work. How can you argue with that? I mean, that's absolutely true. Right? And so, if you agree on that, then that certainly makes evident and makes obvious, you know, things like empowerment, or frontline empowerment, or psychological safety, or whatever. You can sort of draw a direct line from that point, right, to all the things that leaders need to do. So that's one.

And then the notion of social circuitry that I was a little bit resistant to. Just like, ah, social circuitry, I like organizational wiring. But he convinced me, he said, "Circuits...whether a mechanical circuit or hydraulic circuit, its job is to get things to where they are, to where they need to go." Right? And so that explains why, like, in a poorly run, poorly wired organization, no one has what they need ever, right? And even when they get it, it's like in the wrong format. And so that's a function of the wiring. So, it was not just figurative, but I think very much metaphorical.

Navigating the Danger Zone to Achieve Organizational Excellence

Charles Humble: Right. Yes. I really like it. Can you talk a bit about the danger zone and the winning zone? And how that sort of connects in?

Gene Kim: Think of the worst conditions, where you have to solve really tough problems, right? I think in our world, you do it in production, right, when there's immense amount of pressure, and you have no ability to undo everything. But if you make one small mistake, basically, it cascades outwards and causes everything to fail. That's important because if you can't iterate, it means you can't learn, right? Learning is experimental, it's iterative. And what else can we do to make it more difficult? Oh, you can't see what you're doing. Right? Everything you do, you can never see what the outcomes are, or it's like five minutes later, or hours later, right? And so, those are absolutely kind of the worst conditions that one can solve problems in. And so the job of layer three wiring is to get us into this from dangerous territory into kind of the winning territory. Which means, you know, you don't do the most dangerous work in production, you do it in planning and practice, right?

And it's under those conditions where you actually have time to activate kind of a slower, more deliberative process of your brain, that's more creative. You know, this is where you come up with novel solutions. You can red team, you can do tabletop exercises, right, chaos engineering, all that. We call it slowlification. Then there's simplification, you change the nature of the problems themselves. Instead of a tightly coupled problem where everything's connected to everything, right, then you turn one thing and random things fail, right? You start partitioning the problems, right, both across time. You can do them in smaller batches, in space, by modularizing, or even kind of sequentializing. And then amplifying, right? Just make sure that you have sort of vibrant, dynamic feedback loops, that are giving feedback to the right people, quickly, all the time. That helps them learn, right, helps us all learn. So, we use the danger zone, winning zone, to really articulate kind of these characteristics of what everyone should acknowledge are, like, either great ways to solve problems, or terrible ways to solve problems. And then the three mechanisms, slowlification, simplification, amplification, are really mechanisms to move us from one zone to the other.

Charles Humble: I really like those three mechanisms. I kind of naturally latched on to the slowlification word, because I'm a word nerd and you invented a new word, which I kind of really enjoyed. I found myself thinking, there must be a word already for this, but I couldn't come up with one. And presumably, you couldn't either, which is why you ended up inventing it.

Gene Kim: In fact, we were very thoughtful. Making up a word, we don't do lightly. But our observation was that, you know, there's no one English word that seemed to sort of encapsulate this notion of making a short-term investment for a longer-term gain, right? We go slower to eventually go faster. And so, what's interesting is that we have a lot of adages for this. Like, stop sign to sharpen the saw, or like, slow down to speed up. The Germans have a word like verbesserung, that's pretty close. There's another longer word that's maybe even more complete. But I think our notion was that there's a school of thought that says, if you can't say it, you can't think it. And so we wanted to create this word, really to embody this concept, so that we can trigger more moments of, like, oh, my gosh, we are in a condition that we have lost kind of sight of what's going on, and we're actually entering the danger zone. Maybe we should actually slowlify, right, so that we can do things in a more deliberate way to activate a different type of thinking. So yeah, that's our justification for having to make up a word.

Charles Humble: I really like this idea of pulling problem solving out of the realm of execution effectively. It's really rare that organizations do that. But I think it's really crucial. I mean, sort of Bill Gates famously used to have sort of think weeks back in the day, take a stack of papers, and sit and read, and think thoughts. And I was kind of thinking of that as well. As I say, so often, you're dealing with the execution, you're dealing with the day to day, and you don't get time to step back, and reflect, and think, what can I do? I also made the connection to "Thinking Fast and Slow," the Daniel Kahneman... I'm probably mispronouncing his surname.

Gene Kim: No, that's right. Dr. Daniel Kahneman. And Dr. Amos Tversky, right, who was a collaborator on that incredible body of work.

Charles Humble: So again, would you make the connection? Is that connection valid, do you think?

Gene Kim: Oh, absolutely. I think the direct line that we would make to that incredible work is that, just like humans have kind of a system one and system two. System one being the faster, more instinctual biased way of thinking, right, but also much more energy efficient, right? Versus system two, which is, you know, actually tough to kick in, right? It's much more energy intensive, and it's tough to actually slow down and be logical. And what we're saying is that, you know, in organizational work, there is fast-moving work where you're in flow, you're locked in. You know, you're at this flow, like chief of the Mojave, right? You're, you know, a thousand times more productive because you're in the zone. Or in a fast-moving environment. You've rehearsed the routines. But that's actually not the mode that you need to be in to actually develop the routines.

And, by the way, actually... Just to share. I haven't told anyone this, but one of the big surprises to me was that, I wrote the Apollo 11 moon landing. There's like 24 case studies. And I took the first draft of the moon landing one, where basically, this is where Neil Armstrong gets the 1201 error codes on descent, like, 60,000 feet above the lunar surface. And actually, it turns out his display blanked for, like, 15 seconds. And the narrative goes that they had actually rehearsed that drill before. The simulation supervisor actually had set up these amazing drills to kind of rehearse outlandish scenarios, right? So this would probably be recognizable to anyone in the chaos engineering community. But I had written down something that Steve flagged as, like, that can't be possible. Basically, in the drill, I had written that, you know, when they found out the 1201 error code, that the computer specialist was kind of flipping through the binders and trying to make a call of whether he should abort or not, and then mistakenly aborted.

But I thought that they also had on the line, the team at MIT Lincoln Labs, who wrote the computer software. I'm sorry, it's the MIT something labs. But Steve said, "No, that's impossible. Right? There's no way that in that fast-moving simulation environment, they would have had time to make a call to the engineer, Don Eyles, to ask him, you know, did you know this could happen?" Because it's too fast moving. So, just to even recognize that when you're in the production environment, there are real limitations about, you know, who you can communicate with, who's making decisions. Because if it involves trying to find someone 2000 miles away, right, even with the internet, you know, they are out of the loop. And so, it turns out like in Apollo 14, right, Don Eyles was in the loop. But it was because it had to be resolved not in minutes, but in hours. And so I think there's a lot of things to learn just by kind of recognizing the limitations of what you can do in fast performance mode, versus, you know, something that is a slow mode that we can actually do some planning and preparation. 

Recommended talk: Patterns of Legacy Displacement • Rob Horn & Ian Cartwright • GOTO 2022

Organizational Change: Avoiding Cargo Culting & the Couch Metaphor

Charles Humble: I really like that. I think something that our industry has been very praying to is cargo culting. So in my consulting, I've seen th is with things like adopting micro services where, you know, we want to adopt microservices, because Netflix, but we haven't really stopped...spent the time to stop and think about the organizational aspects of them, and even what they're for, or maybe some of the ceremonies around agile, or the Spotify model, or whatever. And again, something I was quite struck by, and I don't know if this was a sort of deliberate thing, but I was just curious about it, was, you seem to spend a lot of time in this work effectively trying to avoid cargo culting. Is that wrong?

Gene Kim: It's such a remarkable observation. No, absolutely right. In fact, just like in "The Phoenix Project," the word DevOps is in the subtitle, but it's actually used only once in the book, maybe twice. And in the same way, in this book, we actually wanted to avoid a lot of descriptions of current toolkits, because they're so laden with meaning, intentional or unintentional. And we really tried to stick with first principles. In fact, you know, for our purposes, we really wanted to establish, what are the first principles. And really prove to ourselves that, you know, just like in physics, you learn about F equals MA, and then you can actually just by using that equation, do like interstellar probe planning, right? You can actually predict where they're going to be without adding to it. And so we just wanted to come up with that very parsimonious set of principles that can explain the most.

And so, I think a way that we did that is avoiding a lot of current terms, even having to manufacture a term. But then in the case studies, we did, you know, I think use a little bit more recognizable term. Like, you know, modularization, information hiding, and so forth. But, you know, it's something I'm just really pleased by, and something I'm just actually frankly amazed by is the couch metaphor. You know, we can explain two things that might be mutually exclusive, that seems mutually exclusive. Like, you know, on the one hand, the couch can explain Amazon in 2001, where basically, you had a very tightly coupled system, where small changes could basically take the entire site down for days. And it explains why they had lost their independence of action, right? In order to get small changes done, each engineer had to communicate and coordinate with 60, 80, hundreds of different teams.

And so by partitioning the system into microservices, they modularize the system, you know, creating independence of action for the you build it, you run it teams. Okay, fantastic. That couch was now subdivided into hundreds or thousands of couches. But, you know, there's this other story, right, that Amazon Prime Video came out with last year, saying they went from microservices and step functions to a monolith. And so, I think the couch also explains that, is that, you know, when you chop the couch into too many small pieces, right, you spend all your time coordinating and transporting data in and out of storage buckets. And so you've lost coherence and locality. And so by gluing the couches back together again, right, you know, you don't need to transport anymore. And so you kind of regain coherence and increased coupling. So I just thought that was... The simple metaphors can explain what seem like contradictory advice, if we can describe the problems that led to them. What do you think?

Charles Humble: I think we get very stuck as an industry into this idea that, this approach is the right approach. And so often, it depends where you are. Like, microservices, if you're evolving really quickly, and your product is changing really quickly, then having lots of independently deployable services makes a bunch of sense. But you are paying a heavy operational cost for that. if something goes wrong, it's harder to track that out and debug it. Versus if you've got something that is more monolithic, yes, you can't evolve it as quickly, but it's a lot easier to run. So it can be a case where if your product is stable, or not going to change, actually, you know what, a monolith might be a perfectly reasonable approach to that, particularly if you can sort of modularize that a bit within the actual programming environment. That could be a perfectly valid approach. And moving from one to the other, I think we get very hung up on this. Oh, there's the one right way to do everything, and there isn't.

Gene Kim: In fact, I just love the couch because, you know, the decisions and the tradeoffs we are making around coupling, independence of action, and coherence, right? To what degree can they all act together as a unified whole. And, like, in general, if everything's in one application, it's a little bit easier to understand because it's actually part of a unified whole versus like thousands of microservices. You know, try understand the context of all those in your head, right? It's very, very difficult.

“The Unicorn Project”

Charles Humble:. Before we close, I really want to talk a little bit about "The Unicorn Project" book as well. We've touched on it a couple of times. But again, I think it has.. One of the things I think is really interesting about it is it had such a profound impact on how leaders outside of technology think about their technology teams. And I don't think many books have done that. I wonder if you could just, you know, talk a little bit about the book and maybe share some of the stories you've heard from some readers of it.

Gene Kim: In fact, thank you for the kind words on that. I love hearing that because... As a fellow writer, I'd love to share kind of a writer horror story. So in "The Phoenix Project," you know, in the book, the most important question is, who is the audience? Right? And in "The Phoenix Project," you know, our first cut was, like, it's the top technology leader, the CIO. And there were reasons for that. But ultimately, there was a whole bunch of scenes that didn't fit. And basically, at the very last three months of the project, we said, "All right, it's not for the CIO. It's not for CIO's boss. It's for the VP of IT Operations, right? It's for them. And hopefully, the book will be good enough where that person spreads the book around." And I think that was the right call. With "The Unicorn Project," we had a similar quandary. And literally, the last week of the book before it went to print, it was like, "Okay, who is the audience? Is it for the dev leaders? Is it the top technology leader? Is it the developer?" Because we were having to... Like, some jokes just wouldn't make sense to anyone but a developer.

And do we really need to explain what the IDE is? Finally, we made the decision, it's for the developer. You know, and hopefully the book will be good enough that a non-developer will read it and sort of get something out of it. And I just think it shows just the power of whether it's products or book, just be very specific, like, who the audience is, and just wrap everything...everything subordinates to that. Mik Kersten, who wrote "The Project to Product" book, he's CTO of Planview now. He said, when he deals with CEOs who want to know more about coding, he said, don't learn Python, just read "The Unicorn Project," because it will give you a good glimpse of a day in the life of a developer, and all the things that leaders can do to make their work miserable, or impossible. Versus like, you know, what makes it full of focus, flow, and joy, where they can actually move the needle on important outcomes. I had mentioned before, it was such an incredible thought experiment just to serve, like, heap on the problems... Maxine, the protagonist, is like, "Okay, what are the craziest things I've heard of people having to put up with to do their daily work?" And I'm hoping that it was very accessible to people that you don't have to be a developer to understand that.

Charles Humble: I really think it was. And I think as well, the fact that, you know, it's a story. It's not a dry, sort of boring management book, which so many are. It's just fun to read. I had genuine laugh out loud moments, which is not something you find often in a management textbook. So the sort of core of the book is the five ideals, so we've touched on a couple of them. Psychological safety is the fourth. Locality and simplicity is the first. Focus, flow, and joy, improvement of daily work, and customer focus. How did you arrive at those?

Recommended talk: Structures Shape Results: Software Insights • Elisabeth Hendrickson & Charles Humble • GOTO 2024

Gene Kim: Honest answer, again, from writer to writer, I was actually hanging out with Mik Kersten, and we were visiting someone we just both mutually admired, the CEO of Compuware, who was this amazing turnaround of a mainframe software vendor. Anyway, I'd met them for dinner the previous night. This is January 2019. They were like, "How's it going?" I'm like, "Terrible. I wrote 110,000 words, and I have no idea what it's about." But by the end of the next day, I'd just seen enough where... I have a picture of the piece of paper, where it just... Just by the way, Chris O'Malley, the Compuware CEO at the time, talked, and just the rituals and norms they had in the organization. And it was just so obvious, like, what the book was about, is those five things. It was a locality and simplicity... Hang on, I gotta reload the head. Locality and simplicity, focus, flow, and joy, improvement of daily work, psychological safety, and customer focus. And anyway, it's amazing how in 24 hours, if you have the right 24 hours, like, what was just a muddled mess simply becomes clear. And then really, then the work became cutting out anything that didn't have to do with those five ideals. Right? And that was work of many, many, many months. So, true story.

Recommended talk: The Unicorn Project & The Five Ideals • Gene Kim • YOW! 2019

Charles Humble: Your writing process sounds horrifyingly like my writing process. So, throwing a lot of words on the screen and then going, what do I have here?

Gene Kim: You know, I listened to Tim Ferriss's interview of Jerry Seinfeld. And he said, "Comedy is a game of tonnage."

Charles Humble: Also there's a Neil Gaiman quote, which I also really love, which is, "Doing your second draft is the opportunity you have to pretend you knew what you were doing all along." Which I also just really like. What are you currently working on? What are you thinking about at the moment?

Gene Kim: Oh, my goodness. What am I thinking about at the moment? You know, before this, I was mentioning that I'm just still... I feel like writing the book was such an intellectual...not grind. It was the toughest thing I've ever worked on. And I wish I could have had a year But you know what, I find myself so invigorated because I find myself now reading other books. I'm like, oh... If we use "Wiring the Winning Organization" book language, right, this is what the lessons are. And so I'm going through some of my favorite books, and just kind of reviewing it through kind of a simpler set of mechanisms. And I'm just finding it just so exciting. Like, for example, when I read the Google leaked memo, we have no moat and neither does OpenAI. And for me, it just reminded me of, like, the lessons about modularization. And so, basically, kind of the gist of the paper is, the reason why they don't have a moat, is that these cheaper, smaller LLMs, that's where the frontier... You can, you know, solve those parts of the frontier with those smaller models. And you don't need $100 million to create these frontier foundational models.

What I learned in the book is that, well, it depends on where you think the tough problems are. Are  they in this vast frontier that one small team can't explore by themselves? Right? And that would say, oh, so the open-source models. Or are there still genuinely tough problems that you still need $100 million to, like, train, right? And I think the answer is very much both. I'm not an expert. I can't prognosticate. But it's given me the language and a thought process to be able to look at a thing of which I know nothing about, despite hundreds of hours of videos watched, and not really come to an opinion yet, but be able to say, "Oh, where are you put your bets will depend on these things." And so that's been so satisfying. So I see myself spending the next couple of years just kind of revisiting some of these concepts and kind of reframing some of my favorite works, you know, through the lens of the tools and terminology in the wiring book.

Charles Humble: That's fantastic. Gene, it's been an absolute pleasure. Thank you so, so much for making the time to talk to me today.

Gene Kim: Oh, Charles, right back at you. I'm a fan of your work. I loved your GOTO video. And so keep up the great work. I can't wait till this series comes out. Not for me, but for the people that you're interviewing, including Elizabeth Hendrickson.

Charles Humble: Thank you so much.