Today I'm talking to Gene Kim. Over the years Gene's work has had a huge influence on me. From books he authored and co-authored including The Unicorn Project, Phoenix Project, DevOps Handbook, and Accelerate, to his advocacy and community building with the DevOps Enterprise Summit, now called the Enterprise Technology Leadership Summit.
I recently finished reading Gene's latest book Wiring the Winning Organization which he co-wrote with Steven Spear. The themes of slowification, simplification, and amplification have already started to seep into my day-to-day conversations. The book is filled with case studies, but also creative metaphors like Gene and Steven moving a couch, which is where our chat starts.
I’ll be working on getting this podcast findable on the major platforms, but for now you can use this RSS URL: https://api.substack.com/feed/podcast/24711.rss
Transcript
John Cutler: [00:00:00] Hi, this is John. Today I'm talking to Gene Kim. Over the years Gene's work has had a huge influence on me. From books he authored and co-authored including The Unicorn Project, Phoenix Project, DevOps Handbook, and Accelerate, to his advocacy and community building with the DevOps Enterprise Summit, now called the Enterprise Technology Leadership Summit.
I recently finished reading Gene's latest book Wiring the Winning Organization which he co-wrote with Steven Spear. The themes of slowification, simplification, and amplification have already started to seep into my day-to-day conversations. The book is filled with case studies, but also creative metaphors like Gene and Steven moving a couch, which is where our chat starts.
John Cutler: Gene Kim, it's awesome to have you on my podcast, the beginnings of my podcast. How's it going?
Gene Kim: It is doing great and congratulations on getting the podcast up and running. I mean, if it's as a rewarding as the podcasting journey has been for me, even though it's been a hiatus, I would be so happy for you. So yeah. Kudos. ,
John Cutler: I wanted to start with a question that perhaps relates more to my personal experience while reading your latest book, which is I stumbled on the chapter about simplification. And as someone who talks about the beautiful mess and how we often oversimplify I found myself initially resisting the framing.
And so I was curious how you would explain it to someone if they're interested in the difference between simplification as you laid it out in the book and maybe the trap of oversimplification.
Gene Kim: No, totally. In fact, can I get your permission to do like 90 seconds of performance art around the couch metaphor? Which I think for me was like one of the biggest aha moments. Let's just think of what might be a relevant example, could be a very useful example of, of Steve and Gene moving a couch.
And so you might think that this is all brawn work, no brain work allowed. And yet, you know, there's actually a whole bunch of problems that don't have obvious answers, like, you know, where's the center of gravity, to get through a narrow doorway around which axis do they rotate? And, you know, to get through a narrow winding staircase, who goes first, do they face forwards or backwards? And of course, they don't need consultants or focus groups, right? Just by picking up the couch, fast [00:02:00] trial and error, um, but most importantly, communication coordination, we can have some confidence that Steve and Gene will be able to achieve what they want to do.
But there are all these things that we can do as leaders to make their work more difficult. We can turn off all the lights, right? Which makes the work take longer. They can actually, uh, hurt the furniture, hurt themselves. But there's another thing that leaders can do, um, you know, such as introducing a lot of, uh, noise, loud music, or even introducing an intermediary, where Steve and Gene can no longer talk directly with each other. They have to go through work orders, JIRA, tickets, you know, account managers, lawyers, so forth. Suddenly under those conditions, we can imagine scenarios where they will not be able to achieve their goal. So it's so interesting, right? We haven't changed the nature of the couch. We've actually changed what we call the Layer 3 wiring.
And so I think the couch is such an interesting metaphor because it really embodies two very important concepts. Coherence. To what degree can Steve and Gene work as a coherent and unified whole? And coupling, right? They are inherently coupled to each other through the couch.
A little side note, I think that is really the birth of the DevOps movement. For example, when doing complex deployments, there's no number of JIRA tickets or JIRA fields that can accommodate the amount of information that needs to be transmitted that, you know, and if you don't get that bandwidth, it ends up with like in the Phoenix project. So to your point about simplification, I can now, I feel like, you can now characterize almost every organizational sort of dynamic through the couch.
It's either, the couch is like coupled to too many people, say 1500 people at Amazon, where like even small actions require like superheroic effort of communication, coordination, escalation, cajoling, politicking, you know, daily war room meetings, because no one has independence of action. So Amazon is a great example of this that led to the thou shalt use APIs. But it can also explain, I think what could be viewed as mutually contradictory, like in 2023, that prime Amazon prime video article where they said "We went from microservices back to a monolith." And reduced cost by 95%. And I feel like the couch metaphor explains that as well.
So in the first case of Amazon e-commerce in 2000, they chopped the couch up into lots of, you know, [00:04:00] hundreds, thousands of little other smaller couches, enabling independence of action. In the Amazon Prime Video piece, it was as if they chopped up the couch too small. And so it meant that doing sort of routine daily things required coordination, but in their case, transport all these little microservices or Amazon stuff functions were just copying data in and out of storage buckets, right? And so by gluing it back together into a monolith, they re established coherence, uh, and locality, right? So that everything's at hand, right? There's no copying back and forth.
To your question, I think, you can ask this question of like, "To get things done that you need to get done are you on the sort of one extreme where there's like too much coordination needed? And it's because of like too much coupling? Or is it the opposite extreme where there's also lots of coordination, but it's because we've chopped up the pieces too small?
The phrase I learned working with Dr. Steven Spear, you know, famous for his work in the Toyota production system, was the word independence of action. One of my favorite examples in the book is the checkbox project, right. You know, imagine an organization where the top initiative is for this telco is get a checkbox presented to the 20 million customers so they can opt into a $5 a month service to get movies, check email, et cetera. It has across 20 different teams, across four different customer channels, it requires CEO minus one level support, daily war room meetings, $28 million dollars. The worst of it is that most people give it a 20 percent chance of success because the last two times they tried, it failed. No one can do work independently of each other. Everything is so coupled together.
I feel like it's nice to be able to focus on what you want to do. And you can independently do your work without having to get permission from 35 different other groups, right? I mean, it's not that what they're doing isn't important and that you don't care about it, it's just that from your own parochial perspective you can get done what you need to get done, you know, without [?] that was one of the findings from the state of DevOps research is the importance of architecture.
Can I give you like another one? Like this is also an independence of action one. Lars Albertson, he was formerly Spotify, formerly Google sort of in the data plumbing space, right? Which it turns out to be a very important capability. He gave such a great example. He owns a Volvo and he sent me two things that he got from the Volvo user forum.
It's like, you know what? I have the mobile app. And they get a lot of notifications. [00:06:00] But here's a notification I really want. Your car is parked outside, your sunroof is open and it's raining. Like if only, if only there was a way, you know, to get the data from the temperature sensor and the windshield wipers and the sunroof, but you know, one can imagine, uh, that like in many organizations, it's like freaking impossible, it will take 11 months for each one of those. And you're just getting no leverage. Right. What you want to do is just send a notification when these three conditions are true, but it's like you're coupled to everyone else in a very not good way. If you look at the plumbing of these amazing organizations, right, where they have like billions of, you know, ETL things going on every day. It enables devs and dev teams and data teams to just get on demand what they need to, again, without the need to pester someone for 11 months.
So the question I now I'm starting to phrase and ask is how much would you pay to gain independence of action, right? So you can work independently of other groups, through platforms, through services, through APIs. And I think the answer is a lot, right? And there's even a whole hing about economic theory, the whole option theory, was that how much would you pay to be able to defer a decision, right? That was Merton, Black, and Scholl. So it's like, it turns out a lot, right? Because if you can defer a decision, it creates optionality. And I think in the same way, in the orthogonal way, to partition yourself from everyone else so you have independence of action is also worth a ton to people.
John Cutler: One thing I loved about the DevOps Enterprise Summit was it felt like you had leaders from, --excuse the way I'm going to frame this-- real companies, I mean, companies that have been around for decades, that were major mega brands known the world over. And, my impression of these companies is it was an order of magnitude more complex than let's say a company that's just selling a digital product. You know, you're a company selling a digital product. You can rationalize how you'll spend 25 percent of revenue to build that product. People are going to sell that product. They're going to use it. You get subscriptions. It's great. The whole company's around that. And we can talk about whether it is actually as simple in practice for those companies. But you're bringing [00:08:00] companies up onto the stage that have so many touch points, so many technologies. They have COGS for the actual shoes that they sell. They're printing money in many cases, but they don't know how long that will last. How does your advice to companies differ based on whether they are this sort of complex mega brand that doesn't sell digital products versus maybe, you know, an upstart newly public tech company.
Gene Kim: That's so relevant. I literally has having a conversation with a friend of mine. So the DevOps Enterprise Summit I've done 20 of those conferences. It's now called the enterprise technology leadership summit. It's interesting in the early years we had a rule, like no unicorns allowed no tech giants. Yet over the years, I mean, I think it's kind of a revelation, a creeping realization, has been like, we're all, we're all the same now, right? I mean, if you talk to someone at Spotify or LinkedIn or Shopify or an Amazon, they have the same socio- technical problems as, anybody else. you know, large, complex organizations like Barclays have been around since 1695 or UK HMRC, the revenue custom service that's been around since the year 1200. I think the older the organization is, the more they have sort of like these calcified legacies where it's like genuinely hard to engineer out of.
Like the Walmart story from Scott Havens. I mean, it was amazing, right? His remit, uh, was to re engineer all the supply chain software for the world's largest company. He came through the jet. com acquisition. That was flipping awesome. When he said, uh, if you go to the walmart. com site and you get the item availability information. It took 23 deeply nested API calls, all that which have to run at four nines, all have to have an SLA response within 50 milliseconds, right? Really expensive. And because the outage cost is so high, they can't deploy independently. In other words, architecturally, it looks like they're decoupled, but like you deploy one at a time, because if something goes wrong, you need to isolate what you need to roll back. And so essentially it was all coupled together.
And so, like, by moving to event sourcing, by moving to a, kind of a pub submodel, they flattened that out, uh, so that it went from 23 deeply nested API calls to one. The 23 services, you know, slowly got migrated [00:10:00] to the system they were architected into. They could run at two or three nines of availability. They could respond within seconds, right, saving tens of millions of dollars. I mean, it's just awesome.
But, you know, they did this despite all the decades of legacy at Walmart. And yet there's a rumor that at Google, there's a financial reporting server that's still on Pacific time zone and over for decades, you know, they've tried many, many, many times people have bet their careers that they're going to be the one who can get that server switched over to Greenwich Mean Time uh, you know, how God intended, like, because, uh, time zones are out to kill you. And apparently like that's not so easy. So like even in these new companies, you know, there are these problems that I don't think they're stupid. I think there's this, this category of problems that large organizations face when they have business critical built up over decades that you just are really, really hard, hard to change.
John Cutler: I noticed through a couple of examples in the book, that there is an element of culture in the companies that are actually able to refactor while the train is barreling down the tracks. And when I think about the Toyota Way or if I think about all those mix of principles and practices and rituals, it does force me to scratch my head a little bit. How does culture play into this? And, and I know your appreciation for lean and ideas around lean. How does lean actually apply in maybe countries that aren't as communitarian or collectivist or willing to slow down and take a long term view?
Gene Kim: So, you know, Dr. Ron Westrum, famous for his work on culture-- we leveraged his work so much in the state of DevOps research with Dr. Nicole Forsgren and Jez Humble--but he also introduced me to the term, the socio technical maestro. And it's like five things, high energy, high standards, great in the large, great in the small, and they love walking the floor. I'm like, when I heard that, I'm like, " Oh, I get it." It immediately sort of explained kind of the people I admire versus the people that I admire less. So I think there's a kind of a norm they set. Like high energy, high standards, right? A need to go see for themselves and desire to enable people to do their work easily well. To me, that's like a [00:12:00] big element for me that I didn't, until he mentioned it, I didn't, I never really saw it. It just sort of popped it into focus. You know you need that in large organizations and small. Not just at the very top, but, you know, at every layer in the organization. And I think what that does is it, is this constant quest for greatness and meeting a high standard leads to this need to have a lower cost of change.
And I think that's a, I think one of the key nerdy aspects of the Toyota production system is they make small changes all the time in the context of daily work, you know the andon, the number of routing changes and so forth, and it's not being done from the home office. It's being done by everybody all the time at high frequency. And, you know, I think we can see the analogs not just in kind of Technology and DevOps, but you know, in great product organizations. So I think those are the things that you would expect to appear, in kind of dynamic, improving organizations.
John Cutler: I wonder. It is about time and how we perceive time in the sense that I don't know if many people can even wrap their head around a decade's worth of change. Most people aren't there for a decade. Most, most people wander in for two, three, four years, at least in, you know, some parts of tech and then kind of wander out. And so the sustained effort that's required, maybe people don't necessarily see the whole picture for a particular organization, especially in companies that people are leaving after two years or leaving after three years. Yeah, maybe you could speak to that long term component. It seems to be a thread to me that the idea of the long term view for the company that these, that these things are a foundation you're building to create this engine of change, this engine of adaptation, requires, almost necessitates, a bit of a longer term view.
Does that match your research that you see or what's the value to the short term view?
Gene Kim: I love what you just said. I mean, I was going to say one thing and then it's really two things came to mind. I mean, the first thing that I was going to say was, you know, it was always fun kind of researching the DevOps Handbook was, you know, I was going to all the like conferences, Velocity and so forth where it was [00:14:00] all about like, how do you keep AWS and Pinterest and, uh, you know, these high growth companies, Facebook, how do you even keep them running? Right. Like during, you know, 2007, 2008, Facebook, Twitter, the fail whale. I mean, it took so much engineering ingenuity just to keep the site up and to keep up with growth. So, you know, that's like one relentless arc. Right.
But there's actually another narrative that I love studying in the ETLS community, the enterprise technology leadership community. What it takes to muster that? So I was thinking about Fernando Carnago, he's VP of Digital at Adidas. And the story started for them after they heard Jason Cox from Disney present in terms of how they built internal platforms and what was their sort of like staffing model and how they saved the day for business units. And so what that led to was a certain meeting, I think at like 2 AM, by the elevators at this hotel lobby where they finally got what they wanted. They approved, you know, the top five business units agreeing to donate, or give 300 of the best engineers to create this shared centralized capability. They were making a bet that they would create great platforms that everyone could use to achieve their own different parochial business goals and fast forward in time by four years later, we're in the middle of the pandemic, he has 1500 engineers working for him. It's the only revenue channel that is still operating, you know, during the global pandemic. Chaos ensues, right? Those kinds of stories I just love, right? Where a decision was made to kind of rewire their organization with this different goal in mind and out emerges these technology heroes, right? Who are, have the best long term interest of the organization at heart.
John Cutler: It also matches the book in a sense too, that if you're not able to at least understand that you're making some incremental progress, that part of the feedback loop, it can be very, very difficult to sustain that effort. Right? So I have this saying, you know, imagine a two by two and on the bottom, it's work, small work, big, and the other one is think big and then think small. And if you're, if you're working big and thinking big, it just takes forever. There are plenty of companies that work small and think small, they just don't have a strategy. It strikes me under the [00:16:00] amplification section of the book these long term efforts still require a sense of progress. Otherwise they probably peter out. So I think it resonates in that balance between the need sometimes for a catalyst and then the need for working small and getting that incremental progress. But the thinking big part, that seems like something you really need those long term thinking leaders to lay those foundations in place.
Gene Kim: The story that reminds me of is like maybe one of the most unsung stories at Spotify, which was, I just heard about this on the corecursive podcast, which I really enjoy. It was about the fact that Spotify was getting ready to go public, they would have essentially have to start showing effectiveness controls for how they deploy software. And they had to come to grips with the fact that every team deployed software differently using different tech stacks and so forth. And like the idea of like layering on those, uh, control requirements to every dev team is like a non starter. And that led to this initiative to create a shared service around, uh, deployment and so forth.
That was probably date driven, right? I mean, the consequence of like not being able to go public because of a CICD program that's not complete, right? Uh, not palatable to the people who mattered. And so that was thinking big, but you know, starting small, gaining hearts and minds, one team at a time.
I absolutely love that. And I just love this kind of mutually contradictory, like the couch, Amazon stories. At Comcast, they have 8,000 engineers, right? So it's Universal Pictures. It's Sky Networks and so forth. They gave a presentation in 2020 that said, "Hey, we want every engineer to be innovating all the time, everywhere, except for CI, right? We have 14 CI pipelines, like we should have one, maybe two. And it was actually, you know, because of some sort of like mishap where there's just wasn't enough expertise on one of these 14 platforms. Johnson Moore, their chief software architect, he said "It was amazing that we could get it done, that we could come to some agreement of what it should be, because no team had a short term gain, but everyone saw the long term [00:18:00] game." And so I just kind of appreciate that. We have this vast space of work and make decisions and decide, you know, what do we want that look contradictory and yet, you know, it can be complete, valid, and very good for them.
John Cutler: One topic that comes up a lot in the product community is the idea of empowerment. An observation however, is that the strategy is in place and people are relatively excited about it and the architecture is the blocker. The empowerment people really need is more structural, it's more architectural.
But if you were going to extend the idea of empowerment to not just, a leader saying, "I'm giving you some decision rights or authority", but if you were to think of the other ways we create empowerment, how could you apply that frame maybe to the different topics in the book?
Gene Kim: Let's explore the two extremes. I just heard this yesterday. It was this beautiful phrase by a business leader of a multi, hundreds of billions of dollars assets under management.
And he said, " When you have like empowered teams that don't understand the goals, they are pivoting and iterating to oblivion. Right? It's like, there's just no, they're there. Right? And so that's,
John Cutler: Think small, work small.
Gene Kim: Right? Exactly. I love that. And it was just so great. So that's a, a failure of leadership, right?
And maybe if I can just sort of connect some dots there, right? It's their job to enable like this system so that all the components are working towards a common goal. There's this other piece that you put your finger on, which I find very frustrating, you say, "You are empowered, you have the decision rights to make decisions to achieve your part of a greater goal." But then they're stuck, right? They're like the checkbox project.
They're like the hypothetical Volvo, uh, things like, " Oh, for me to achieve, to do what I need to do, I need these, temperature, windshield wiper, and, uh, sunroof data feeds. And, um, now I'm stuck in line. It's gonna take 11 months each and now I have to cajole, politic, escalate, right, play games, to get what I need done." How much would it be worth to create the system where everyone has genuine independence of action, where every one of these capabilities is [00:20:00] self service? And I think, for Amazon, I mean, it allowed them to not just thrive in the eCommerce capability, but those capabilities arguably, led to so much option value that it became AWS, which is the highest profit generator for Amazon. It starts hinting at sort of the tools and the thought processes that leaders should make. Otherwise you have thousands of people who, in the absence of having independent action, they're stuck. And, and, and that's, that's terrible.
Here's what I feel. I think what we're observing is this kind of co evolution or convergent evolution of, practices that show up in startups, that shows up in tech giants, that shows up in enterprises. You know, things like shifting left. You know, for security and it's not just like you put static code analysis in the CI CD pipeline, what it really means is that the dev teams are fully responsible and accountable for securing the stuff they ship and you build it, you run it. Developers, you build it, you run it, right? So therefore you own the production quality and maintainability of the code you write. So it means decoupling from the security function, right? It means decoupling deployment away from the deployment engineers-- the Brents in the Phoenix Projects-- and, you know, give the tool so that developers can do it themselves.
Similarly, you know, cloud, build your own VM's, anything where you can get self service on demand to enable decoupling that's happening. And the reason why we need to decouple is because you have these functional specialties, that must get integrated into everybody's daily work, but there's just not enough of them to go around. And because if you run it as a shared service tickets, everyone's just waiting, right? They become as stuck as a checkbox project. My feeling is that we have this ever growing number of functional specialties. The job of technology leaders is not getting any easier. And in some of these cases, it's like vast rewiring of the systems. Those model builders actually have to be on pager duty because like when they're, you know, things are generating toxic responses in production, you know, they're accountable and responsible.
So it means that we have to have this ever more sophisticated layer [00:22:00] three wiring, in our organizations. And I think this explains why we have this kind of convergent evolution not just within technology but, you know, in, every industry in every phase of value creation and every type of work.
So in the book, we have like 24 case studies. 20 percent of them are technology related. The most number of case studies are actually health care related just because emergency departments are so notoriously dangerous because people often don't have the information they need, there's lots of functional specialties, there's lots of handoffs, and it leads to some just kind of harrowing and sometimes, devastating outcomes.
But Steve said it wasn't always that way. In the 1950s, it was actually far simpler. You had essentially two functional specialties. Doctors and nurses at layer one. At layer two you had very little technology. You had x ray machines. And that was kind of a slow cadence of operations. So you didn't have to have a very sophisticated organizational wiring to coordinate those efforts. 70 years later today, we have 20 to 40 different functional specialties among clinicians, nurses, supply chain, uh, pharmacy.
And that's at layer one. Layer two you have, it's not called radiology anymore, it's catscanners, MRI machines, blood tracers, so much technology. And so you need a much more sophisticated layer three wiring. The real arc is as we increase the number of functional specialties, you know, Because we're actually relying on just a several tools to actually coordinate and integrate their efforts together.
John Cutler: Maybe during the initial growth phase of one of these tech companies, when they aren't necessarily being challenged on any sort of fundamental level, their challenge is their scale. At that point, there is a high premium placed on the independence of these groups, and they haven't necessarily developed these sort of complex wiring challenges yet.
We have independent teams and we're going to ship as fast as possible. We're going to throw people at the problem and it's going to work itself out. And then maybe what you're seeing in these larger companies is that unless they're able to muster a more [00:24:00] collectivist response, at least initially, maybe they're going to go back into their independent silos because, you know, maybe good, good neighbors have walls, you know what I mean, right? Maybe they are going to go back into their silos, but they need to at least understand during those periods of re architecting or refactoring the organization, you almost need to see the big picture. You need to muster those sort of collectivist responses to it.
That's one thing that comes to mind based on what you said where at different times for different companies and at different levels of complexity of the wiring needed you maybe get this pendulum swing between solidifying around how things are working. But then when there's some element of disruption you have to expand out and take a bigger view. And then figure out what you're doing and then go back to that level of modularization.
But um, that's just my my initial take
Gene Kim: I love what you just said. Can I, um, react and....
John Cutler: Absolutely, say it back, because I don't know if I made any sense.
Gene Kim: Let's go to that checkbox project for this mythical, telco. At one point, it was okay for the four channels of the customer to work independently of each other, because there was no reason for the stores to talk to the customer service call center, to talk to the you know, digital mobile teams and whatever. And so you could run them as contained entities that don't have any connection except for their collective bosses.
I love sort of thinking of these as like, almost like circuit boards, organizational wiring, right? But now something has changed where it actually requires much more, um, oh like, like in a car. For an internal combustion engine, there's actually no reason for the battery team to talk to the brake team. They can work totally separately. Even if you put them in the same room, they have nothing to talk about. But an electric car, right? Like now they need to be talking all the time. In fact, they have mutual dependencies for fuel efficiency, regenerative braking. You have to reconfigure systems so they can actually talk to each other without having to go all the way up to the CEO and then down, you know, eight levels.
From internal combustion engine to electric car, what is that transition to the checkbox project. What needs to happen so that these four different channels with customers, [00:26:00] you know, are now working in the right way. So the right people are talking to the right other people at the right time, at the right frequency, et cetera,
John Cutler: One story that comes to mind there is Brian Chesky recently did this interview about Airbnb. That almost perfectly describes the pendulum swing, right? It's, it's Airbnb. It's a great product. We're going to hire a bunch of talented product managers and let everyone do their own thing. Great. Uh, it's growing, growing, growing, growing, growing, and then it hits the pandemic. And then it forces them to think about, " Oh goodness, we have an end to end Airbnb experience. What, what have we done here? Why have we created all these competing teams?"
And it turned out they had way, way, way more dependencies than anyone would care to admit. And I've noticed that a lot in tech companies is that, when things are in the ascension, people downplay the dependencies because they don't want to necessarily contribute to the collective good. As long as someone else is feeling the pain of the dependency, they don't care. They're just gonna keep moving, right? And so you saw this big pendulum swing where apparently, you know, it swung all the way to these groups and no one was getting anything done. He admitted there was super high WIP, there's all these dependencies, and then he needed to kind of exert this top down shock to the system to reset it back in that direction.
But one could imagine that this pendulum swing will go in either direction. Again I'm going back to this amplification part and thinking about feedback loops. It would seem that companies could have an advantage of detect this change earlier so that the swings are not as violent. It feels like many of the layoffs we're experiencing now are a function of inertia without correctly predicting the direction things would come when they would swing back in the other direction.
Gene Kim: That all resonates so much with me,. In the book, one of my favorite lines in there is like, Winston Churchill said, "We shape our buildings and thereafter they shape us." What a wonderful way to say, you know, "We create the wiring of the organization and then it shapes us." It sort of controls what we see, it controls the way we behave. And wouldn't it be amazing if there was some way to detect when, like, the wiring is no longer working with us. It doesn't [00:28:00] require, like, the problem getting so bad that, you know you have to do these major, major changes, right. Because the pendulum went too far? Wouldn't that be great. Just to say it explicitly, I would like to think that what we try to put into the book is-- we're starting to write down, what is it that these socio technical maestros have that allow them, you know, to sort of detect when the wiring is wrong, right? And allows them to sort of make these changes in a way that can be done incrementally, uh, right? Think big. Works small, but not for the product, but for the system that people work within.
You know, you know what, you just convinced me. These are the exact same concepts on orthogonal planes. One is on the product. One is, you know, you have the product, you have the process and you have the organization and architecture. What you can do to one, you can do to the other two. I have now moral certainty on that, John.
John Cutler: All right. for the podcast then.
Gene Kim: I'll give you my proof point because I asked Jez what was your biggest aha moment writing Lean Enterprise?
He answered right away. He said, " The same sort of experimentation that you do, like with Lean Startup and pivoting and so forth, you should do to your processes as well." Oh, I'm going to extend that by one. And you should be able to do the same thing with your organizational wiring.
John Cutler: I think if you just put product to the side, it's a form of problem solving that's contextually appropriate, thoughtful. Back to your socio technical maestro. What is their style of problem solving? I've used this phrase recently of justers and butters. Justers say you just need to build this and but people say, but you can't do this, but you have to do this.
Your socio technical maestro persuades me that they ask enough but questions to understand the context and then they have a bias to action to work small. So we're just going to get moving, right? We're just going to do this thing. and, so there's...
Gene Kim: And they also have enough of a mental model where they can sort of simulate in their head, right? Kind of like what's going to happen if I sort of set incentives this way versus this way. I'll give you a great one. My friend, going to not mention her name, she said we had this problem where we had, uh, an [00:30:00] SAP role engineering function that, you know, every major business change required something from the team. SLA of two weeks. However, they're averaging 11 weeks and that had a net promoter score of negative 87, I didn't know net promoter scores could go negative. I got the whole range of the function wrong. She said, we love shared services, but just not there. They broke up that group, embedded those SAP engineers into the business units and suddenly the problem went away. That rewiring essentially got rid of contention and there's probably some coordination, but there's no prioritization. It's like, do what the business units need. What a great example of understanding the organizational wiring, characterizing the problem correctly, and intervening correctly. Love it. Does that resonate with you?
John Cutler: Absolutely And I think that's a great spot to finish up here because that was very, very inspiring. We meandered along to get to this, but I think we were building up our conviction for something towards the end there. So it was great to have Eugene. This was wonderful to chat with you.
Gene Kim: This is great. Yeah. I'm such an admirer of your work and I got to tell you, I'm leaving with an insight that actually want to run with. Because I think it's really important is it's not the butters and adjusters, right? It's, there's something different. There's something in the middle that's worth characterizing.
John Cutler: Absolutely. Great chatting with Gene. This is inspiring.
Gene Kim: Thank you, John.
Share this post