LIQUID - How CTOs Harness Complexity to Unlock Flow

Speaker A: From 7ctos. My name is Etienne de Bruyne and you're listening to the CTO Podcast. Every week I spend time with fascinating people that enrich the lives of chief technology officers around the world. From perfecting the basics of building technology organizations to inspiring our minds into shaping our future. As always, the CTO podcast is brought to you by seven CTOs, helping CTOs become world class leaders. Let's go.

Speaker B: All right, welcome to today's episode. I'm excited because we're diving into a book that feels very apt for the moment. And it's called Liquid. And it's written by three people who spent their careers leading teams, building companies and navigating the messy, unpredictable, high stakes reality of modern technology organizations. What makes LUKIT so timely is that it doesn't just talk about the hard skills of engineering or product. It looks at the hidden systems, the complexity walls and the invisible forces inside companies that either accelerate you forward or quietly grind you to a, uh, halt. And it does it in a way that's fresh and in a storytelling format, which I enjoyed a lot by the way. With practical frameworks you can actually use, you could literally walk away from this with some things to put into practice right away. Today I'll be talking with the authors about where the idea came from, how three people managed to write one cohesive book together, which I'm so impressed by, and why the lessons in Liquid might be more important now than ever. So whether you're a founder, a cto, a CPO, or a cpto, or just someone trying to lead in a high change environment, you're going to find ideas here you can put to work immediately. So let's dive in. So before we get started, I kind of want the readers to get some insight into the three of you. So the first question is, who are you when you're not writing about leadership and complexity?

Speaker C: I'm a dad. I am a dog owner. I am a prolific reader. I do lino cuts and print artwork. Um, I have a lot of hobbies and I take on a lot of roles, but complex adaptive systems, I would say, are my obsession.

Speaker A: You have a lot of hobbies, Scott M. Like what?

Speaker C: Well, I mentioned one linocut. Take a piece of linoleum, um, and you carve images into it, and then you can put ink on that linoleum and you can make prints of it.

Speaker A: Whenever I get asked, what are your hobbies? I, uh, I just get filled with shame because I'm so bad at taking care of myself.

Speaker C: Well, you're just Busy. You're just busy.

Speaker D: Well, I. I can answer the question. So I, too, am, um, highly creative. So right behind my monitor here is my easel with my paint station. So I do acrylic painting. I am so still learning how to paint abstracts, which is surprisingly really hard. Much harder than copying a picture. So that's cool. Yeah, I do lots of other types of creativeness. I'm really into making jewelry right now, which is super cool. I'm setting up a, uh, jewelry station, jewelry bench in my basement right now. But of course, we had to finish the basement first, so I'm actually staining the concrete floors myself. So, again, creativity. Right? So that's me. I'm, um, a wife. I love cats. I live in Colorado, which is beautiful all year round, which I really love. And I spent a lot of my free time out of work, really wanting to just help other entrepreneurs be successful.

Speaker A: So.

Speaker D: So that's kind of my passion. That brings me joy.

Speaker A: To me, staining concrete sounds like work.

Speaker D: Not like it is work, but it's fun. It's gorgeous. It looks like, like hand hewn leather. It's awesome.

Speaker A: I don't know, Nishant, what do. What do we do for hobbies, man? Nishant, what do you do for hobbies?

Speaker B: My hobbies. In search of a hobby?

Speaker A: Yes. Yes. I, I. My name's Etienne. Super happy to be here. Uh, super proud of our book. Thank you, Nishant, for hosting the CTL podcast.

Speaker C: Yeah,

Speaker A: I think that my primary concern is my wife and children, so I am always dad. And it's interesting to always look at my life and my activities through that lens. I am a systems thinker, and I also like to think in terms of how to make hard concepts easy to understand. Mostly because my brain needs that. I find that. I love to dig in and do deep research. But for me to remember the stuff, I find that I have to tie it to simple concepts. And that's why my, my colleagues love it when I start with the alliteration and the S's and the p's and the D's. But I really have to do it because otherwise I can't remember the stuff that I. That I'm researching or reading. And, uh, I just have to tie it to something that I can remember. But, yeah, I love. I love music. I. I do play, and I don't play in a band right now, but I love my bass guitar. And, uh, I am ctoing and also building seven ctos and then also building out cto Sentinel.

Speaker C: Beautiful.

Speaker D: I also Know you love coffee and you love to ski.

Speaker A: Okay. I love snowboarding. Yes. Thank you. Sometimes it takes your friends to remind you of how they see you.

Speaker B: Yeah, I used to remember a lot. Like, anytime I would tell share, uh, with that Tiana challenge that I'm going through, you're always like, you're missing the three E's of entrepreneurship. You know, I. To be like, holy cow.

Speaker C: It's kind of.

Speaker B: He's got a number and an Alphabet, you know, for everything. Uh, yeah. It was always fascinating to hear how Etienne saw the world.

Speaker C: So thanks for saying that.

Speaker A: He's saying fascinating, but I think he's saying super, super damn annoying sometimes.

Speaker B: Yes. I feel like, oh, here it comes. The number in the letter.

Speaker A: You need the Fibonacci sequence for counting your tickets.

Speaker B: So this is really interesting. I feel like you all have gone through this really sort of. Sort of a magical, crazy, fun journey together. So what is the one unexpected or unusual thing you learned about each other through this process as you were writing Liquid?

Speaker C: Well, I've always been really fascinated and in awe, um, of, uh, Etienne as a. As a communicator of ideas. The first time he showed me a draft of the levels framework, I was amazed that he could put all of those ideas onto one A4 sheet of paper. It's like, to me, it was like black magic, right? So that's something that I knew about him to begin with, but I got a little bit more of a peek under the hood about how he. How he does that as we were writing this book together. He, you know, he. Everything that Etienne does is sort of connected to his empathy. I, uh, feel. And, you know, when we were talking through some of the really complicated and esoteric ideas in this book, it was easy for Etienne to grasp. I can almost see, like, the readers behind him, like. Like, he always had the readers in his mind. M. Like something. They just, like, live with him in his brain, which is not how I experience the world. And one thing I didn't know about Kathy is what a strong voice she has. Kathy did like, the vast majority of the actual writing in this book, like, the sitting down and hitting the keys and editing and getting the text to be readable and engaging. And, uh, it just. She has a very clear. She has a very clear voice. You ever read a book like, Stephen King is also, like, a really good example of this, right? It doesn't matter what the story is. If you're reading a Stephen King book, you can hear Stephen King, right? And I feel like that Kathy has a way of saying things that is very unique to her and is. It's very commanding. It builds trust. And I just did not know that she could write like that. And I was amazed at the stuff that she was producing. You know, when you generate some text out of an LLN like her, her running is the opposite of that.

Speaker D: Oh, um, thank you.

Speaker C: Yeah. I mean, like, it doesn't sound like the summing up of every business book she's ever read. It's. Her voice is unique to her. So I would say, you know, those are the two things that I learned.

Speaker A: Yeah, I love that, because I found, Scott, that you and I would go off the deep end on stuff, and then it would be a real safety net to have Kathy say, wow, guys, how about we put that in book number seven or book number eight?

Speaker C: Or maybe never? What if we never put that in the book?

Speaker A: But it did feel. I agree with you. I think the voice of Kathy, for me, is very strong in this. And what I want to share is a very special moment we had when we were sort of struggling, I think, a little bit, because we had so many ideas and so many thoughts, and, you know, we. We actually made a pretty solid pivot in the book, I would say, when we. I mean, initially I thought this book would just be about levels and, oh, uh, levels this, levels that, and these levels and these blocks and. But I think over time, we realized that the complex adaptive system really looks at the four sentinels as emergent properties. And I think once we started coalescing to that, we. Kathy actually said, guys, how about if we follow. Write a story? Like, uh. Like, how about we follow the story of some founders? And. And I think initially I felt a little bit like, oh, man, you know, how are we going to capture that and how are we going to do that? And. And then Kathy, very quickly, I think this is one of her strengths, was able to draw from her experience, I think, pretty quickly. And the Personas of Alice and Thea were born. And even as an author, I felt related relatability with these characters. And so it was fun to see ourselves progress. And, uh, maybe this is what screenwriters go through or playwrights, I don't know. But you start developing a relationship with these people and you start feeling. And as Scott mentioned, because I am so strong on empathy, you know, I started feeling empathy for these two people, fictional characters. So, uh, it was amazing for me to see that in Kathy. And then I think what I saw in Scott was bursts. What I did not know about Scott was there's a time you don't talk to him. And it's somewhere between frying eggs and, and frying bananas and pouring coffee. Like, uh, there's somewhere where the lights aren't on, but, boy, when they come on, you need to be ready. You need to be there, present and accounted for, because that's when the genius will flow. And then sometimes Scott, mid sentence, I'd realize, hang on, Scott's gone. Like, I. He's done. You drop the mic lift. He's still sitting in front of me, but he left the room like he's done. And so I think I have new respect just for the sheer, just the sheer energy that, that, that you consume, Scott, to, to come up with some of your profound ideas and prolific thoughts. So I, you know, I. I've known you for a long time, and so I. And it's mostly been through virtual relationships, you know, zoom calls and slack. So spending this amount of time with you actually trying to fuse our thoughts together, I did realize that I have a very different way of thinking and being productive than you do. And so that, I think, has been part of the reason why I think we've produced something special, because it was really the fusing of the way the three of us works. Sometimes Kathy would just say, guys, I can't listen to you anymore. So she would just go off and go and write, like, thousands of words. And then we wouldn't know where she was, what she was doing, and then she'd come back with a, uh, perfectly written chapter. So I was very impressed with, with how that all worked out.

Speaker D: M. I'm, um. I was really amazed. A lot of people ask me, why. How. How can three people write a book? Doesn't that seem like total chaos? And you' stepping over each other and you end up with a book. I've seen books written by multiple people where every chapter sounds different and it's just really hard to read. And so what I found brilliant about the three of us coming together is that we all have our strengths and we all acknowledge our weaknesses and, and we all come. We all took different roles in the writing of this book. You know, we talked about Scott, and he's so deeply into the philosophy and the science behind what we were writing about that. And he knows everything about everything when it comes to complex adaptive systems. I'm like, whoa, I didn't even know that. Scott, right. Just deeply ingrained in that and can talk for hours on it. And I just learned so much from that perspective. But I don't come from a Philosophical perspective about things. I'm very much an operator. How do I do it? Playbook? What's the structure, the process? How do I get to the outcome? And so when I took the role of writing, that for me, like really fit my mold of the operator who can make the thing happen. And you love to write much more than I love to speak. And that uh, Etienne, uh, is like so eloquent at uh, uh, being able to take a concept and turn it into the spoken words that can really like pull the whole concept together and, and what I mean by that, pulling Scott's philosophical view into my operator view, like he's the glue between this and. It was just so fascinating to see that dynamic of all three of us in action. You know, we did, we took a four day retreat up in Winter park where we did probably about 30% of the writing and all the structuring of the book. And it was just so beautiful to see that diversity at work in that timeframe about when we wrote this book. And then of course we carried it forward to writing the rest of the book where everyone played their role. And it just reminds me of how important it is in business for everyone to play that role with Hire cookie cutter. We hire someone in that fills our weakness. And um, we want to be surrounded by people that like, latched together like a puzzle where we all fill our own roles. And I think we just did a great job of this, uh, where we all just really played to our strengths.

Speaker B: It almost feels like the words out of your book are coming alive a little bit. Like you all were a complex system and because in the book also you talk about specialized roles. Right? And you're, all three of you are CTOs, you're all professional CTOs. But then you all had to come through in this setting, in this context, in very different ways. And how those things can work together is sort of the beauty of, you know, complex systems.

Speaker D: Right.

Speaker B: So the ability to adapt in that, that's great. It's incredible. So take me back to the moment where liquid becomes an idea, like what was happening in your lives and in your careers to sort of say, Kathy, Scott, Etienne, we need to write this book like what was happening at that time.

Speaker A: Yeah, we, we, we actually talk about this in the opening chapter, the which. Which really is a, uh, it's really fascinating for me how the three of us were really on the same journey. I think experience obviously solidifies a lot of thinking. I think a lot of people have experiences as CTOs. They learn a bunch of things on the fly. They formulate their opinions, and then there's some learnings and playbooks and frameworks that emerge from that. Um, but I think what was unique for the three of us was I think that we were all dissatisfied with just treating the symptoms or here's this, the way in which you address the hiring pipeline. You know, it's, oh, you can't fill it up fast enough. Well, because you're not networking in, you know, oh, you should. You need to be speaking, uh, like, there's a lot of things that I think, uh, engineers want to processify. And, like, this is how you go from zero to stood up in a predictable, immutable way. And I think the three of us were on a journey where we were like, no, there's something going on that no one is looking at or no one's really seeing. And for me, it was my first. I would call it my first real failure as a cto, where it was a tangible F up, where I really messed up. And here I am, the founder of 7ctos, and I'm Mr. CTO to so many people, and I'm this and I'm that, and I go and do a CTO job, and I completely screwed it up. And for me, from that emerged my. My paradigm shift, which was, hey, there's a frame of mind in a technologist, which is, let's how do I produce technology that will satisfy some business problem? And for me, that was from the technologist out, like, okay, this is what I do. I have to be technically proficient. I have to build a team. I have to have great timing in knowing when to solve which problems. I have to have this massive tool chest that I can draw upon. And. And I actually applied that thinking to that job that I failed at, which I talk about in the book. And I realized that I wasn't thinking from the business back to me. I was thinking from me to the business. And the reason I failed was I was providing what I thought was solid, sound technology principles and leadership prowess, when really I was. I was in a failed system and I wasn't being a partner to the CEO. And that's. And that's really the birth of what I called the Sentinels and what Scott called something else and Kathy called something else. We were all sort of coagulating around this idea that there are healthy emergent properties that happen when you are doing and focused on the right things. And that's what I brought to the table when I shared it with Scott. Scott was like, well, I'm building a Thing called. What was it called, Scott? Full.

Speaker C: Uh, it doesn't matter. I can't even remember anymore.

Speaker A: But it was, uh, he had a framework. And then we started thinking, wow, this is really interesting that we're, you know, and Kathy and I had been working together inside of seven CTOs and other ventures, and we were like, hey, we're all actually thinking. We're thinking about this as a systemic issue. So, hey, cto, don't go in and go do all these things and, you know, pat yourself on the back because you are amazing at some domain or you have got a prolific network or you have been there, done that attitude. Oh, I've raised series D and E's, and I've, you know, the investors bring me in to fix it. Like, uh, no one cares about that stuff. What we all care about deeply is can you see what is going on and what is needed? And the three of us were just. Whenever we got together, we realized, man, we are actually all saying the same thing. And that's when we realized, you know, what levels were starting to be developed. And we just started realizing we not only do we care deeply about the custody of and the purity of levels, there is a lot more going on beneath the surface and that the world should really know about. And then the three of us looked at each other and were like, wow, should we get married? Like, should we define the relationship? And so that's how we formed levels os, which. Which is sort of morphed into CTO Sentinel. And when we thought. And I think Scott was the one who said, dude, we have to get this stuff in a book. We have to get the book. A, we have to organize our own thoughts because there is a lot going on. B, the world first needs to understand what we're grounding. Ah, our thinking in before we start saying all sorts of things. Oh, levels is this. And levels is amazing. Well, no, not. Not really. If you don't empower it and you don't understand why it works, it's just another framework and it's just another thing that some consultant is shoving down your throat. So I'll stop there. But that's what it was for me.

Speaker D: I m find it interesting how much as humans, we want to solve complex problems with simple solutions, right? We just want the playbook. We just want to know how to do it. Especially as engineers, we just want to jump to the solution, right? And what I found really interesting when Etienne's like, well, I got this stuff for a book, and it was really like, more like a handbook for CTO levels was the original concept. And fascinating that we, all three of us just kept talking beyond that level of content. You know, yes, the how to do something. The playbook's incredibly important. These are solved problems in the world. We don't need to be resolving the problems. The playbooks are pretty clear. But it doesn't matter how well you know the playbooks if you can't understand the system that's operating beneath it.

Speaker C: Right.

Speaker D: You know, uh, you could do all the playbooks in the world, be perfect at all those things, and still fail as a CTO because you don't understand how to wield what's going on under beneath. And the three of us just kept talking beneath what was going on beneath. And we're like, that's the real book. The real book is not a, uh, how to manual. So many books out there are how to manuals. The book is like, how do I see what's going on? So that.

Speaker A: Yeah. Which I will confess, I did write the first version of this book, and it was purely a manual. It just really went through the blocks of levels. And my two compadres were like, uh, uh, no, brother, we're not doing that well.

Speaker D: And, you know, now that's all openly available on CTO level.

Speaker A: Well, yeah. Not only did they say, we're not doing that, Scott and Kathy were like, no, we're putting that out there for everyone to use and see. And my poor South African entrepreneurial scarcity mindset was throwing a fit because I thought I had some magic. Wow, guys, we've got this beautiful grid. We can. We can. I used to say, we can Brene Brown the crap out of it, you know, and. And I'm so thankful to my two partners here for really just bringing something so much bigger to the table. M. And honestly, I don't think we used a single sentence from my original draft, so thankfully, that one is in. Is Is in that place where all bites go to die. But, yeah. Scott, what did you think?

Speaker C: You know, I think what set my feet on the path to my two co writers and solving this problem together was a question that my boss asked me. And I, uh, talk about this in the book. One day, my boss just came into my office and we were doing great. This is a company that went from zero to $300 million in revenue in just a few years. And he came into my office and he asked me the question, how good of a CTO are you? And I thought that was a very stupid question because I was like, look at the Numbers, you know, we're doing great. But he was a lot smarter than me about that. Because what he was, what he was trying to get me to think about is what is the job of a cto? And on an absolute scale from the worst CTO in the world to the best CTO in the world, where do you lie on that continuum? And that got me thinking about the job a lot. And then after that I did consulting work and I would ask myself that question, um, am I being a good cto? And that kind of led me to the conclusion I didn't really know what a CTO was. Like, what's the proper work of a cto? You know? And at the end of the day, Liquid is our answer to that question of what a CTO is. What is the proper work of a cto? And it's all about keeping the system going, keeping the system running, about being a good steward and shepherd of, uh, all of the other work that people are doing in the organization and keeping that complex adaptive system cohesive, flowing and liquid. That's what the CTO's job is. And that's what you can read about in the book.

Speaker B: I love that. Considering the timing of the launch of this book, which I believe is August 19th next week, why now? Why is this more important today than ever?

Speaker A: Who?

Speaker C: I have an answer to that question, but Kathy, I think, I think you might have one.

Speaker D: Go ahead.

Speaker C: Well, I think that, you know, not to put, not to put AI on every single technology podcast, which is something that I'm against. But since you asked the question, why not?

Speaker A: Hey, we just got a boost in our, uh, social.

Speaker C: We get to wedge some, um, AI in here. Right. I think that the concept of having AI agents write code or produce things or take, take a role in the organization, like how excited about that people are and the potential that people see in that, uh, leads me to conclude that they don't really know what technology organizations are and technology companies are.

Speaker B: Mhm.

Speaker C: I think that maybe it would be a good time for people who run technology organizations to recall an organization as a collection of people. Right. And that whatever machines produce on their own will not be the same as what people produce together for their own purposes. And what Liquid is about, it's not about machines. It's about people working together and overcoming their individual limitations by finding other people who are different than they are and working together and making that. Just like the three people on this podcast had, uh, to fit together like puzzle pieces. And we, we made something that we couldn't make without each other. And that's what liquids. You can't replace it with machines. It's not a function of the quantity of intelligence in the organization. It crosses the organization. It's greater than any individual in the organization. It's how nature creates something out of nothing is by adding up dissimilar things and making something completely, uh, new.

Speaker D: I love the why now? Conversation question. Because if you think about it, uh, when technology kind of came into its own, we were releasing software once a year, then maybe once every six months, and then once every six weeks. Right now we're at days or minutes to launch software. And what's interesting about that is the rate of change is so fast that we actually no longer can have rely on the craft or the skill of what we need. You know, if it took you a year to write software, you could apply your skill and, you know, make this most beautiful thing. But today, like AI comes to be LLMs. And of course, AI has been around forever, but AI came to be, it's fast now, vibe coding. Now anyone can do anything, right? Your skill or your craft is actually not what propels you forward anymore as a cto. It's how can you problem solve? And who teaches technologists to problem solve at a strategic level, right? You have to problem solve how to write this function or that function when someone writes your requirements for you, your user stories. But what if you're sitting in front of a blank piece of paper and a CEO is saying, how are we going to corner the market? Our value as ctos is shifting from the craft of the technology to actually being the problem solver, being the person out there that can understand the complexities and how to wield those complexities together to achieve a business outcome for our company. So our value is in the future and the ability to see. And so this feels like why now liquid is because if you can't see the system that's operating, you can't wield it, you can't influence it, you can't direct it, because you can't see it. And so, uh, for me, there's just so many factors of complexity going on in our world today, whether it's in technology or in our country or the world. There's just so much complexity. And if we can't understand the complexity and how it's operating, we won't be able to influence. And there's no simple solutions to complex

Speaker B: problems at the end. Any thoughts? Why now?

Speaker A: You know, I think all I'll add

Speaker C: is

Speaker A: the concern I was feeling, you know, Obviously I founded seven ctos. And one of the first things that actually took me by surprise in 2012 was the premise of 7ctos was how do I get the right people, 7 people in a room to talk to each other and share their challenges. And the easiest way to answer the question of like, tell me about your company. Like, oh, I'm the CTO of a. The answer nine out of ten times is not. Is, is, is not. I don't think it's the right one, which is, oh, we are a 50 million dollar company and we're, you know, the, this revenue number that gets thrown around and, and it bothered years that that was the. And of course I had this business challenge because at 7ctos, I had to get the right people talking to the right people in, outside of our peer groups. And I was just seeing year in and year out, and I know Nishant that you are intimately familiar with seven CTOs, but year in and year out I was watching these peer groups struggle. Two ctos of $10 million companies. I could be having very, very, very different problems. And said differently, the CTO of a billion dollar company can have the exact same problems as the cto of a $2 million company. And my concern was, what the heck? Or uh, you know, how do we to what Scott said earlier, like, what does the CTO do that has the revenue number not be the leveling factor? And so for me it was that pursuit. And I think this was my individual journey of which I said earlier, both Scott and Kathy have had their own journeys. But for me it was there has to be a different denominator for complexity. Like, well, comparison I should say. I wasn't using the word complexity as much as I do now, but I was like, how do I get the right people around the table who can actually talk to each other and uh, share in each other's challenges? And that was when I, I realized, you know what? It might. It's, it's the, the CTO is entrusted with resources. Uh, at its most, I would say at its most frivolous statement could be, hey cto, we are giving you X amount of money, X amount of resources, and we want you to just make sure we reach our technology goals. And that's when I started thinking about this notion that, listen, the number of people and the amount of money that the CTO role is entrusted with can actually make or break that person. In fact, one of my most seminal moments in this thinking was in a 7ctos forum. I was leading a 7ctos group. And we were month in and month out, the six or seven people are sharing their challenges. And there was this one guy who was moseying along on his product development roadmap and his business challenges. And every month he came back with his challenges and they were bootstrapped and they, you know, and they were finding some product market fit. And it was a pretty predictable story of scale, uh, on the bootstrap path. But I remember him coming in one day and saying, guys, we just landed a $50 million investment. And that guy, I thought he was going to cry. M. And I. Not because of Joy. Yeah, he was, he was afraid, was a friend.

Speaker C: Ah.

Speaker A: In that moment, his whole paradigm shifted from do more with less to get more so you can do more. And he didn't know how to do it.

Speaker B: Mhm.

Speaker A: And that's when I realized, you know what, a CTO who knows how to work with a $50 million budget, I, uh, mean, it wasn't all going to go to him, but let's just call it 20 million, let's call it 10 million. CTO who can work with a $10 million budget would eat that challenge up for breakfast because that's what they do. It's not a problem. But for him, who was sort of scratching around for like, uh, uh, an extra a hundred thousand here and an extra half a million there, it was an almost an impossible task. And he was, I've never seen in my whole professional life someone as afraid as he was in that moment. And like I said, he was tearing up like he was afraid. And that was when I was just, you know what? The true leveling factor for the role of CTO got nothing to do with what the, the health of the business and what they're generating. It's the whole, well, we're a team of five and we're generating 10 million in revenue a year. Like that stuff all falls away. It's like a complexity factor, at least organizationally increases by the number of people and the amount of money that you have been entrusted in your role to build the technology organization. And so the answer to the why now? Is just that it's actually been why for the last 10 years. Can we show the industry, can we show CEOs, can we show investors, can we show fellow CTOs what they're signing up for? Since we released levels, we have been able to tell CEOs don't go and get someone who is used to a level. Let's call it. I'm not going to go into the levels now, but let's just say level 10 organization. When you're building, when you're comfortably running a Level 3 organization, the guy who knows Level 10 isn't automatically going to be great at, uh, running your Level 3 organization. And so the amount of CTOs and CEOs and investors we've been able to help and say, listen, go find the person that can operate inside of that complexity or that complex adaptive system. Have them do it has changed how people hire. I mean, I think Scott and Kathy and I have been involved in several, probably countless placings where we're able to say, I know exactly who you need. And it's not because we have a Rolodex of resumes, it's because we know the complexity that this system requires, someone who can, has managed that complexity and nothing more and nothing less. And so I feel like even now, to all Scott's points about AI, that's the stuff that we need our industry to understand and to see. And that's where Liquid really goes in and says, take a look at the state of your organization and understand that as a complex adaptive system.

Speaker B: So in this book you all like weave this story in. The fictional characters are named Alice and Theo. Alice being the CEO, the founder of the startup, and Theo being the principal founding engineer who becomes a cto. Right. What was the idea behind that? Why did you, what did you think that you were going to gain by telling this story of Liquid through these, through the eyes of these fictional characters?

Speaker D: I can jump in on this. So one thing I find. So I talked earlier about how philosophy is not my thing. I need to put things in concrete terms. And I think it's important to lean into how people think, how they learn, how they process information. And I was doing a talk about a year ago, it was at Techdoor's FounderCon and I was talking to a room full of CEOs and CTOs and I said, who of you are systems thinkers? 300 people in the room and like two people raised their hands. It's because it's complex. Systems thinking is complex. Seeing 2, 3, 4 orders of magnitude away, how something you're doing today is influencing something, it's hard, right? And many books around systems thinking are very theoretical or they use examples where people don't really understand. It's not like in their day to day. And we really wanted to anchor this really pretty complex thinking into real world example. And um, several of us have been through companies, been through growth I've been through from early stage startup all the way to enterprise and so it was really helpful to take Alice and Theo from conception of an idea all the way through all the challenges that we see hundreds of times when we talk to CTOs or CEOs out there, when we talk to them about their business, to take them through all those common challenges so that people could see themselves in that moment, um, with that challenge at that time. And then to see the pattern that Theo and Alice applied to really move it from either boiling or freezing back to liquid, right? So that they're flow again. And every business goes through these ups and downs. It boils a little, so you bring it back to liquid and then it freezes because you went too far. And I think it was just really helpful to weave the story in there so that everyone could see it in a way that they could place themselves either in Theo or Alice's shoes.

Speaker C: I'll tell you one reason why I think it was that we made a good decision when we decided to turn this into a narrative, is that the thesis of this book, or one of the central ideas of this book, is that there are that the fate of every company, every technology company, every company is largely determined by, by the interactions of several large complex adaptive systems. And that that is invisible, because it really is. You can't directly see or experience these systems. And every contact that we have with a complex adaptive system is as a subject of that system. And that you can only explain the operation of a complex adaptive system through a, uh, subjective lens. And one thing shows, not to show the entire history of this company through the eyes of the cto, because Alice has a different subjective experience of the operation of that system than Theo does. And every person inside of a complex adaptive system that is part of it only sees a slice of it. And it's only by combining those different viewpoints that we can get a sense of the operation of the whole. And in Liquid, Theo and Alice have conflict, conflicts arise. And these are conflicts that, uh, basically we've seen them and we change the names. These are real conflicts that we've seen and we'll see again inside of technology companies. And you know what the underlying cause of most of that conflict is? Not talking to each other and not sharing each other's subjective experience of what this complex adaptive system is doing at that moment. And one of the big takeaways from Liquid, where I hope you'll, when you get to the end of Liquid, that you'll say to yourself as a CTO or a CEO, is that I don't really have control of this company or this technology department, I don't have any control over it at all. The best that I can do is influence its evolution over time. And if I have any hope of doing that, then I'm going to have to combine the subjective experiences of everyone in the system and management techniques, what teams we decide to create, what rules we decide to, and best practices and culture we decide to install into the complex adaptive system is really just a function of combining everyone's perspective. And if you can, when you get to the end of liquid, come away with that, I think you're going to be a better leader and I think you're going to make better technology. But, you know, we'll leave it up to the reader to decide whether or not we've accomplished that.

Speaker B: Thumbs up from Etienne.

Speaker D: Yes.

Speaker B: Like multiple thumbs up. Yeah. In fact, like one of the earlier interactions when there was a problem with the Alice and Theo, uh, as I was reading it my blood pressure was going up because I was like getting some instant PTSD from some conversations I've had. And the fact that Theo was just repeating himself again and again. I, ah, like wanted to reach into that book and just like, dude, change the sentence.

Speaker C: Change your words. Yes.

Speaker B: Speak Spanish, do something. Don't say the same thing, man.

Speaker A: Yeah, and also it also forced us to, yeah, it forced us to step out of La La Land. And again, I imagine this is what screenwriters go through. It's like it was such a brilliant tool for the three of us to be able to talk about these two characters as, and not have some sort of personal stake in the outcome. Because, uh, we were like, we really. Because I can clearly remember Scott and I would go off on some theories and then, and we'd be like, oh, yeah, but you know what, now we have to talk about how this, this applies to them. And it was hard. I mean it wasn't easy because there's of course multiple outcomes, there's personalities, there's random acts that could affect things. But I found it to be a, uh, very good tool for. And maybe that's one of the reasons the, the tri unity of our authorship worked so well was because in the end we were writing Alice and Theo's story. And that I think, got a lot of our own, I would say our own. And I'm speaking for myself, maybe my own agenda out of the way. It's like, oh, uh, I've got to promote levels. Oh, levels always works. Oh, this always how things are. And then when you start thinking about Alice and Theo, like, no, that's not And Scott and Kathy and I also have different experiences, uh, whether it's being a founders or co founders or whether it's being CTOs or hired guns or fractional. And so it was a way for us to find alignment in Alice and Theo's story and not somehow pushing our stories. That's kind of why we got our stories out of the way in the beginning as quickly as possible. So that it was like, let's just get that out of the way so we can all put that down and not have it be something we constantly come back to in the book. And I, and correct me if I'm wrong, but I don't think once we go back to any of our own stories. No, no, I want to talk about what happened to me in this chapter. It's like, no, dude, we're talking about what Alice is going through right now. And it's harder on her than it is on you right now.

Speaker B: Bro, bro, bro.

Speaker C: Yes.

Speaker D: I think one of the other things that really stands out for me is that there's no like, right or wrong, good or bad. Like there's just things that happen in darkness. And then you adapt. You adapt to what happened. And Alice and Theo's story isn't all happy path. They run into a lot of challenges. There's a lot of turmoil, there's a lot of introspection that they each have to do. And I won't disclose the stories, but like, world is not perfect. Just here's what happened and here's what we're going to do next, and here's how we keep ourselves stable and growing and as functional as we possibly can. And that's that state of being liquid.

Speaker B: So the interesting thing about complex adaptive systems is that we always feel like in that system there's something, there are forces that are working against me. And I've been in the same position where I'm explaining myself. And as I'm explaining myself, I'm mostly pointing my fingers out and saying that the reason for the issue is that, and the reason for the issue is over there. The reason for this issue is out there. For an adaptive system, we tend to think as an us versus them type model, uh, when it's all part of the system. So even if you have vendors, if you have contract, whatever the case may be, right? Your customers, your investors, your board, whatever, it's all part of that system. And sometimes I feel like us, uh, as ctos, we like small systems and we don't like to enlarge the boundary of that system to Anything else. And the uncomfortability then comes is that when that boundary starts increasing because naturally the second you go out of, you know, you're building it in, in your garage, giving it a customer, there goes your circle.

Speaker C: Right.

Speaker B: Your boundary just went out. So immediately. Now this is complexity because you're bringing in somebody that if you have been doing your job well, you've already included them in the conversation. But more than likely for a year you haven't talked to anybody. You're getting all the thumbs up from family and friends. Right. So what is it about this hidden world that you all speak about? The secret world that exists and the thing that we are not able to sort of like, we don't want to go, we don't want to venture out. What's behind that, what's going on there?

Speaker A: Yeah, I love that because, and I want to, before Scott says something, I want to just jump because I know Scott has, has a lot to say on this. I love that because I love what you said. That there's this feeling that it's, there's forces working against me. You know, I think CTOs can fall into that trap very quickly and adopt sort of a bit of a victim mindset which is you guys want me to X and I only have Y and you guys want me to keep. And then it's the scope versus features or the triangle question. It's like it's. I definitely relate to the, the forces against me and, and I think relating to my story earlier, I think scarcity is a very comfortable place for ctos. I don't think we like to admit that, but we know how to work with it. Yeah. Because our whole lives we're like, we've built an app by ourselves, we write thousands of lines of code by ourselves. We pull off the all nighter, uh, to produce the feature seconds before the deadline. Like we know very well how to work with scarcity. It becomes very different when scarcity is removed. It's like, here's a blank check. Go make it happen. That is unknown territory. And I think that's why we are tempted to keep our worlds small. You know, I'll uh, go hire three more days. Well dude, if I hire three more devs, that's three more standups and that's two more teams and that is six more complaints and that is seven more relationships. You know, and then the second thing I want to say is I think, think it has something to do with a uh, boundary of certainty where we like to certainty is something that we want to Live inside of. There's. I know very few CTOs, to be honest, who thrive on uncertainty. Like, I know developers and technologists and I mean, give me a, uh, one sentence and I'll go build a whole freaking prototype. So I know a lot of us love the thrill of building some new thing that solves some esoteric problem that, that really came out of thin air. But when it comes to organizational management and uncertainty is very dangerous. You know, you're talking about livelihood, overall happiness. All it takes is one developer to come into your team and make you hate your job. You know how it feels when your devs are happy versus when they are fighting different job. It's one. It's a job that you hate. Like, I don't like it. I really. It affects me. And so I think we artificially, and hopefully I get some hate mail for this, but I think we artificially shrink the number of components and keep it close to our chest so we can operate in a zone of certainty that we are comfortable with and has the most predictability for us of the outcome. Now that outcome could be really bad. But sometimes I just think that's the outcome I predicted and that's the one I'm comfortable with. Whereas if you start having wide open spaces, man, all bets are off.

Speaker C: Yeah, I agree with Ant. And I think one of the key things that one key observation that you made in the shot when you were teeing up this question is that, uh, people aren't comfortable with organizations growing. Right. So like, deep down, I think we all understand that this is about scale and scaling and the way that complex adaptive systems must change their behaviors and their internal characteristics in order to reach a different scale. I think, uh, most people know the possibly apocryphal quote by Joseph Stalin when he was asked about the quality of his tanks and he was producing a lot of them, and his famous quote was, quantity has a quality all of its own. And that is absolutely true. And this is not something special to technology companies or companies or societies or organisms. It's the way that nature works. You know, I can pull a lot of examples from nature. For example, insects. Insects do not have a vascular system. The fluids inside their bodies just sort of slosh around in there. Well, you can't get very large if that's the case, because once your parts get too far apart from each other, that doesn't work anymore. And you have to have a vascular system to get bigger. And that's a different type of organization.

Speaker D: Yeah.

Speaker A: Uh, you see why Kathy and I, you see why Kathy and I love having Scott on the team.

Speaker D: Exactly. I was thinking the same thing.

Speaker B: How, uh, did you think vascular system was going to be brought into this conversation? Right.

Speaker C: Yeah. And so I would wrap up that digression by saying that technology companies are special kind of companies. They're a special class of companies. And that's why a CTO is a special type of executive. Because the promise of a technology company is that if I insert this tool or this technology into my market, that will fundamentally change that market, and that's going to cause my company to grow much faster than other types of companies. So CTOs have to have a greater capacity to cope with rapid organizational change than other types of executives. And the character of that change is that it's sudden. The thing about complex adaptive systems is they generally do not change in straight linear ways. They change in nonlinear way ways.

Speaker B: Mhm.

Speaker C: And that has to do with critical points and, and phase transitions and a lot of complex terminologies. But we've all seen it. If we're technology leaders, we've come in one day and suddenly the, the development team can't make, change the system anymore. You know, we've come in one day and it's the same product, but all of a sudden there's been a radical sudden change in the customer's behavior. And that's the world that we live in. And that's the reason why there's this impulse to try to not do the one thing that technology companies are supposed to do, which is grow rapidly.

Speaker B: In this book, you're sort of like speaking to CTOs, but I kind of feel like you're speaking to CEOs as well, and you're really trying to really convey to them that they're actually a very integral part of the this, of this working right. Of this, of this working well. And you know, some of the, some of the challenges that I see in technologists is like, they need to have an answer for everything. Like, I feel like, you know, when I show up to the executive call, I need to be answer boy. Because whenever I get a question, I need to be able to have the answer and it has to be the right answer. Right? Or, uh, sometimes, like Noel Nishant, I'm looking towards you, literally, I'm, I'm looking towards you to have the answer to this question. And so immediately my brain, my survival mechanism kicks in and I'm just like, oh boy, I need to get, I need to have this answer. But it almost feels like the CEO and the CTO are co Sense makers, like they're looking at the system that they're in and sort of trying to make sense of it. But it's really a together experience. But it's coming through those different lenses, as you all are, you know, sort of mentioned, you know, in your relationship, right. Is that you see things different. And in that sense making process, it's really both of them coming in with those inputs. Right. And then making sense of it together. So what is it that you want to communicate to CEOs that is so integral to making these complex, adaptive systems successful?

Speaker D: I can jump in here. So you're right. We're speaking to CEOs, CTOs. And to be honest, any C suite, a company is made up of a series of systems. Technology is a system, product is a system. Within technology, there's subsystems, your different teams and things like that. But within a company, there's marketing and there's sales and there's finance. And there's a lot of complexity about how all of this organizational complexity interacts together to achieve the mission of the business which we want to increase revenue 100% this year. Right. Sounds so simple, doesn't it? And from a CEO's perspective, he's like, just why are we not increasing revenue 100%? And if a CEO just continues to see it as a simple problem and not complex across all the different facets of the organization and how all the parts of the organization integrate together, the boundaries between those organizational units have to work in tandem, in unison together to achieve that revenue gain. The product has to be there so that the go to market team can sell it and the marketing team can market it, and um, the finance people can take the money and the customer service team can support it. The CEO needs to see the complexity of the system at play within their business so they can orchestrate it. They need to make sure that those boundaries are all between. Each of those organizational components are in alignment with each other. I think of them as the conductor at a symphony. And if they can't see that complexity, how are they ever going to drive it and achieve those goals? And so a lot of times in my work, I come in a lot in turnaround situations. And most of the time it's because the CEO is thinking that the solutions are simple to something that is really complex and they're not really orchestrating across the organization effectively. Or maybe it's the marketing arm is not, or someone is not seeing the complexity of the system and so therefore it can't be orchestrated. And so if you have A CTO coming from, like, I understand I can only influence this system. And the CEO is saying, just fix the problem. You're at odds in how you're communicating, and you're not going to be in alignment to deliver on that mission of if it's going to take five, six, seven steps to influence a system and the CEO thinks it's one, you're not in alignment. And if you want an effective business that can really grow, you all have to be in alignment and seeing that system. So it really is written to anyone who's orchestrating the complexity of a, uh, business at this level. So through the lens of the cto.

Speaker A: Yeah. And I remember throughout the writing that Scott would bring our attention to, hey, you know, it's really important that the CEO, uh, gets it, you know, And I, I think if you think about the states we talk about, which liquid comes from our concept that systems or organizations could be in one of three states that water can be in boiling. Well, boiling, I guess it's more like steam, but it's a, uh, boiling state, frozen state, or a liquid state. And I mean, hey, no shade to CEOs, but that's a really simple thing to understand.

Speaker D: Well, and you know what's fascinating, Nishant, is when you watch a pot of water boiling, you can't tell the water is warming up if you just visibly look at it.

Speaker B: Just look at it. Right.

Speaker D: It looks the same. It looks like water. It looks like water. Oh, everything's great. And then all of a sudden, it's like boiling and steaming and spattering out of your pan. Right. And so that's how quickly, if we're not paying attention, that's how quickly a phase shift can happen in our business. And once we hit boiling, way harder to get it back to liquid than if you actually just turned the temperature down when it was warming up. So, like, as a CEO, how can we bring that visibility to a CEO with language that makes it simple for them to understand and ways to identify those patterns that are happening.

Speaker B: Well, let's talk about that for a second. Earlier, you mentioned that, you know, we tend to want to have simple solutions for complex problems, but we also tend to simplify language in order to get understanding across.

Speaker A: Right.

Speaker B: And so things get lost in the translation or, uh, you're leaving out quite a bit when you're trying to achieve that. If you're trying to get your entire executive suite on the same page. And they may understand that it's complex, but they're not, like, fully understanding the level of Complexity. Right. So how does a CTO then balance that out with their CEO and all that, like, simple to what point? And complex enough to what point?

Speaker C: I think you bring up a very good point here because the way that complex adaptive systems deal with the increase of complexity, not just the rapid increases, any increase in complexity or scale, is to form boundaries.

Speaker B: You talk.

Speaker C: Yeah, yeah. So if you, if you, if your software is getting more complex and your business problems are going to, are getting more complex, then you have to have more boundaries inside of your team. Right. And, uh, effectively some of that complexity gets combined, confined inside of each one of those boundaries so that the overall complexity of the system decreases. So it's important to know what to communicate and when, what complexity to contain within the boundary of, um, your department, and what complexity to let out of your department. And that is hard and sometimes especially. And so Kathy Great wrote a great chapter on empathy. I think it's one of the best chapters in our book. Because in many cases, empathy is a solution. Because you're going to have to trust me. If you don't trust me, the cto, then you're going to want to come inside my department and you're going to want to look at, you're going to want to expose yourself to all that complexity inside my department, and you won't let me control what complexity that you get exposed to. You're going to run yourself crazy. You're going to fall apart. So if we don't trust each other

Speaker D: and

Speaker C: let each other limit the amount of information that we're sharing with each other and trust each other, that we're giving each other the right information at the right level of detail, then all the boundaries inside your company are going to devolve and you're just going to have one stew of complexity and you know what's going to happen? It's going to boil and flash to steam, and you're going to completely lose control over it. So trusting people about whatever cards they're hiding, about whatever complexity they're hiding from you is key. If you don't, then I guarantee your organization is going to blow.

Speaker A: And, and what I loved about what we discovered, or what I discovered, was that the overreaction to go from boiling to frozen, uh, if a boiling system, let's say, has very porous boundaries and there's just information flow and it's not there, there's no control. And then all of a sudden you come in with a more fascist approach. You don't actually go to liquid, you actually go straight back to frozen when nothing can get done. And you have sort of this authoritarian, oh, the CEO is stepping in and firing off the C suite and I, uh, take control of product. How often have you heard the CEO is now taking over product? You know, and that's going from a boiling system to a frozen system. Or maybe from a frozen to a boiling, uh, but you're not. This was why the title was so compelling for us. Because it's a state that you have to maintain with, with finesse, care.

Speaker C: Yeah. And that, that's why, that's why. See, the C CEO is a very important for this book.

Speaker D: Mhm.

Speaker C: Because the entire company has to be liquid. If we have liquidity and adaptability in the technology organization, but the other components of the organization are rigid, it doesn't matter. It just doesn't matter. So if you have a CEO that knows how to manage their department so that it stays in that liquid state, and the CEO is doing that for the rest of the company, then you're going to have a company that will react quickly to whatever the market does, whatever changes there are in the technical landscape to people leaving or coming or maybe you get a big influx of cash. Whatever the change, large change that you need to do for the company to survive and thrive, the whole company has to be liquid for it to do that. And as a cto, you can only. You have the most influence over your own department and keeping it liquid. But if your CEO does not include the rest of the company, it doesn't matter how good of a job you do.

Speaker D: We have this illusion, and I hear this often from like leadership, often from CEOs or sales or even technology. I don't love process. I don't want to put a process in place. Well, I think that's an illusion. There's always a process.

Speaker C: There's always some way, um, there's always a culture.

Speaker D: There always is something, a process of how things are done. That process could just be called chaos or boiling or frozen or whatever. You have a process. Is that process effective or not? And so when Scott talks about boundaries, I think of that as I'm um, going to put the appropriate process or operating model in place to make that boundary between certain parts of the organization or or even within our code. It could be like modularizing your code and creating strong boundaries between services. It's doing that with intention and finesse and making sure that it's not boiling or frozen. But that that process that is always there is not chaotic or frozen, but that is actually flowing and liquid and Effective, lean and effective. Not overbearing. But it is totally an illusion that there is no such thing as process. And I don't want to add process. Yes. You don't want to freeze yourself or you don't want to boil yourself. How do you stay lean and effective?

Speaker B: So, yeah, in the book you also talk, uh, about culture and what an important factor that plays into it. What do you tell. What do you want to tell CEOs and CTOs as they're reading through this book? What do you want to communicate to them for those who have been frozen for a very long time or those who have been boiling for a very long time and their culture is so stagnated with either or. Right. What would you want to tell them?

Speaker A: Judas book, what a great question.

Speaker D: We talked a lot about how culture is the hardest complexity to shift. And so I think of all those turnaround situations I've been in where the culture is just completely frozen, there's no trust. You know, everyone thinks everyone has an ulterior motive. And coming into that is like, it's a really hard shift. And I don't think certain types of complexity, I don't think you can shift them slowly. And culture is one of them. I think you have to. If you have a cultural problem, you need to say, this is what we're doing to fix it. This is the change we're making. Pattern interrupt. Do it now. Sometimes that's a, uh, leader getting fired is the change. And then that leader comes in and immediately puts a new operating system in place. And I think sometimes we need to be shocked to make the shift. If we try to, to do it slowly, the forces that play against us will just make it that slow process, even slower.

Speaker C: Yeah, that's absolutely right. What will actually happen if you try to do it slowly is that you'll expect a linear change in the behavior of your apartment. But what will happen is you'll creep up to that critical point. Once you hit the critical point, you'll get a sudden exponential change and you realize, well, there's no point for me to creep up to that point anyway. Yep. Right. Like, there are so many aspects to having a liquid department that it's not just like one rule or it's not just one sort of cultural value. They all. It's the sum. It's the summing up of those that gives you liquid behavior in your. In your department. But here are some things that if you have a really, really frozen engineering department, let's say, because that's what I'm most familiar with and you want to loosen it up a little bit or cause it to shift into a liquid phase. I would say that the, probably the best way to do that is take a certain amount of time of the. Of your engineers that you were trying to control and you let them control it. Because you know who, like there's no individual in your engineering department who has the answer to like what's going to make your whole organization change face. They have to do it together. Mhm. They have to all. They have to all change their behavior at the same time. So if you carve out like a part of that day that you are going to give to productivity, like you're going to set all the rules and you're going to structure the time how that engineer spends their time during that day towards business objectives and, and measurables and number of story points they close. You take that and you free that up. What you'll find is that they will use that time to accomplish those goals anyway, but they'll do it in a different way. Right. And then people will adopt that and then your organization will change. Right. You don't. As a person who's trying to influence any complex adaptive system, you don't do it by figuring out what changes you need to make inside. You always do it at the boundary of the complex adaptive system. You feed it a different signal and let it, let it respond and reorganize itself internally. M. And uh, what that feels like as an individual inside the department, as a subject of the system. Because we are all in one way or another subject to the system. What that feels like is it feels like freedom, it feels like autonomy. People love it. And then they will use their intelligence to. You can't outthink your engineering department. You can't sit outside the system and devise rules for each of the people in the system to follow such that it will adapt. Adaptation is something that a system does not an individual does. Right. So just give them a part of their day where they can decide what they do during that day and that will start the process of thawing out a frozen department.

Speaker A: Yeah. I actually want to ask you guys something because I was in a call. I've been coaching uh, a startup, probably about 10 million in annual revenues. And the uh, the initially reached out to me and I did his levels assessment with them and suffice to say they realized that the CTO was just doing way too many things and that the organization was suffering because of that. So they signed me up for some more coaching and Then I started coaching the C suite and after a couple months I realized that this system was boiling. Now what I find interesting, boiling does not necessarily mean frenetic, out of control. And actually I'm open to your feedback on this. We think of boiling because we see bring the pot to a rolling boil and it looks busy and crazy. And really the, the lack of boundary could be very subtle. You know, it's the uh, it's the quick walk from the one office to the other to quickly, you know, screw up a, uh, developing team's day, you know, because the CEO asks them to go do something without any respect for process. But that point aside, I realized that the system was boiling because the CEO wasn't CEOing. He was kind of hands off and he was like, rule by accommodation, consensus. You know, everybody is just doing what they can and 60 hour weeks was the norm because the C suite was doing it and everyone was doing too much.

Speaker B: Right.

Speaker A: So here's what I suggested on a coaching call was I suggested that the CEO step down. Now, I mean, I'm in insurance territory, right? Because I'm like, did I have my liability insurance in place? I actually checked my insurance before I suggested it. Uh, I was like, hey, the co. What if the COO steps in as the interim CEO and you guys get yourself out of this funk and let's get the system back to Liquid. And to Kathy's point earlier, that was a shock to the system. And honestly it was, uh, one of those ontological coach moments where you kind of have to reflect things back to your client and say the thing that no one wants to say on the call. But what that did was it did bring the shock to the system that everyone could look at each other and finally admit that, listen, guys, this is not, this company is boiling itself to death. And just because we are closing deals, earning revenues, doing customer implementations and burning the midnight oil does not mean that we are running a company that can sustain itself. And it's all trickling down to this levels assessment where the cto, almost every block is red because they just haven't been able to address anything because the CTO is too busy delivering on customer implementations and promises. And so now they are in a very, very serious introspective land and the CEO has come back and has had a wake up call. I mean, the story is still playing out. But I'm curious to hear Kathy, uh, and Scott, like, what are you hearing there as far as Liquid's concerned?

Speaker C: I think basically, yes, it depends on what that CEO was Doing, right? You know, there's a sort of an abstract concept of heat or entropy inside of a, inside of a system, right? And one source of entropy could be getting a lot of conflicting, conflicting direct direction from the CEO. If that was what he was doing. Maybe he was putting too much heat into the system and causing it to boil. But I will say that one important, maybe the most important part of, um, influencing complex adaptive systems to keep them in a liquid state is to see just to figure out where the heat or the cold is coming from. Right? If the heat is coming from the CEO, then maybe he needs to be replaced or to turn it down a little bit. Maybe the cold is coming from a middle manager who insists that everyone follow the rules exactly all the time. That can freeze your department. Maybe it's a cultural problem and your engineering department doesn't have the right mix of rule following and knowing when to break the rules. Right? So it could be cultural. So figuring out what's causing that system to be in the state that it's in and like knowing how close it is to a transition point or those are the key, those are the key things that you need to know in order to be able to influence that system.

Speaker B: System.

Speaker C: And, uh, what happened? Did they follow your advice? What happened?

Speaker A: Well, like I said, the story is still, uh, unfolding actually. The, the CEO, uh, is determined to wake up and like, put systems in place and like, you know, reign it in a little bit. But my fear is that it might be too late because of this hidden machine that has already established a culture of over capacity, you know, So I don't know.

Speaker D: One thing I see through your story is this concept. You said we started with the levels assessment, right? Because, uh, it sounds like maybe, you know, engineering wasn't delivering on time or wasn't delivering what the business needed. The CTO is doing too much. What I find is in any sort of company, there is a producer component of that system. So if you're a technology company with a technology product, technology is the producer. They produce the product and everyone else facilitates selling it, uh, marketing it, ah, servicing it. So if you're a services company, then your services team is the quote, producer of the value of the business. And what happens in these businesses is, you, uh, know, as they say, shit rolls downhill. And that team has always seen if they aren't, if they aren't delivering as the producer, they are seen as the problem. That is a very simplistic way of looking at your system. But yet if you back that out, and this is What Etienne did in the process of his coaching of all the executives, as he backed out of that, he went from symptom to root cause. Right. What is the root cause? What boundaries between all the sub components of this system? How are those boundaries operating? Is sales asking for so much custom work that the product can never get built? Is the CEO coming up with new ideas constantly and derailing what's in progress? Is product not, you know, are they a feature factory? And they aren't seeing how the system fully, uh, the workflow, the system fully operates? You know, where is the failure points between the boundaries of the organization within the system failing? And in this particular case, it sounds like the CEO just assumed all these leaders I'd hired knew their job and could own their boundaries themselves. No, that CEO needs to orchestrate, ensure that the boundaries between all parts of those subsystems are working in harmony, in alignment to the goal of the business, to their vision. You can't just assume and delegate away your responsibility as a CEO for orchestrating that, that capability.

Speaker A: What I want for this CEO, and I think maybe in a way this answers your question, I want for the CEO, uh, to feel like, you know what, what I need to bring my A game is not to shock the system from boiling and then risking going to this frozen state where all the executives are suddenly saying, what's going on now, now we're just this whole other company. I want the CEO, uh, to feel like, you know what, there's one or two tweaks that I need to make that establishes firm boundaries. The one or two tweaks is not code for B software. Be complicit, be gentle. It's establish not 10 boundaries or 50 newer SOPs. One firm boundary or two, and that the company can know, you know what, we're the boy. The temperature, like Kathy said, is just went down one notch. We're not trying to like, switch the temperature off because that can't happen overnight.

Speaker C: Yeah.

Speaker A: And I really think, I wonder what happens to the livelihood in a company, the empathy in the company, the trust in the company when a CEO can show up that way. Instead, we celebrate these turnaround CEOs who come in and lobotomize half the company and satisfies Wall street. And now everyone's happy because we're profitable again. At what cost? Like destroying people's lives. And so I wonder what happens when the CEO comes with a liquid mindset of, uh, where we are today is absolutely not where we should be. But my answer to this team is, here's one Boundary. We're start, we're starting today with one boundary. Do not. That boundary is, is hard. It's a hard one, but it's there and it's the only one. And then maybe a couple months later, let's add the next one. And I really think, and Scott really led us a lot through this thinking about what is, what does the boundary actually mean? How does that actually impact organizations? And that's what I, that's what I want this CEO, uh, to, to feel is like, hey, m. The I can do this.

Speaker C: Actually, I have a lot of empathy for CEOs for this reason. The deeper you go down the org chart, the less complexity you have to deal with. Right? So let's say that you are a programmer on an engineering team. The CEO has already figured out how to raise the capital to pay. Right. The people in the product organization have already figured out basically what you need to sell, what the characteristics of the customer are. And those are decisions that you don't have to make. Those are things that you don't have to figure out. You have to figure out how to make the code work. Right. And believe me, I, uh, do not want to minimize how hard it is to make the code work. I'm a programmer. It's extremely hard. Right. But so is everybody else's job is equally as complex. And you can think of the CEO as the person in the company who does not have any complexity filters in front of him. Right. She is exposed to all the complexity of the whole world. And so that is a very difficult job. And if you make the wrong choices on how you reduce that complexity, then that's going to ripple throughout your entire company. Maybe boil it, maybe freeze it. It's an incredibly difficult job. And a, uh, CEO needs the support of everyone on that executive team in order to do that job. Right.

Speaker D: If you think about it, each C Suite member lives within a system. They live inside the boundaries of, uh, their part of the organizational system. The CEO lives outside those boundaries.

Speaker C: That's right.

Speaker D: The CEO's job is to orchestrate the boundaries between each of the parts of the organization to work effectively. And then the rest of the C suite, we live inside of a boundary. And so it's like, I have a lot of empathy too. It's like really hard to orchestrate. You are the only person orchestrating a series of subsystems within your company.

Speaker C: Yeah, technology, absolutely.

Speaker D: I don't have to manage across all the different boundaries.

Speaker C: The way that would change that a little bit, Kathy, is to say that leaders, executives, they don't live within their boundary. The boundary of their apartment. They live on the boundary.

Speaker D: On the boundaries. Yeah.

Speaker C: They're on the edge of the boundary. Right. So a, uh, CTO is at the boundary of the engineering department and the rest of the company, but a CEO lives on the boundary of the company and the rest of the whole universe. Right.

Speaker D: Super hard.

Speaker C: Yeah.

Speaker B: And I think what I'm really taking away from this conversation is also this, like, it is a partnership, like this. This journey with Alice and Theo. There was a. There was a moment where Theo came to Alice, you know, talking about, maybe it's time to make a change. And there was that environment and culture that was created for that conversation to happen because he was positioned on the boundary and he could see what was happening. Like. And I think what's interesting about a CEO is that maybe we don't have enough empathy about. Is that they have to have eyes, uh, you know, in front of them and behind them.

Speaker C: That's right.

Speaker B: So it's like they're dealing with threats and risk, you know, all over the place. Right. And sometimes you all talk a little bit about signal to noise ratio in the book. Right. And really getting a sense of that. And we could go on. I mean, there's so much to this. To this subject that we could go on. Uh, I think Liquid is an incredibly amazing first step in that direction. Can wait for your next book, which probably is going to be named Plasma Shift or something. But, you know, if you. If you were to give Liquid a soundtrack, what three songs would be on it?

Speaker D: Um, that's an Etienne question.

Speaker A: I mean, I kind of feel like sergeant Pepper's Lonely Hearts Club.

Speaker D: What's the theme to Rocky? What's that?

Speaker B: Yeah. The Tiger.

Speaker D: Yeah. There you go.

Speaker C: Well, pick a track for every state your organization can be in. Right. So I would say that probably a frozen organization sounds like maybe a Philip Glass song. Minimalist and repetitive. Right. Not. Doesn't change much. I, um, think that you know, maybe. Maybe a organization in its fluid or flowing state or its liquid state maybe sounds like the girl from Ikonema. Bouncy.

Speaker B: Oh, interesting.

Speaker C: Comfortable. Right. And then chaos. I think 9 inch sounds like maybe any one of the. Maybe any one of the guitar solos from a, uh, Metallica song.

Speaker A: Yes. I think when you said that, I also thought of Roger Waters, who released an album called I think Chaos, Radio M. And these whole. The whole album, some of it's beautiful, but a lot of it is sort of this chaotic. Radio frequencies. Yeah, that's, um, An. That's such an interesting question. Thanks, Nishant.

Speaker B: Thank you.

Speaker D: This is a great conversation.

Speaker B: Thank you all for playing.

Speaker C: Yeah. Wonderful conversation. Thanks. Nishant was awesome.

Speaker A: Yeah. I think this is the first time the three of us had to talk about the book like this, so it was really lovely. So, Kathy, people can purchase the book on Amazon.

Speaker D: Amazon on August 19th.

Speaker A: And we have a little mailing list@ctocentinel.com liquid. Yeah, we have a LinkedIn page for CTO. CTO Sentinel is our imprint that we're going to use for several more books to come.

Speaker C: Scott, your books.

Speaker D: Scott, you want to hold that up?

Speaker C: Oh, yes, yes. I just got them. I just brought his physical copy, um, I've ever held in my hand.

Speaker A: Wow. Can I touch it? I mean, I haven't even. I haven't even got a copy. Wow.

Speaker C: Okay. Just give it a shot.

Speaker A: Wow. That's amazing. And then we invite people to try out levels. Go to ctolevels.com and go see what level your organization should be operating at. And we have an assessment tool where you can see where you're falling short. I think we've got more of that coming out in the near future, so sign up for our mailing lists. And, yeah, we hope to, uh, bring harmony to the tens of thousands of C suites out there that are changing lives. That's the show. Check out ctopod.com to stay connected. We love hearing from CTOS. We love hearing from CEOs. Anybody who needs to get their CTO plugged in, check out 7ctos.com. There are membership levels for everybody. So it's never too late to expand your network, nurture your relationships, and please, let's see each other soon, like next week. Cheers.