Season 4 kicks off with a conversation with Gene Kim, author of several renowned books, including "The Phoenix Project," "The DevOps Handbook," and most recently, "Wiring the Winning Organization."
In this episode, Gene candidly shares the trials behind writing what he considers one of his most challenging books, why it was a joy to partner with Steven Spear as a co-author, and the key principles needed for creating high-performing teams.
Illustrating these ideas, Gene and Conor draw on examples from diverse realms, including the intricacies of software development, the complexities of healthcare, the socio-technical system behind Amazon’s success, and everyday tasks like moving a couch.
Note: This conversation is a follow-up to last year's episode with Steven Spear. You can listen to Steven's episode here.
Episode Highlights:
- 01:00 Teaming up with Steven Spear
- 05:00 Slowification, Simplification & Amplification
- 14:00 Applying concepts from the book to your org
- 21:30 Examples of "miswired" orgs
- 28:00 Trends in the DevOps community
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Welcome back to Dev Interrupted. I'm your host, Conor Bronsdon. I'm delighted to be joined by the esteemed Gene Kim. You may have heard of him. Author of the Phoenix Project, the DevOps Handbook, a new book, Wiring the Winning Organization. I just spoke with his co-author, Dr. Steve Spear, and I'm very excited to talk to Gene as well.
Then he's also, of course, the program chair for it, revolution's DevOps Enterprise Summit founder himself. Gene, welcome back to the podcast.
Gene Kim: Oh, so good seeing you again. And by the way, I'm dying to ask what was it like hanging out with Steve for that interview?
Conor Bronsdon: I love Steve. He is, he's such a gem.
I have to say, he's got me convinced on bow ties now, . So it was fascinating learning about your research. It was great to just chat with him. He's a really cool dude, and I can see why the two of you wrote a great book together. Yeah.
Gene Kim: Yeah, it was so cool because, the question we set out to ask was let me just set up the stage a little bit.
So I spent, I guess 23 years studying high performing technology organizations. And so we know that the organization have the best project duty performance and development. They have the best operational reliability and stability. They have the best posture of security and compliance. And the state of DevOps research we identified, it has something to do with their.
Technical Practices or Architectural Practices and Cultural Norms. And Stephen Spear Speer, he spent 30 years studying, the Toyota production system, engine design at Pratt Whitney the safety culture at Alcoa. Submarines, incredible career. Yeah, exactly, and so I was...
Wonderful that when I met him 10 years ago this quest that started to merge was, what is in common between the Toyota production system, right? And safety culture and DevOps and agile and concepts like psychological safety. And it was exhilarating to see that, they are potentially all incomplete expressions of a far greater whole.
And I have to tell you, it is, it was one of the most challenging thing I've ever worked on. Really. There was one point in the book where I almost quit just because and should I tell you what? Please? Yeah, that's a great story. It was about a year ago and we're just I thought we were at a point where we were very stuck.
We had a theory that we knew it had to be, three things. Ification, simplification and amplification. But we couldn't come up with a simple model to really demonstrate all three principles. It felt too hard to boil down. Yeah, exactly. And I told my wife I'm going on a walk and I'm not coming back until we have something.
And so six miles later I am pretty convinced I'm not smart enough that I don't understand software development enough. And I try to come up with these kind of much simpler scenarios like. I don't understand movie theater operations, but, I realize I don't understand movie theaters well enough for that.
How about restaurant operations? I don't understand restaurants well enough. And yeah, it was a very it was a distressing moment where you started something three years ago and you might not be able to finish it. Because if you can't explain it, you don't understand it.
Using this vignette that we had written, a year before around Steven Jean moving a couch together, could be expended to, oh, Steven Jean being asked to move, help their spouses renovate a an old hotel. So they have to do, remove the furniture from room, paint the room, and bring the furniture back in.
And it just, it was just so exciting because I was like, oh, yeah, we can use that to show how even having just two functional specialties doing, not the most complex activity can be thoroughly screwed up, if you organize 'em wrong. Yeah. And so it was just even more exciting when, I did.
In a 30 minute call with Steve, he instantly got it. And so I was like, ah, that's a wonderful moment. Yeah. Yeah. So it is been a, it's been such a fun adventure and my genuine hope is that this will not just resonate with technology leaders, that they'll find something instantly familiar.
This is a recast, like everything that we've learned over the past many decades about like how to do great software well. But it'll also resonate with manufacturing leaders people doing bio bio research. Totally. And so I find something, I find that. To be a, just a wonderful hope that, that's one, create a common language to talk about, how we talk about systems and leading systems.
Conor Bronsdon: Steve talked about this in a very similar way. He's felt like it was a kind of culmination of this, decades of work the two of you have done. So it's very cool to hear you view it similarly of I've had a lot of the pieces and now I have this grand unifying theory of how to build high performing teams.
Gene Kim: No totally. And I love this quote. Anyone can make the simple it be complex. It takes, it is a lot harder to take something complex and really simplify proof yourself. That is something simple. And so maybe I can instead of talking in the abstract, how about how we talk about in the concrete?
Let's do it. Yeah. There's essentially was saying there's three mechanisms to create great performance and you cannot, create great performance without all three.
Conor Bronsdon: It's much harder at least.
Gene Kim: Yeah, exactly. Exactly. And so the first is ification. And you know that word we made up because there's no word in English that we were able to find after asking GPT four a hundred candidates.
Yeah. There's no word to capture this concept of slow down to speed up or stop sawing to sharpen the saw, or slow is smooth is fast. I guess the Germans do, but it didn't fit on the cover. In our world, we know this as Amazon game days, or when, or Chaos Monkeys.
To perform brilliant under in production to be able to handle that with resilience and ease actually takes a lot of planning and preparation. And so the classic stories in April, 2011, the first AWS East outage where, essentially AW S's largest availability zone goes down.
That's where they put all the customers, most of the big customers go down except for Netflix, which is very confusing because Netflix was running entirely in the Amazon Cloud. How did they not go down? Yeah. And that led to the. Famous Netflix blog post, that described how they did it.
And essentially there's really two design decisions they revealed. One was as they migrated out of data centers in nine, in 2009 they could have no single point of failures. And their largest single point of failure risk was AWS . That makes sense. Yeah. Yeah. And they, I think they even say, they will never be there when we need the most.
And so that led to the development of Chaos Monkey. Which randomly kills computance in the cloud, right? Yeah. Then it kills services in the middle of the day. And so developers got very good at fixing those issues. And no, no wonder that when that availability zone went down, Netflix services still ran.
So that's an example of ification. You don't want to, if you have. If you're doing all your learning in production environments that have high consequences, that you can't undo actions, it's impossible to learn , right? So you have to do it in the most, more safer environments of, planning, preparation, right?
So simplification so that first one really makes problems easier to solve. The simplification is all about how to make the problems itself. Simpler so that we can solve 'em easier.
Conor Bronsdon: And same concept of mathematics, right? Where it's okay, this fraction is large, let's break it down so we can make this a little easier for people.
Gene Kim: Totally let's start it like terms and there's all these things we can do, get our heads around the problem. That's a great example. I've never heard that example, but that's exactly
Conor Bronsdon: That can be the next book.
Gene Kim: Yeah. And I think what's exciting about that is that in our space, the what that should bring to mind is the state of DevOps research finding where we found that.
One of the top predictors of performance is to what degree can teams, is architecture, to what degree can teams work independently of each other without a lot of fine grained communication coordination?
Conor Bronsdon: And not just technical architecture, but people architecture as well.
Gene Kim: Oh, absolutely.
The socio-technical system. Without a doubt. And the classic example of that is in Amazon 2004. They started off with two categories of products, books and music. By 2004, they have 35.
Conor Bronsdon: How many are we at now?
Gene Kim: Yeah. So imagine you know how difficult it was to get things done. Yeah. If you were one of those 35 product teams and you had to deal with the product page team, the ordering team, the shopping cart team, the returns team, right?
And then you have every team connected together and to get even small things done required a huge amount of coordination. Yeah. And Dr. Vener Vogel, CTO at the time, he said in fact I just only learned about this quote a year ago. Despite reading this paper 10 years ago, he said there was this absurd situation where Amazon digital, so it was video and Kindle to fulfill an order they had to provide a physical shipping address.
Which, and there was no way around it. Oh, interesting. . Yeah. They had to go to, according to this article, right? Those teams had to go to 60 different ordering teams and say, could you please give us an alternate, order path? And they're like, didn't budget for it. You're outta luck.
So they were stuck and so that was the real genesis behind Oh, and then the fact that they couldn't deploy code anymore. That, most deployments didn't finish. Yeah. Because something went wrong. A bit of a challenge. Yeah, exactly. So you of course, that led to the $1 billion re-architecture of Amazon into those APIs.
Which, they've separated them into modules that can now work independently. They can independently develop, deploy, value to customers.
Conor Bronsdon: That whole concept of just having APIs run everything within Amazon has really enabled them to scale like they have. And it's interesting that the first two examples we bring up are both related to Amazon, because it shows the depth and the success they've had at building a very high performing organization and scaling it across the world.
Gene Kim: Two things that they did brilliantly, that modularization allows, it allows the reduction of design time coupling so that those teams can do what they need to do without communicating, coordinating with the 60, 100 other, or now thousands of other teams. As long as I don't change the API, I don't need to coordinate with anybody.
And then, as you mentioned they reduced or eliminated runtime coupling. I can scale my service without having to scale everybody else as well. It turns out that is another, that is one of the three ways to simplify systems. And there's something equivalent that you do with sequential processes, like the Toyota production system.
Each one of them enable independence of action. Dependency reduction. Without having to get permission from 35 different other people.
Conor Bronsdon: So creating autonomy within the organization Yes. And the ability to then execute, which again, there's other resources been shown that when someone feels like they can maybe be impactful, they do better work too. Another indicator here.
Gene Kim: Oh, absolutely.
And it allows them to get more faster, more direct feedback on their work. Great. Great point. Absolutely. So all those things. Come from modularity.
Conor Bronsdon: We're seeing this all add up, these little steps that then start to compound together. Yeah. And I know there's a third dimension as well that you mentioned.
Gene Kim: Yeah, in fact, you know what? Maybe just you just reminded me. So that linearization, right? The cousin or the orthogonal cousin of Modulary is the Toyota production system, but that's also CICD. Yeah. It's like when you line up sequence activities, like requirements to dev, to test, to deployment, to ops.
Conor Bronsdon: Let's simplify the friction points all along the way.
Gene Kim: Absolutely. Let's tie them together. , right? Yeah. So that we don't do large batches and they have to. Open up tickets. Wouldn't it be great if we could automate, linearize, and then automate those processes so that we can get single piece flow through those systems.
Yeah, exactly right.
Conor Bronsdon: I was just talking to Dr. Andre Martin about his book and... How his viewpoint is also like, when we have these situations, we are freeing up cognitive loads. People can do their best work. And I see that same theme in your research.
Gene Kim: Oh yeah, absolutely. And I think what's really exciting to me is that, Dr. Nicole Forsgren was here, she presented on her research. And what I love is that the concepts in wanting the winning organization, they line up right with the state of DevOps research, finding the door message, because Linearization is all what allows us to get fast, deploy lead time because you can't deploy within minutes or multiple deployments a day if every deployment requires threading your work through, 3,500 different steps across 60 different teams.
Yeah. And of which maybe the testing step will take six weeks, right? Can't be done. Linearization should also be familiar to technology.
Conor Bronsdon: And these are all important sub concepts of that simplification thing you talked about.
Gene Kim: Yeah, absolutely. So yeah, you were mentioning the amplification, the third one.
The notion is that in any system you have to, when something goes wrong, you want to be able to generate the signal, transmit it, receive it, and then hopefully have someone react to it, right? And then solve the problem. And this should be familiar to us in technology.
It should remind us. Of production telemetry. Yeah. You gotta see the problem.
Conor Bronsdon: Also. Continuous learning. Say learning, let's find the problem. Let's keep going on it.
Gene Kim: Yeah. Iterations, iteration. You're right because once we see a problem, we wanna fix the problem. I should hope so. We want to be able to in any complex activity, it helps us see what's going on, right?
And helps us confirm that what you actually did resolve the issue. In fact, for that matter it also reminds me of. Now that you mentioned it putting developers on rotation, just like ops people, right? Because you gotta share the pain or, you gotta share the learning.
Share the learning, right?
Conor Bronsdon: Yeah. I love it. So how should I construct my team then? How do I wire that winning organization? Great. I have these concepts. How do I apply them?
Gene Kim: Oh yeah. That's a great, that was a really great question. And I think it defies easy explanation, but I think we know.
When it will work or when it won't. I think we simplify it down enough. So let's say Dev and Ops configure it one way where dev does all their work and hands it over, throws it over the wall to Ops . And the only way that ops can talk to Dev is if there's a live seven out. And you have a ticket number.
And the only way that ops can talk to Dev is if there's a project code . And I feel like that is just not our winning recipe because the communication channels between dev and ops are so few and thin that it's just hopeless to transmit enough data, to get the system to work as a whole.
Does that resonate with you?
Conor Bronsdon: It absolutely does. There's plenty of research that shows that when there is high degrees of communication and feedback Yeah. The quality improves. Yeah. So this absolutely resonates.
Gene Kim: Yeah. And I think the metaphor that we use for that is to try to educate leaders on that is it's like Steve and Jean moving a couch, and it's just a metaphor for how we do joint problem solving and joint cognition. And you one might think that moving a couch is all bra work. There's no brain work. But when Steve and Jean move a couch together, there's actually, how do you get it through the door? Yeah, exactly.
Where's the center of gravity? How do you get it down the stairs? Yeah. Who goes first?
Conor Bronsdon: I was actually telling Steve when I was younger, I had to help a cousin of mine move and we realized we couldn't get the couch out. Down the stairs, and we had to actually hoist it off the roof to get it out of the building, so I'm like, yeah, there's absolutely some complications that come in here.
Gene Kim: Oh, absolutely. And, as leaders there's all these things that we can do to make it harder for Steve and Gene to move the couch. We can put in a ticketing system. We can put in we can prevent them from talking directly to each other. We can turn off the lights so they can't see what they're doing.
We can put in a lot of background noise so they can't hear each other. So they can't communicate and coordinate.
Conor Bronsdon: Okay. So that maybe the background noise would be inefficient systems that don't flow well to, to your example earlier about CI ICD systems and trying to create this linear flow.
Gene Kim: Oh, totally, totally.
And I think the the reason why the first system doesn't work well is the reason why. I think we were able to say, oh, that doesn't work well. Because Devon ops, they're trying to move a couch together, but they're not actually allowed to talk to each other.
Conor Bronsdon: Okay. Can be sign language on the couch or something.
Gene Kim: And so when we do things like co locating them together, having a liaison of ops into the dev teams, and vice versa, these are now much closer to Steve and Gene moving a couch together. Because there's actually joint problem solving going on. How am I doing? Does that resonate with you?
Conor Bronsdon: on a production line can focus their energies on key tasks instead of, worrying about these other contextual pieces that it's like, Hey, we've already figured the context. We've figured out the flow. Let's free you up to do what you do best. And I think it's the same thing, whether you're a writer, whether you're an engineer, it's okay, let's make the systems that work for you as easy as possible.
Some people mention AI here, I'll throw it in as a buzzword, gotta do it once in the talk. And then we're gonna free you up to focus on what you're most creative at, what you're problem solving, your strategy, these things that give you depth. And as a leader that this release speaks to is so much of your focus should be how do I make it easier for and resonant for everyone around me to do their job, to feel passion and to go deliver.
Gene Kim: That is amazing. Double, triple underscore that. What I had learned in this book is that the job of the leader Is to ensure that everyone can do their work easily and well. Yeah. And you can thoroughly screw that up by, not having enough time slack in the system, because that means you're not slowing, every mistake is being made in production when you can't learn, or you've organized a system so that you know no one can move a couch together.
Yeah. Or maybe to get things done, you have to. Open up tickets with 35 different teams. That is the opposite of easy and well. Or, if you create a system that somehow suppresses or extinguishes entirely important signals. Not like... Weak failure signals, as opposed to amplifying them and acting on 'em directly.
So I found that to be very satisfying. I love the way you phrased that.
Conor Bronsdon: Honestly I take a lot of inspiration just from what I've read of your book so far and my interview with Steve of this conversation around social circuitry and the idea of how do we program the society we live in and particularly like our organization to work better.
And I, I think that's a. It's such an impactful concept, I already told my producers I'm gonna be repeating this for the next year, they're gonna get tired of me hearing me say it.
Gene Kim: It's so difficult to argue against. And what I'm hoping that people reading the book will give them a language to be able to say, no my leadership has not made it easy for me to do my work easily and well.
And there's gotta be, it's either one of three things has gone wrong. And what I hope it gives leaders is especially ones that come from a technology background or are engineers, the same. Theories and intuitions and experience that helped us build great technical systems are actually perfect for us to think about the socio part of the socio technical system.
Conor Bronsdon: Breaking things down into components. Again, understanding that we try to simplify, amplify the key pieces so people can spend more time on key tasks versus less time in, status meetings, for example.
Gene Kim: A hundred percent. Yeah. I love the way you talked through that like an architect, right?
When Steve and Jean are, moving and couch together, they are coupled. What affects gene affects Steve vice versa. But it means that they are coupled together and there are times when we want lots of coupling when you want dev and ops pairing together because you want that incredible flow of information to be as wide and fast as possible.
Yeah. The problem is is that. In order to make a change involves both Steven Jean , right? So that's great, but it can get to a point where you have 35 imagine a couch that 35 people are attached to and none of the 35 can do anything. And they've lost independence of action. Oh, that's the autonomy piece we alluded to earlier.
Exactly. So maybe it's time to divide up the couch without destroying it. . But somehow re-architect it so that, maybe it's 35 smaller couches. . What are the pieces that can actually, be done independently of each other? And the benefit of that is independence of action.
So the other thing that we can get wrong what we got wrong in that part is that. When we are overly coupled to the organization, not only does anyone have independence of action but we waste a lot of time. You're listening to things that have nothing relevant to you. Small things require, vast amounts of effort.
Yeah. To get everyone's permission. And then, it's not just to get permission. You have to schedule together, prioritize together. Worst case, deploy together.
Conor Bronsdon: If you're watching on YouTube, you can probably see me shaking my head right now, thinking of some examples of when I've dealt with Snowden concepts before.
This is really wonderful. I love the way you have broken this down into these like simple explanations that then build outwards into real life scenarios people are dealing with. Are there other key concepts from the book that you want to highlight for our audience?
Gene Kim: I have a super fun example that actually a group of people came up with that I just fell in love with.
Imagine a fictitious telco, okay? That the most important thing that they could do is just present a checkbox to the 30 million customers that would allow them to opt in to a $5 a month service for email, watch, movies, et cetera. The problem is that it has to cross 40 different teams across four different customer channels, digital store support, billing, okay?
And it will require CEO minus one support. It requires daily war room meetings and it'll take about nine months. Estimate is about $20 million , and most people think it will have a 20% chance of success. Why? Because it didn't work the last two times we tried it.
Conor Bronsdon: Doesn't sound ideal. like the nice concept, but yeah. Okay.
Gene Kim: And what's awesome about this example is that it's not because it's technically challenging. It's because somehow the organization's wired wrong to make it almost impossible to get this work done. Yeah. And yeah, I think it's just a great example of it just so vividly shows how we can easily create.
Systems where to get small things done require like s heroic efforts because the coordination cost is so high.
Conor Bronsdon: And these coordination costs often become even more and more impactful as organizations scale too. Yeah, because, when you're a startup, maybe you're 20 people working in the, one office together you're all fired up about the idea you're passion.
It's easier to ignore these coordination costs because it's a smaller group, there's less people you have to talk to, but as organizations start to grow, it's so crucial that you think about these concepts and ensure you're being intentional about them. Because by that 100 person mark, there can be such a tax on coordination within your organization if you're not careful.
Gene Kim: Showing the examples outside of technology there was a section that Steve wrote about how when one of his daughters was six years old and got in an accident on the playground, had to go to the hospital. And they show up into the ER, and it takes hours to get through the paperwork the it takes hours to get the X-ray done.
They show up. Oh. And it turns out they initially were going to X-ray the wrong arm. Oh, no. They they, because of a supply chain problem, they can't get a fiberglass cast, so it has to be a plaster cast, which you have to keep dry. And to make the follow-up appointment, they had to call 'em outside line which they had to find on their own
And so this was an example of a misfired yeah. Er. And it reminded me, and I wrote right after that my dad had a stroke. It was something very similar. I was met with the neurologist just to try to get an understanding of what was happening. And so when he got moved outta the intensive care unit yeah, they, the, they did the rounds.
So this is the the the physicians, the specialists, the not, the nursing staff the social worker. and they're trying to make a decision about should we put 'em on blood thinners or not? And they couldn't make a decision until they got the the MRI images. And I said, is it this image I showed?
The image I took the previous night? Yeah. And they're like, oh, yeah, that's very helpful. You, and they decided to put 'em on blood thinners right away. But it was just another example where people didn't have what they needed at the right time. Systems issues. Yeah. It seems and it's not a technical issue so much as, the organization was miswired to get the right information to the right people.
Conor Bronsdon: And that must be such a challenge in healthcare in particular because, you know your decisions can affect lives so deeply. And so I'm sure the idea is, oh, we want to make sure we don't make mistakes. And there's also, of course, massive issues with, we're going to get sued for this malpractice.
But because that, I'm sure, has seeped into the entire ethos of the system other pieces of organization, the organizational design that could ease up the friction points so that people can focus on those key decisions, like it sounds like those are breaking down.
Gene Kim: Can I offer you a less generous interpretation?
That this is actually a DevOps problem in a different context. Okay. That in other words, what would happen if to change a medication on a patient bedside required going up eight levels in the nursing chain and then down eight to pharmacy? Probably never change the medication, that's for sure.
Or to to change the type of gloves used has to go up eight levels to chief operating officer and then down eight levels to supply chain. Alright, it reminds me so much of oh, in order to dev to get important information to ops, they have to escalate through the VP of development to the CIO down to the VP of operations, down to aligned ops person or a headache
Yeah. It is eerily similar , right? And yes, everything that we, you said is true, but in no way I would say excuses, that the healthcare leader from. Allowing people to do their work easily and well. And I think we've helped create this incredible body of knowledge in the DevOps community.
But you could take those same concepts, apply them to so many different domains that we talk about in the book. And to me, that's just so satisfying. Yeah. That in so many ways DevOps is leading the way and my hope is that. Through the book, other domains will see how those same principles and patterns can be applied to their work as well.
And in many cases, in situations where it really matters.
Conor Bronsdon: Today, which linear B is proud to partner with is one great one. We to put out a benchmarks report and Nicole Forres Green's work at GitHub and Microsoft. Some really fasting signal Sonotype got a new report. Yeah. All this incredible data and information is coming out. What are the trends and extensions of the DevOps spirit and the improvements that you see coming over the next couple years
Gene Kim: It's such a fun time to be in the game.
It's incredible to see just. How much the world is changing. And all that spirituality. So my main reaction is Wow, what a great time to be in the game.
Amen. I guess the downside is that It's hard to expect everyone to read them all. Yes. So I think, the one thing I think about is, It does describe How all this New knowledge is creating a need for more functional specialists. We can't expect everyone to know everything. And so the reason why we have movers and painters is to allow them to, specialize roles.
Breakthrough in Adam Smith's pin factory in the 17 hundreds was that, if we can have division of labor allow specialization I think it was like a two order of magnitude or three order of magnitude difference in terms of how many pins you can generate per day. Yeah. And we want specialization, platforms, SRE metrics, observability, containers, Kubernetes, this is.
No one can read all the documentation in their lifetime. And I think it just says, as technology leaders, our work is getting more difficult. We're not talking about two silos, we're talking about maybe eight silos, 20 silos. Now you're going to be working with your best friends in data and AI and ML and MLOps.
And necessary for the leader to create that layer three organizational wiring, the social circuitry, so that everyone across all these vast functional specialties can all do their work easily and and achieve the goal.
Conor Bronsdon: My simpler plan is just to add AI to the name of our podcast. I think it'll drive views.
We should be good to go then, right?
I love this perspective we have where we have such an opportunity here, but there are risks, as you point out. Because if we fail to think about simplification of organizations, how our organizations are flowing, if we fail to modularize, there's problems that we can have.
Gene Kim: Oh in fact, Patrick Dubois gave a great presentation on day one.
And it was a real life experience report of him trying to bring AI enabled capabilities to market as the VP of engineering.
It's a fast moving field, the tools aren't all there yet, and the division of responsibility is not yet well known. One of the things you talked about was the need for the data people to get way right.
The quality of the answers, is it toxic? Is it something that we don't want to be displaying? So this is yet another place where we need to close the feedback loop. And all of it I found, one, wildly entertaining, because it's so technically challenging. It's so much on the frontier, and yet, and it's exposing these other problems that force us to get the benefit.
Of ai, we need to solve. And it's just exciting for me to, see this community solving them.
Conor Bronsdon: Gene, I can't thank you enough for coming on the show. I'd love to close.
Let's tell folks, where can they find your book?
Gene Kim: Oh, yeah. Just Google for Wiring the Winning Organization. You can order the book anywhere, pre order it and the retailer of your favorite retailer.
Conor Bronsdon: Perfect. We are very excited to, to read it. I am glad I got an advance copy. It's gonna be fantastic. And thanks so much for coming on, Gene. It's always a pleasure chatting with you.
Gene Kim: Oh my gosh, so good to see you again, and yeah, thank you for this.