Should we look beyond technology organizations to learn essential lessons on how to innovate and run successful, complex technology organizations? Gene Kim believes so and contains unbridled curiosity for transformation across industries, as seen in his most recent book Wiring the Winning Organization. Gene Kim returns to share new lessons in change-making for leaders and companies tackling an array of challenges.
Gene Kim is a bestselling author of several books on technology innovation, DevOps, and organizational strategy. He founded and served as CTO of Tripwire for thirteen years, an enterprise security software company, and is the founder of IT Revolution. Gene offers an engineering perspective with an executive-eye view.
In this episode, Gene discusses being inspired by Toyota and his goal to lead great organizations toward the most effective, liberated problem-solving capabilities. He shares how coordination is the layer that is the difference-maker in a successful company and offers several case studies across industries. Gene highlights three key factors in a cohesive organization: 1) independence of action, 2) time (for practice and planning, and experimentation and implementation), and 3) actionable feedback that reaches the right people at the right time.
Gene offers a metaphor from his book—moving a couch—that exemplifies his experience in communication and coordination. With this simple metaphor, Gene shares how small, cross-functional teams with the right number of collaborators are a great tool for success.
Join Gene in Las Vegas from August 20 to 22, 2024, at the Enterprise Technology Leadership Summit (formerly DevOps Enterprise Summit).
- (01:40) – Gene Kim returns
- (04:22) – Layer three as difference-maker
- (09:22) – Healthcare case studies
- (11:55) – Three mechanisms for a cohesion
- (15:04) – The CheckBox Project
- (20:29) – “Slowification”
- (26:55) – “Great in the large, great in the small”
- (29:03) – Specialization of roles and coordination
- (34:34) – The technology leader’s boss
About Our Guest
Gene Kim is an author, researcher, and technology leader studying high-performing technology organizations since 1999. Gene founded and served as Chief Technology Officer of Tripwire, Inc. for thirteen years, an enterprise security software company. He is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has organized the Enterprise Technology Leadership Summit (formerly DevOps Enterprise Summit), studying the technology transformations of large, complex organizations.
Subscribe to Your Favorite Podcast
If you'd like to receive new episodes as they're published, please subscribe to Innovation and the Digital Enterprise in Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.
Podcast episode production by Dante32.
Full Show Transcript
Patrick: Hello fellow innovators. This is Patrick Emmons
Shelli: And this is Shelli Nelson.
Patrick: Welcome to the Innovation and the Digital Enterprise Podcast, where we interview successful visionaries and leaders giving you an insight into how they drive and support innovation within their organizations. Welcome to another episode of Innovation, the Digital Enterprise. Today we're thrilled to welcome back a distinguished guest, Gene Kim. For those who might not be familiar, Gene is a Wall Street Journal bestselling author, a dedicated researcher, and a multiple award-winning CTO. His journey in studying high performing technology organizations began in 1999, and he has made significant contributions to the field ever since.
Gene was the founder and CTO of Tripwire for 13 years, where he made remarkable strides in technology and business. He's also the author of six very influential books, including the most recent Wiring the Winning Organization, as well as the Unicorn Project, co-author of the Shingo Publication award-winning Accelerate, the DevOps Handbook, and the Phoenix Project. And since 2014, Gene has been the founder and organizer of the DevOps Enterprise Summit, where he delves into the technology transformation of large, complex organization. His work continues to inspire and educate those in technology and business sectors, and he's an luminary and inspiration to many of us. So welcome back to the show, Gene. It's great to have you on.
Gene: Oh my gosh, Patrick, Shelli, it’s so great to be here again. And wow, what an introduction.
Patrick: Well, I know the DevOps Summit and Price Summit got renamed, if I'm not mistaken.
Gene: Yes. I think many people said, "Thank goodness you did that, because when people say, 'I want to bring my friends to the conference,' they're like, 'Why would I care about deployment pipelines?'" It's like, oh, no, no, it's so much bigger that. But because really about organizational design and how do you get people to work together across multifunctional silos, and maybe it's a little tangent. One of the things that really excited me earlier this year is I got a group of people together, and I would say fully a third of them, were also now being appointed to help with the rollout of things like Generative AI. So I don't think there's any surprise that the people at the vanguard of the DevOps Frontier are once again the vanguard of another important frontier. And one of them is like Brian Scott, he's a principal architect at Adobe. He used to work for Jason Cox earlier in his career at Disney,
And essentially he and another architect, Dan Neff, they've been chartered to figure out a way to safely roll out AI across thousands of engineers, as you can imagine, demanding them and trying to balance what they call maximize liberty, but also maximize responsibility. And it's just, I love it just because when he was at Disney, he was part of a group of incredible pirates that help people get to production when everyone in central services said no. And now he's part of this governance organization that's working across this vast cross-functional team, including legal compliance, InfoSec, dev product, the creatives, try to figure out how do we unleash the full capabilities to help all technologies do their work better, easily and well, but on the other hand, not introduce existential risk to their flagship products. So it is so cool.
Patrick: Well, and I think that touches on that transformation. There's an interesting thread of a story from how Agile impacted software engineering and how that spread outside of right now you have agile marketing, you have Agile.... So Agile has had an impact. Agile led to DevOps. DevOps is leading to really the transformation of how organizations operate in a more digital speed. It's never been more necessary. And I think you tell me, it seems like that continuation, especially with your new book, is more of a holistic approach of how to bring these types of strategies and approaches to think things from a more, and maybe I'm biased, but more of an engineering mindset.
Gene: Yeah!
Patrick: Because I think about sales and marketing, when you've got engineers running, that sounds like it should be terrible, but it's not, right?
Gene: Yeah.
Patrick: They actually focus on outcomes and results and there's metrics and meaningful metrics. And so is that really part of where you're seeing your work and your research starting to really hit huge impact with the people that you speak with?
Gene: Absolutely. Right on. In fact, maybe I can tell you about where the genesis of this book project came from and how I came to the exact conclusions that you came to. So you had mentioned, I've been studying high-performing technology organizations for 25 years now, and there's been all sorts of observations made, just as you did saying that there's something in common between Agile and DevOps and exactly what those Venn diagrams look like. We all have a slightly different view on what they are, but we also harken back and say there are some similarities between that and the Toyota production system, lean, resilience, engineering, psychological safety and so forth. And so I started working with Dr. Steven Spear from the MIT Sloan School of Business. And so he was part of the second Generation of Toyota researchers, and he wrote the most famous Harvard Business Review article of all time, most widely downloaded, called Decoding, the DNA of the Toyota Production System.
So that came out in 1999. That was based on his PhD doctoral dissertation that he did at the Harvard Business School. And I remember reading that in 2002 with one of my Phoenix project co-authors, Kevin Bearer, and we're just marveling at this paper, talking about how everyone inside of Toyota are solving problems in a community of scientists. It's like, "Oh my gosh, this is so amazing." So I took a workshop from him in 2014, and I can't overstate just how much that changed my thinking. And so about four years ago, we started working together to try to answer two questions, why and how do organizations work both in the ideal and not ideal? And what is in common between not just Agile and DevOps, but also those other disparate body of knowledge, like the entire Toyota production system? And our conclusion is that they're all expressions of a far greater but also far simpler whole, and that there's really three mechanisms that are at the basis of every one of these things that create and enable high performance.
And to sum up, I mean, I think there's this magic that winning organizations have across every industry vertical, across all phases of work, across all phases of valuation, that great organizations, they're able to fully liberate everyone's problem solving capabilities. And that what's made the difference maker is really in this kind of layer three wiring. So layer one is the object in front of us. It could be the patient, it could be the code, it could be the binary running and production. Layer two is the tools and technology. So that could be the MRI machine, the cat scanner, the IDE that we're editing our code in. It could be the Kubernetes platform, but the difference makers all in layer three is how do we connect our teams and people together, norms, rituals, processes, the software architecture we work within that dictate who talks to who about what and when and how.
And on the one extreme, everyone has what they need when they need it in the right format, and they can get it easily. In the worst case, no one has what they need. And so even small efforts requires superhero effort, massive coordination, costs, escalations, cajoling, politicking even to get small things done and everyone's stuck. And so I just found that really dividing what the spectrum performance looks like and isolating it to layer three around organizational wiring just to be so illuminating. It was by far the most intellectually challenging thing I've ever worked on, but it's one of the most rewarding.
And one more thing, I think whenever you study transformations, when an organization goes from good to Great, whether that's in DevOps or Agile or the new me joint venture in Fremont, California, what almost always happens is that layer one and layer two, nothing changes. Same people, same equipment, same floor space, same capital equipment. The only thing that changes is layer three. And so when we say it's the difference maker, it just really says that leaders are truly responsible for that layer three wiring that preordain how to what extent people can do what they need to do easily and well.
Shelli: All great information.
Patrick: I think it's great. And as you're talking, I was thinking the people, the tools, and I think about, hey, in the constantly globalized and competitive world, those are not areas of strategic advantage, especially with the Cloud. When we started in technology, buying an Oracle database was things only the rich could do. And so the rest of us got SQL Server or MySQL or Postgres, which I do love that Postgres is back. I always thought it was an underappreciated technology. But it does seem like when we get into that conversation, it's the execution. It's not even having good ideas anymore. And I think with AI, it's going to be even worse of the closing gap capability of strategy isn't even going to be an advantage anymore. It really is going to come down to team execution. And to me that seems like the level three of how are you evolving the way that you're working together with people with the tools as opposed to, we need to get better people or we need better tools. And it's like you're going to get a limited impact improvement there. The real impact is not only can we change, how fast can we change and how fast can we change without friction?
Gene: Absolutely. And this one "aha" moment, I'd love to share with you to respond to what you just said. One of the things that I still marvel at is something that Steve told me was that in the book, there are 24 case studies and only 20% of them are technology related. The most actually come from healthcare, specifically emergency departments. And what's amazing is that when you talk about organizations where no one has what they need when they need it, probably the best example of that is in healthcare. And so one of the case studies is about Ms. Morris versus Ms. Morrison where the wrong patient got operated on despite 14 indicators that they got the wrong person, including the patient saying, "You've got the wrong person."
Patrick: Multiple times.
Gene: Right?
Patrick: I think you're underplaying. It wasn't an insignificant operation, right?
Gene: Yeah. It was a very invasive surgery. In fact, I think not only did the patient say, "You've got the wrong person," but there was actually a scar indicating a recent surgery that's saying that the patient has been now being operated on twice Anyway. What's remarkable is that as notorious as healthcare is right now, for a kind of insufficiently sophisticated layer three wiring in the 1950s, it wasn't that way because they're basically two functional specialties. You had doctors and nurses at layer one, you had very little layer two technologies. You had basically x-ray machines, and then, so you didn't have to have a very sophisticated layer three. Fast forward in time, you have now scores of functional specialty. It's just in clinicians, you've got nursing supply chain, you have pharmacy, you have tons of technology. It's not radiology anymore. It's not just X-rays, it's cat scanners, MRI machines, blood tracers.
And imagine just how much more sophisticated the layer three wiring must be. So as you increase the number of functional specialties as leaders, we have to create increasingly sophisticated layer three wiring to make sure that their efforts integrate into a cohesive hole. So that the whole is greater than some of its parts. And so the same thing is happening in our world where we were just talking beforehand about you have people, as organizations try to do more AI things, you have to have harder specialists, you have to have GPU specialists, you have to have AI prompt engineers, AI engineers, ML ops. And so the job of technology leaders isn't getting any easier. And so it might be a competitive advantage that you can actually get GPUs these days, but in the long term, that's not going to be the source of competitive advantage. Getting drivers installed might be, getting actually all those AI disciplines integrated into the value stream, that will absolutely be a competitive
Patrick: Advantage. Now in the book, you talk about these three disciplines. Do you want to share those? I think there's some really awesome stuff there.
Gene: Yeah, thank you. And maybe to back into this, I think there's three dimensions of magic that organizations ideally have. One is that everyone's solving important problems all the time. In parallel, everyone has what they need whether that's information, approvals, requirements, decision rights in the right format at the right time. And they don't have to talk to everybody. They can get it whenever they need to, maybe even self-service. And the not ideal is that everyone's stuck. No one can do even small things without escalating eight levels. And even when they get it's in the wrong format. And so that's certainly one dimension, and that's about to what degree have we partitioned the organization and roles so that everyone has independence of action. And so in our world, that seems like modularity. It's like linearizing assembly lines so that there's clear handoffs. So that's around simplification is what we call that.
The second dimension is that there's enough time for things like planning and practice and experimentation and improvement, that we can actually have practice environments where we can actually rehearse high stakes things where we can actually undo, redo. And in the absence of that, the only place to do our most dangerous work is in the production environment where we can't redo or undo, which means we can't iterate or experiment. And so experimenting and learning, that is an iterative process. And so if those things aren't true, we have no ability to slow down, to speed up to stop sawing, to sharpen the saw, and that's what we call slowification. And so in some ways, strategy too can come from there as you had mentioned, Patrick. So that's the second of them. And the third mechanism is around feedback. In the idea we have energetic feedback loops where even weak signals of failure are amplified and can be acted on to detect and correct quickly or, even ideally, prevent.
And that means that feedback is going to the right people at the right time, right? In an actionable format. And not ideal is that you can imagine what the opposite looks like, is that weak or even strong signals of failure are somehow dampened or extinguished entirely. You can imagine a system where good ideas are snuffed out because of leadership behaviors. And when that happens, failures go undetected and grow over time. And really, we can talk about psychological safety or culture of innovation, but it's all about signals. How are signals generated, transmitted ideally received? In fact, many people say you measure success of communications by the receiver, and then what does the receiver do with that information? And that comes with Dr. Claude Shannon from the Father of Information Theory. Anyway, so those are the three mechanisms. To what extent can we slowify, in other words, slow down the speed up? To what extent can we simplify meaning, change the nature of problem by partitioning them so they are easier to solve? And then amplification, to what extent are we amplifying signals so that they can be acted upon either to prevent, detect, or correct, or to innovate or to push the frontiers of performance.
Shelli: This is incredible. I'm just curious, Gene, what advice you give to companies or technology leaders that want to implement this into their business? And it just seems very overwhelming. What are just simple ways to get started?
Gene: So there's one story that resonated with me. So someone told to me about a year ago, and we actually wrote a paper on it. It's called the Checkbox Project. So model after the Phoenix Project and the Unicorn Project. But imagine you're a part of a large mobile telco with say, 20 million customers, and the number one initiative is to put a checkbox in front of every one of the customers so they can opt into a $5 month service to get email or watch movies. The problem is that it has to cross 20 different teams across four channels to the customer. It requires CEO -1 level support, meaning daily war room meetings. That's made to cost $28 million. But the worst part is that most people give it a 20% chance of success because the last two times they tried it failed. Which I think is kind of funny, but also you're really familiar.
And so the problem here is that everyone's coupled to this project. So for anyone to get any small thing done, you have to basically get the consent of 35 different groups. And if anyone says no, then you're shut down, which is the reason why you have to have these daily war room meetings. So what we're saying is that this is not very difficult at layers one and two. This is all around layer three, around coordination. And so the goal is how do we repartition the problem so that these groups can get independence of action? So of all the things in the book that I'm proud of, it's like this simple metaphor of two people moving a couch. Let's call them Steve and Gene.
Patrick: Yeah, I love that part of the book. As a guy who delivered furniture for two summers, it really connected hard. Sorry for the interruption.
Gene: No, no, no. In fact, I love how you said that because essentially every problem that involves more than say one person boils down to this metaphor. So you might think that Steve and Gene are just doing brawn work, no brain work needed, and yet Steve and Gene actually have some non-obvious problems they need to solve. Where exactly is the center of gravity? Around which axis do they rotate to get through a narrow doorway to get through a narrow winding set of stairs? Who goes first and do they face forwards or backwards? So despite all that, we don't need focus groups, we don't need consultants. We can have some confidence that just Steve and Gene can figure out the answers to these problems just by picking up the couch, trial and error, fast feedback, some experimentation, but most importantly through coordination and communication. And so what is marvelous about this is that as leaders, there are many things we can do that will make their work more difficult or maybe even impossible.
We can turn off all the lights, suddenly the work becomes more difficult, even though we haven't changed the size of the weight of the couch, the work will take longer. They could damage the furniture themselves. But there's another difficulty that we can introduce as leaders, which is by impeding their ability to communicate and coordinate by turning up background noise like a loud siren or loud music. Or we can even introduce an intermediary that prevents Steve and Gene from talking directly with each other. We make them go through work orders or JIRA tickets or project managers or account managers or lawyers. And suddenly I think it's not so difficult to imagine that Steve and Gene will not be able to achieve the goal. And as I remember telling my observation last time we talked was that I think this was a genesis of the DevOps movement is that for large complex deployments, the information flow between Dev and Ops were so great that it couldn't fit in that JIRA ticket no matter how many fields you added.
And so the only solution was to get them to work side by side so that they can co-create, so that they can jointly solve a problem together, joint cognition. And I think as leaders, we have to understand really two failure modes of organizations like the checkbox project where we may have accidentally coupled 3000 people to one couch just like Amazon did in the early two thousands where no one has independence of action, no one can do anything independently. And the reason why you have these massive escalations is that that's the only way you can coordinate 3,500 people. So the solution there is you have to carve up the couch into smaller couches just like Amazon did in their API transformation where it became tens of services, hundreds, even thousands of services. So each group could independently deploy value to their customers.
And then in some cases, we can imagine a situation where, for example, in DevOps is like, we don't have enough coherence. We don't have enough coupling where instead of having multiple silos work together through work tickets, you actually have to just sit them down side by side, create those small cross-functional teams that ideally all the communication happens within that team. And so I don't think there's an overstatement to say, I think almost all organizational problems I've seen in layer three can be boiled down to a couch problem, too many people coupled to the couch or too few.
Patrick: And just remember to take the feet off of the couch. That's like 90% of it right there.
Shelli: Oh yeah. Right.
Patrick: And get good at taking off the railing. That solves a lot of problems. And one last bit of advice, don't tell movers to not bump it into the walls. We would inherently intentionally bump things into the wall as soon as you tell the movers, "Hey, make sure you don't scuff the walls." "Yeah, you're getting one now, that's for sure." But I think it's tremendous stuff the [inaudible 00:20:27] is a lot of great stories in the book. I remember reading about the Sloan boat racing. I thought that was a really important concept of, you mentioned Sloan before, and I'd never heard the word Sloanies before in my life, so that one stuck. But the idea that these two MBA students, if I'm not mistaken, went from participating in a boat race where neither one were involved in boat racing before to even after they're gone, the team still consistently outperforms other people.
Gene: Yeah, Adam Schreiner, in fact, he spoke at the DevOps Enterprise Summit last year about that incredible experience now called, as you mentioned, the Enterprise Technology Leadership Summit. So the two captains of the team were very experienced sailors, but everyone else were very inexperienced, most had never been on a boat before. And what was so remarkable was that by creating this learning dynamic, including pausing in production, whenever something was not understood, when something was going wrong, they stopped even in the middle of the race to basically reestablish orientation, to reestablish cohesion, to essentially slowify to improve their methods and daily work. The outcome was that by the end of that first race, they were winning all the heats, but because they were so far behind on that first heat, they didn't win. But the astonishing outcome is they went on to win for multiple years, essentially winning first place year after year, even though the captains of the teams changed over because they graduated.
It just shows, I mean, to what extent they were able to... This learning dynamic took essentially sailors with no experience and turn them into a world-class sailing team. And not only did they have no sailing experience, he had mentioned in his experience report that often English wasn't the first language of some of these team members. So they had to invent their own language because certain words that sailors use sound the same. And so they're actually inventing a new vocabulary to match the team as opposed to the other way around. It is such a cool story,
Patrick: The whole and approach of like, "Hey, it's not working, let's stop and talk." And again, we buy a lot of Toyotas in the Emmons family. I'll just be clear that whole concept of, and I do think that's the part that a lot of people miss, where this is your opportunity to learn and then you can simplify and then you can amplify. It seems to be like the real missing part is to slow down sometimes and say, Hey, I know we even talk about retros and software engineering. How often does that really happen? And the real challenge I think, is where's the meaningful results? Where's the learning? How does that actually lead to the simplification or the amplification? I see a lot of those behaviors become theater more than it is engineering.
Gene: Absolutely. And I had mentioned the Ms. Morris versus Ms. Morrison case. And so that was really meant to be the antithesis of slowification. You can imagine a scenario. In fact, the counterexample to that was the driving down of C-Lab. So this is the infection of when you insert an IV that turns into potentially fatal things, that actually drove that down to zero by doing the opposite of the Ms. Morrison versus Ms. Morris case. So in the first case when there were 14 things that went wrong, none of it was enough to overcome the operating tempo. They just kept going, eventually operating on the wrong patient. The opposite is that when anything goes wrong, they stop, study it and try to figure out what can we do to meaningfully change the environment so that it can't happen again? And by doing that, they drove down the C-Lab infection rates by two orders of magnitude. For people who have read Steve Spears work, this is very, very similar to what happened at Alcoa under their incredible CEO, the honorable Paul O'Neill, who reduced the number of accidents at Alcoa by three orders of magnitude.
I mean, think it was the average across tens of thousand workers was around 5% would get injured on a job, which meant that if you were there for more than 20 years, it almost guaranteed that you would be hurt. And if you're dealing with high heat, corrosive chemicals, large round objects that can move in these factories, it's very, very hazardous. And for them to drive down the accident rate to zero or near zero was just incredible. And that's of course very correlated with their increase in quality and financial performance. And his observation was that if we can't create a condition where people can't stop hurting themselves, how would we expect them to be able to increase quality?
And so you create the right layer through wiring helps not just safety, but also quality and financial performance. I think that is very much supported by the third mechanism of amplification. One of my favorite case studies there was about Toyota, the San Antonio truck manufacturing facility. It just paints such a vivid picture of what daily work looks like that where you have thousands of people working together with a vast supplier network and just how highly they value pausing. It's not just the end on cord, but at the end of the shift, if there is some unintended downtime, they use that to work on their backlog of experiments and improvements. And one of the things that really blew me away was when they interviewed the plant manager who actually happens to be the president of Toyota trucks, they asked him, "How much time do you spend on the plant floor?"
And I think it was only two days because he has all these other responsibilities. And he was lamenting about just how much more he would love to be on the plant floor. The plant manager, her answer was like, "It's only 60%," because she has some administrative duties. And I think it's just an amazing contrast study. Contrast that to other leaders or just how much time are they spending walking the floor assessing for themselves? To what extent are people able to do the work easily?
And this didn't make into the book, but Dr. Ron Westrom, he talks about the socio-technical maestro, five characteristics, high energy, high standards, great in the large, also great in the small, and they love walking the floor. And I think these are the things that resonated with me because it just explained some of the best leaders I've ever met. And also its absence of those characteristics explains why other people didn't meet that criteria, why they never thought they were as good leaders as maybe they thought they were. So as you said, these are observable behaviors that lead to great outcomes that look very, very different than organizations where these mechanisms are absent.
Patrick: Wow. So I'm curious, what does that mean? "Great in the large and great in the small," I think you said.
Gene: Yep. I think you had hinted at some of this. So great and large, to me that means systems orientation.
Patrick: Okay, big picture-
Gene: Process orientation and not processed in a bureaucratic process, but it's like, hey, there's a bias towards making things repeatable that we are clear about what the inputs and the outputs should be, right? Then we care about how we get from here to there. So that's great in the large, I think great in the small means, they are detail oriented. They have a sense of when things are being misrepresented, maybe things aren't quite as good as people say they are. So you match that with high energy, high standards, and then you have this love of walking a floor and you end up with a leader. And this is at all layers in the organization where people to the extent that they are responsible for, that's what enables greatness.
Patrick: That's awesome. I hear you. So I'd say the value stream is what I think about in the large. What is the overall, how do we get value to customers? How do all from marketing, sales to operations, finance, how does that all work in synergy? And then the minutia of, can I coach the tactics of what this role needs to do foundational?
Because when I think about well run organizations, it's all about being good at foundational, like the fundamentals you don't have to make, I think about the Patriots, the coach and Saban, two great football coaches sitting on the sidelines. What do they say during the game repeatedly? "Do your job." Which sounds like an accusation, but where they're actually just reminding them, just do your job. You don't have to be a superhero. We put the game together. The plan is here. You've been taught the fundamentals, "Do your job." And that kind of concept of like, "Hey, we've simplified it down, we've done the practice, we've slowed it down." And now they're just amplifying and repeating to people like, "Listen, you got A gap. You got the C gap. You don't need to worry about interceptions. That's not your job. Your job is to take this dude, right? That's your job."
Gene: Right. Specialization of roles, the coordination function at layer three, but I'll give you one that inspired me a ton. And this didn't make in the book, but for me it was just a revelation. So a friend of mine, she was describing a situation. She was one of the co-authors of the checkbox project thing. She described how in her organization, every major business feature needs an SAP role change. And they have an SLA of two week turnaround time, but the average around 13 weeks or something like that, they have a net promoter score of -87.
Shelli: Wow.
Gene: Actually, I thought the range was 0 to 100. I didn't know it was -100.
Patrick: Wow.
Gene: And she said, "We love shared services but not there." And so what she did was she said, "What we did is we took all those SAP engineers and we put them into the business units so that they could be prioritized and used however the business saw fit, and the problems disappeared. The queue times disappeared, discontent disappeared." So again, same people, but wired in a different way. You end up with radically different outcomes. And I think kind of great leaders, they're great at creating these systems. Your job is to block, don't worry about interceptions, do your job, but also be able to scan the field and say, "Oh, something's not working there. Let's reconfigure that." And I think that's part of what these great leaders do is they can sort of simulate in their head like, "Oh, I can sort of diagnose what's going wrong there and reconfigure it and then get radically different outcomes." Very much like an engineer would do with circuitry or code or for plumbing or electrical systems. So I love what you said earlier about it is how would an engineer treat these socio parts of the socio-technical system.
Patrick: But it's a great point is with an honest assessment, not with, because I think to your point on a lot of things, it's like, well, this is what conventional wisdom is. And it's like, yes, but it's not working. So it's like being in love with the outcomes, not so much your natural, because a natural, I think why do we end up in these bureaucratic at different organizations is because the human brain naturally wants to put things in buckets.
And so we're going to put things in buckets and we feel safe by imitating the buckets that we've seen other people do. And I think this is a big challenge for a lot of organizations. They see large organizations, they go, "Well, this is what they do and they're good, and so we should imitate them." And the truth of the matter is no, they're just big and they can dominate an industry much larger. It's not that they're smarter or better run, they just have a better market control than you do. And so to imitate them, and that's almost how you're going to have a competitive advantage if you're not going to find what they're not doing. So then you're not going to be able to create some kind of differentiator.
Gene: Yeah, I love that. In fact, let me give you another example that sounds totally different, but I think is another example of this socio-technical maestro-like Spidey sense. So I was talking to Dr. Mik Kersten he's the CTO of Planview. He wrote the Project to Product book and in passing, he was talking about how for them to potentially migrate a piece of their co-pilot product from say, GPT-4 to Claude 3, they're potentially in a position where that could take months. And I was like, "What? The API shape is almost identical? Why would it take you months?"
And he said, "The reason is because we decentralized the prompt engineering function. So we let every dev team write their own prompts. And because of that, that couples them to the foundational LLM which are sort of idiosyncratic. And so at this time, when the field is changing so quickly, you want to sort of maximize optionality. You want to minimize switching costs so you can switch from LLM to LLM. And so by accidentally pushing prompt engineering into the dev teams across scores of teams, you now have increased the switching costs. So it actually re-centralizing that function so that they could control and monitor which prompts were being used so that they could reduce the switching costs from say, GPT-4 to Claude 3."
I mean, it's just amazing. So it's not the same as modularity as we know it, but it has the same smell. In fact, the same characteristics as bad modularity in code is like, can you change just one side of the interface and switch out the other side without the other person noticing? So it just says that the frontier is just so wide open right now, is that those leaders who can sort of detect places where there's high cost of change and the high cost of coordination are absolutely in position to create competitive advantage and take advantage of these technologies that are coming at us every week. In fact, this week, there's been a lot of advances in AI. I mean, it's just breathtaking.
Shelli: Awesome.
Patrick: Yeah. Very good. I know we coming up on time and I really appreciate you joining us today. HENE, as always, I always love the conversation. I can't recommend the book higher to everybody. I really recommend everybody grab a copy. For some, as Gene mentioned, if you have some of these natural abilities, they will help identify them for you. I think it also gives you the ability to communicate them out to others as Shelli had mentioned, how do we share this and integrate it with the world that we can have impact on? And I think some of it is if you read the book and it's kind of a new concept, that's great. If it's something that you're like, "Hey, I already do this." I also think it gives you words and verbiage and a language to speak to others about why this is important and even steal some of Gene;s stories and just say, Hey, I know this guy. He was running this boat thing over at Sloan, so I mean, just steal his ideas. I have been doing that for a decade now, and I've never really told you that Gene, but I take credit for a lot of your ideas. I pass them off as my own.
Gene: Please do. That's what the books are for. In fact, if we can just amplify one of those points is that I think, unlike my previous books that I've been a part of, this one is aimed at a different audience. And so you can say the Phoenix Project was really aimed at the VP of IT operations. The Unicorn project was meant to be aimed at the developer. DevOps Handbook was around technology leadership. Wiring the Winning Organization, the audience that we had in mind was the technology leader's boss on the observation that so much of the success of the technology leaders often depended upon how tolerant their boss is. And if you change out that boss, right, either they will continue their rate of fantastic successes or it will die.
And so we really wrote the book for my selfish purpose, taking everything that Steve has learned in his journey, everything that I've learned in my journey, and really trying to boil it down to something that is universal. That someone not just in different industries like aviation engine design or someone managing a squadron or a ship in the US Navy, but in sales and marketing across every industry, showing, hey, they are common factors that create high performance that will be recognizable to any leader regardless of where they gain their experience.
And so my fondest hope is that this book will give additional evidence and ammunition for technology leaders to help bridge that gap to their boss and their boss's boss and their boss's peers to say, "Hey, look, if we want one team working towards a common goal for the good of the organization, these are case studies that we should study and see if there are things that are applicable to us." Just like the Phoenix project, I'm hoping was a tool for people to look at this kind screwed up company that has nothing to do with us, but does any part seem familiar? I'm hoping that Wiring the Winning Organization does, not just the technology organization, but for other people that matter, who we need on board in order to achieve the most important goals of the organization.
Patrick: And Gene, I really think part of this is I look at all of the books and there's almost like growing up together. Each time it's like you're expanding the scope because these are the things you're witnessing. These are the things. So I feel like I've been growing up with you through-
Gene: Likewise!
Patrick: And now we're getting to that enterprise of like, listen, this isn't even about technology anymore. And it is because that's an important part and that's our background. But the truth of the matter is the lessons that we've learned here are universal. And so bringing that engineering mindset is so I just look at it like, Hey, I'm trying to figure out what your next book is going to be about, I don't know, running a board or something. Right? We got to keep elevating to that next level. So again, thank you for joining us.
Shelli: Yeah, thank you.
Patrick: Another shout out real quick. So as we mentioned, Gene has his Enterprise Technology Leadership Summit coming up here in August 20 to the 22nd. It's in Vegas. It's an amazing community of people. I've always enjoyed going, you always learn stuff. You're able to connect. It's such a great community that he's created. If you're interested in not just DevOps, but creating high performing technology organizations, you can register for that at ITrevolution.com/events, and I highly recommend it. It is a great community, Gene. You've done a wonderful job with it. I've always enjoyed the events that you guys host. Just tremendous opportunity to learn from other people. A lot of times, events are more marketing for their own products. Gene puts the spotlight on everybody else, and it's just a tremendous service he does for us all to learn from some really amazing people.
Gene: Oh, yeah. Thank you so much. I learned so much every time that we get a chance to interact, and so much of that on my part was similarly informed by this amazing group of technology leaders who are absolutely pushing the frontiers of performance. So yeah. Thank you so much.
Patrick: Awesome.
Shelli: Awesome. Well, thanks for being on the show, Gene.
Gene: Thank you so much, Shelli, and thank you as well, Patrick.
Patrick: Oh, thank you. Want to thank our listeners, we really appreciate everybody taking the time to listen today.
Shelli: And if you'd like to receive new episodes as they're published, you can subscribe by visiting our website at dragonspears.com/podcast or find us on iTunes, Spotify or wherever you get your podcasts.
Patrick: This episode was sponsored by DragonSpears and produced by Dante 32.
