Episode 62: Gene Kim on the Evolution of Product Operating Models in the World of AI

Speaker A: Hello and welcome to the Mick One podcast where I sit down with industry leaders to dive into the project to product movement and future of connected work. I'm Mick Kerson, Chief Technology Officer of planview and the author of the best selling book Project to Product how to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. Today I'm very excited to be joined by Gene Kim for a third time on this podcast. Gene is one of my favorite people to talk to on the planet. He's a Wall Street Journal bestselling author, accomplished researcher and former cto. With multiple prestigious awards under his belt, Gene has written and published over six books. Uh, and last time I had Gene on the podcast we discussed his latest Wiring the winning organization co authored with Dr. Steven Spier. That book made a tremendous impression on me. I continue to use uh it regularly and you'll find that on episode 57 of the podcast if you're interested in digging into that more. But on this episode we're actually going to dive into Gene's upcoming book that he's written with Steve Yeage called Vibe Coding. I'm um, so excited for that one to get out there. I think it's going to be so impactful and we actually then get into a discussion about uh, more books, uh, about a book that I'm writing as a follow on to project product called Output to Outcome, which is all about implementing a product operating model for the age of AI. So highly related topics and without further ado, let's dive in. Gene, welcome. The third time on the podcast. It's so great to have you. It's been such an amazing journey over the years and uh, yeah, it's great to have you here and, and uh, to be talking books.

Speaker B: Yeah, totally. Mick. Uh, oh m. My gosh. What, yeah, what a grand adventure it's uh, been on. And I hear you're working on another book again which is flipping awesome.

Speaker A: I am m. I am m. Uh, and it's, it's, it's book two. It's a follow on Product. It's called Output to Outcome. And yeah, uh, I've been getting a lot of questions lately how applies in the age of AI and how things will be different, how this in the concepts change. It's been interesting to see how it still does apply. Certainly, uh, in my own journey scaling um, uh, our teams around AI, we've obviously used these concepts. But then I'll just start by saying my mind was pretty blown reading your new Vibe Coding book, right?

Speaker B: Oh my gosh. Yeah. In fact, change in the terms of like, you know, does it matter, uh, now in the age of AI? We were just talking before, it's like, yes, now more than ever, right? Um, uh, yeah, absolutely, yeah. Uh, in fact, I think you were going to ask me like, uh, how did that book come about and how did we end up, uh, hanging out with Steve Yegi? Can I tell a little bit about that?

Speaker A: Exactly, please. So, yeah. Well, first of all, Gene, so Vibe Coding new, uh, book, uh, from you and Steve Yegi and coming out late fall, you said?

Speaker B: Yeah, late summer, early fall. Totally, yeah. Uh, yeah. In fact, so you and I have talked a lot about Steve Yegi over the last decade. Uh, you know, he's uh, famous for his, uh, 20 years at Amazon and then Google, and he gave one of the best chronicling of the, uh, Jeff Bezos memo. The uh, thou shalt Communicate only through APIs. Um, and anyone who doesn't do this will be fired. That was actually a, uh, Google post that he meant to, uh, be private to his fellow Googlers and he accidentally posted it publicly and that landed him on the front page of the Wall Street Journal, which is edible for anyone

Speaker A: who hasn't read it. Definitely we should put that link to the materials.

Speaker B: Yeah, oh, absolutely, yeah, I'll post that link to you. Um, yeah, and so, uh, we met in June, uh, and he spoke at the Enterprise Technology Leadership Conference in uh, August. But something that happened shortly, uh, thereafter was that, uh, we had two hour pair programming session where uh, you know, the goal was to teach me, you know, what we now call vibe coding, which is, you know, our definition is it's any time where you're not writing the code, right, the AI is writing the code for you and you are supervising. And you know, more colloquially I would say vibe coding is anytime when you are not typing code in by hand. Right. So, uh, uh, and it changed my life. We, I uh, had certain goals going into that pair programming session. You know, I had all these transcripts, um, anytime I listen to a YouTube video or a podcast, when I hear something interesting, I take a screenshot. And so I've had, you know, 5,000 of these I've captured over the last 12, 13 years. And uh, the goal was, hey, can I take these transcripts in a YouTube video and create those video excerpts that sometimes you see on social media. And uh, we wrote one in uh, 47 minutes. It was just incredible. So it's like, you know, for some people, they could probably do it by hand in 47 minutes. But I Couldn't, I mean, that would be, you know, days, right? Uh, it was never a good week for it. And so uh, you can't have an experience like that and not have that change your life. That was a series of. One of several things that was equally transformative. And uh, so we decided to write the Vibe coding book together. And it's been the most fun thing I've ever worked on. Uh, in fact I just posted something uh, late last week where the goal was at the very last stage of the book at 2:00am you know, uh, the question was like, can only people like Steve Yegi, uh, who's written over a million lines of production code in his career, is it only people like him who can actually generate thousands of lines of code per day? And I'm like, well, um, let me check in terms of like in the last uh, 80 hours of the editing, um, process, I was actually writing something on the side, uh, so that I didn't have to do so much copy and pasting, you know. So like when you're writing a book, uh, you have to do a lot of things like you know, are there repetitive portfolio portions of the book or like, you know, rewrite the introduction and conclusions. And I was just doing so much copy and pasting from Google Docs into an LLM and uh, I was like, gosh, um, I'm just so tired of it. My hands hurt, my wrists hurt. And uh, so I took some code that I'd written in 2022 and uh, it uh, was a markdown parts. And I was like, could I like turn that into like a SQL like database where I could sort of make queries so I could like make the copy and pasting in a keystroke. And it turns out that when I counted lines of code in the repo, I had written uh, 4176 lines of code in three days while working like 16 plus hours, uh, on the manuscript. So I had done this on the side during coffee breaks while brushing my teeth. Uh, and if you count the documentation, it's 7,000 lines of code. It just shows that um, and so that's easily 16 times higher than my average, eight times higher than my peak day, uh, of productivity in the same repo years before. And so the notion is, uh, you can really unlock this 10x increase in productivity in co generation, uh, to solve important problems. And we call it fafo, uh, faster, you can be more ambitious, uh, you can do things alone or more autonomously. You can have more fun and uh, uh, and you can Create so much more option value or you can explore so much more of the decision space. Um, and so it's just uh, you know, I think it's uh. Who would want to write code by hand anymore? Yeah. Sorry Mick. So that's like just to motivate, uh, why we wrote the Vibe programming book. And it's just the most fun adventure I've ever been on. And you know, coding has never been more part of my daily uh, activities and I've never had so much fun as now. Mick. Sorry. Does any of that resonate with you?

Speaker A: Absolutely. You know, it's amazing. I think because it's such a. I had the pleasure of reading the manuscript and it is amazing to see how you and Steve have both realized that this 10x you've experienced uh, this 10x. Right. And maybe where we land in the 10x and how many people. Because I think one of the amazing things about the book is that will help everyone apply the patterns and anti patterns around Vibe coding. Right. Like you're not shy at all talking about the dragons and how 8 go up to repos and all those sorts of things. But maybe we can touch on some of those things. But I guess that's the core of what I think is so profound. Right. Which is that you have experienced what this order of magnitude feels like.

Speaker B: Yeah. In fact one of the people we cite very uh, heavily in the book is Ah, Dr. Eric Meyer. So language, uh, nerds like us, uh, we have just a tremendous. I think we put him in the top 10 computer program language designers uh, of all time. So he was uh, obviously part of Visual Basic, he was part of C, he was part of lingq, he was part of. He created the hack programming language at uh, Facebook to create static typing for PHP where they migrated millions of lines of code in less than a year. Uh, and ah, he had this amazing quote that he said uh, the days of uh, typing in code by hand are coming to an end. We may be the last generation of programmers to do that and let's have fun doing it. But that kind of rallying cry of uh, who would want to write code by hand? That's like a photographer going to a dark room and manually developing film. Uh, uh, still happens in some places. Uh, that's uh, what you do but for the vast majority of, I mean just dramatically change the cost of production when you can um, uh, be so much more productive. And so I'm uh, working with uh, the DORA team to help substantiate some of these claims about uh, Elevating developer productivity. But to go into my own repo and just be able to count 4,000 lines of code from uh, uh, 261 cloud code prompts and conversations. Right. And just be able to compare before and after. Uh, it was just, um, it was such a relief to be able to say we can substantiate it. You know, N is not, you know, is in single digits right now, um, in terms of being able to do this, but, you know, that's heading down to the thousands for sure. Right.

Speaker A: And so before. Because I definitely want to get into the implications of this. Right. And that's, that's what's so interesting to me. But before we get there, just tell us a little bit about, um, what you cover in Vibe coding and why, why people would pick this book up. I mean, I think. And before you answer, just to make it clear, after reading it, my, my, uh, uh, immediate reaction was every single person in my organization needs to read this book. Um, yeah.

Speaker B: That's awesome. Yeah, yeah. If there were like three, um, things that, um. Let me just go through the parts. Uh, part one is all about why would you want to Vibe code? Right. And so, you know, FAFO is a big part of that. Fun, uh, ambitious alone and autonomous. Uh, uh, faster and more optionality. The second is the dangers, uh, just getting an understanding of how these things work. Uh, and just because of context, uh, window saturation issues, uh, their ability to uh, really precisely follow instructions all the time like you'd want, uh, actually lead to tremendous potential danger. We share some stories where you uh, can quickly create, uh, haunted code bases that are impossible to understand, impossible to change. Um, uh, Steve, uh, he shared stories about how entire repos vanished or deleted. Uh, uh, he was actually sitting on the last copy of uh, a code base that he had spent thousands of, uh, cloud code tokens on. Um, and had he left that directory or closed that terminal window, it would have been gone. Uh, uh, deleted tests, disabled tests, all these things that you just really don't want to have happen. Just so people can go into this with their eyes wide open and then what you do about it. How do you have to modify your inner middle and outer developer loops? Uh, what are the new risks that you have to prevent, detect and correct? Uh, in some ways we're kind of overloading the inner outer loop, uh, terminology because it does change. It's not just compile, test, run, right? All these other things you do, in fact, uh, and now the coding agent is actually doing your compiling and testing and running at least some of it for you. Um, and then, um, part four is all about, um, what does Vibe coding mean for leaders? One of the things that really riveted me, I was listening to the, uh, interview of the cloud. No, it was the OpenAI, uh, Codex team. And they said, among the Codex coding agent team, productivity has taken off, um, except for the part that they had to put back into the ChatGPT monolith. And then productivity plunged. Because one of the things that you and I share, passionate for is architecture, is that when you are, uh, in a monolithic architecture, you, uh, lose all the independence of action that being separate, uh, gives you. Whether you decoupled architecturally, you just don't have to talk to it at all. And so the fact that, um, the OpenAI Codex team felt that all the superpowers were taken away once they had to integrate into the ChatGPT monolith, uh, which is apparently very, very, very large and had to scale very few properties. Maybe no other property on the planet has ever had to, uh. Well, suddenly they are now operating at tempo. You know, that is more typical with what any other non AI assisted team. So it just shows for leaders, right? If you want to take advantage of the productivity that these new technologies can generate, then there are certain conditions that have to be there, like fast feedback loops, like, um, modular architectures that decouple you and create independence of action. Um, and obviously you have to do things in a way that don't blow up the monolith. Um, Mick, I mean, I have to imagine, uh, when we talked about that, that clearly had to have resonated with your own experiences.

Speaker A: Yeah, no, absolutely. And I think the really interesting thing here is, and I think it's this 10x actually, I was just reminded, as you were saying it was that, uh, Enterprise Technology Leadership Summit in Amsterdam, we were first having this discussion, right? It looks like there's going to be a 10x increase in developer productivity. Um, and of course it could be that this is just the last generation that writes code by hand as well. Um, but. And then we of course need to then think about the roles that are needed when you're actually 10xing, and the fact that modular architecture could be more important, not less important than how these systems evolve. But I think what's so like you, I've been kind of a productivity geek forever, and especially a developer productivity geek. And it's just incredible to think that we're looking at this now, right, that two years ago it looked like it was real, and then I Think what you've outlined so clearly, um, in vibe coding with Steve, is that this is actually. You can get these benefits now. And here's how. And here are the things to watch out for. Here are the dragons. But this is real.

Speaker B: Yeah. And to your question, like, uh, in terms of what made me so excited when I found out that uh, you were ready to write the follow on to project to product, uh, output to outcomes is now more than ever, uh, especially in the age of AI, these things matter just a bunch. The reason why I shared the OpenAI story is that it just shows. Hey, if you um, want to. It's such a great demonstration that even an AI Frontier lab, right? These constants, these universal principles still matter. If you don't have an architecture that enables independence of action, uh, no matter what magical technology you throw at it, you are now constrained by the architectural constraints of the system. Um, and uh, so if you're decoupled, clearly the bottleneck moves somewhere else. I can't wait to hear your thoughts on that. But, um, number one. Yeah, yeah. So it's just, um. Can I mention one more thing in terms of like nerdy architectural nerd stuff? So we've talked to uh, many people who uh, taught us that, uh, we sometimes compare AI to electrification. There's actually a really interesting similarity is that uh, in a modern, like 100 years ago, it took about 20 years. Uh, actually probably 150 years ago, it took 20 years for factories and factory leaders to figure out, like, how does electricity really transform, um, and you know, allow productivity to take off. And the reason for that is that, um, before electricity, the primary mode of transmitting energy was, uh, the water wheel. And that meant drive shafts. And that meant that every work center had to be coupled to the drive shaft. You had to basically make sure that everything was proximate to the drive shaft because that's how you convey power. And so in comes electricity. Uh, and basically all they did was, you know, um, uh, uh, use electricity to turn the drive shaft. So you didn't actually change the factory floor until someone realized, oh, you don't need a drive shaft, you just need wires and the motors can go anywhere. And so suddenly you decouple all the work centers from the drive shafts, which allows for this explosion of productivity and ways of, uh, working that just didn't exist before. And so I think in the same way AI is doing for modern teams because it actually reduces significantly the cost of coordination. And so in the FAFO construct, uh, the uh, the second a. So faster, uh, um, Faster. The autonomous alone, um, signify it has a couple of interesting things. Dr. Daniel Rock, he was part of the OpenAI jobs report, um, that they did three years ago now. Um, and what they. He was telling us a story how they built a GitHub app. Uh, he learned about them on Tuesday in Google and they had one working on Thursday. So basically 48 hours later. And it was with a team of three people. And he called it like, he said it was like the Drift from Pacific Rim where. So uh, Pacific Rim is this movie about giant robots fighting monsters and you need two pilots for them to control, uh, the robot. And uh, they sort of mind meld through the Drift. And uh, basically to him it was him with the idea. He goes into Claude and says how do I write a specification to build one of these with my engineers? He then taps in uh, his chief of staff who comes from a design background and she starts modifying this uh, specification file and markdown. Then on day two they bring in uh, their lead engineer who uh, looks at it and starts talking about testability and uh, uh, how do you actually wire this into uh, their infrastructure? And so there's really kind of two taxes that this reduces. One is the uh, cost of coordination. The fact that they could just communicate through this markdown file and have a shared vision, shared goals, uh, have specifics to actually address the uh, problem. Uh, and it also reduces attacks of. I can't read your mind. The fact that the AI by intermediating uh, the interactions is dramatically making it easier for them to actually come to a shared goal faster. And so uh, to me that's very much uh, akin to what the electrification did in factories. Once we figured out how to decouple the teams from each other in the drive shaft, we're allowing teams to operate more independently, reduce the cost of coordination, um, and uh, allow uh, us to build with more fidelity the things that we're actually trying to build. Uh, Mick, how am I doing?

Speaker A: I think just so many interesting points there, Gene. Right? Because I think the there's. And this is why we're at such an interesting point in time, right, Is that I think we've got the electricity is there. Just how it's embedded in the way organizations work and deliver. Right? And it's exactly that story of moving away from steam and drive shafts and water wheels, um, into a completely new way of architecting a factory and the work ways of working in a factory. Right. And we didn't really get um, that mass productivity that came from the age of oil and mass production until that previous innovation of electricity was applied uh, to mass production. So I think, yeah, and I think it's really interesting how Vibe coding touches on some of those things like things related to modularity and then coordination costs and independence of action. Um, but yeah, I think this is, to me this is probably the most interesting challenge to solve right now, which is uh, given that we can expect 10 and maybe later more like significantly more, maybe 100x maybe full autonomy on delivering what has been one of the main constraints for organizations which is building software and digital experiences. Um, what happens, where does the constraint move to?

Speaker B: Well, it's pretty clear, right, is that if leaders don't uh, reshape the wiring of the organization, um, then they will get exactly the same productivity as they had before while everyone else kind of who can take advantage and reconfigure the organization to take advantage of these new modes of production, uh, they will get a lot better. They'll be able uh, to out compete those who don't. And so that's why I love that phrase now more than ever. All the things that you're talking about, both the project to product and uh, output to outcomes, uh, matter for leaders.

Speaker A: Yeah, exactly. I think we're seeing this already. I think this is a concerning trend which is some organizations are already well structured for this in terms of their leadership structures um, and the way that they have. Let's just take this, I think key concept which actually shows up and I would put the outcome quite a bit, it turns out of independence of action that comes from um, you're in Steve Spears acquiring the winning organization. Uh, if you don't have independence of action. Well are you really, if you don't have encapsulation and modularity, are you really going to be able to leverage those kinds of productivity gains in a way that's meaningful to the business? And I think this is a trend we've seen already with the DevOps movement. Right where in the state of DevOps report and the project to Product industry report, uh, we kept seeing this trend of elite organizations getting better. And I think we're now at the point this to dig into the organizations who are very good at uh, delivering value by scaling kind of yesterday's developer productivity which is hands on keyboards, uh, are just much better positioned to scale productivity in the age of AI.

Speaker B: Yeah, uh, I definitely agree with that. In fact in the Vibe coding book we quote uh, a bunch of people I admire. One of them is Fernando Coronago. So he's now global vice president of Uh, E commerce at ah, Adidas. And so we've studied him for years and you know he, he did a 750 person uh, gen AI pilot for developers and the same and incidentally. Right. He's also led the platform engineering group over the years and I think that gives him uh, and his group just this very unique set of experiences that make them perfectly suitable to kind of figure out like what do we do to use this other new dev tool. Right. To achieve dev and organizational goals. Uh, there's a person uh, who I met, his name is Bruno Passos. So he's group head of technology, uh, that owns developer experience@booking.com, so they have 3,000 developers, uh, they're one of the largest travel agencies on the planet. Uh and it's incredible. Uh, same thing. He again um, leads the dev productivity groups and again uh, uh, this is bent towards statistical analysis and really uh, improving developer productivity. He is at the forefront of some of the experiments uh, that uh, they are doing for Gen4 developers. And one of the findings is hey, uh, we need one of the best accelerators was two days of training because these things are so idiosyncratic, so unpredictable. Meaning AI, uh, is that um, you have to sort of uplevel everybody to make sure that there's a base level understanding because otherwise without that it's too easy to have them try something, have it not work and then have them write off AI is something that's practical. So uh, I guess it's my long way of saying it is no surprise to me that the people who are sort of changing ways of working who are focused on dev productivity, they are the ones uh, leading the charge for uh, gen AI and the scope of developers. Uh, that makes so much sense.

Speaker A: Yeah. And I think my sense is right now, I think the enterprise technology leadership community, the enterprise DevOps community the last 20 decades has provided a lot of evidence on the kind of practices that it takes to, to bring the organization to an elite organization. Now some, some companies have adopted those practices. A surprising number I think haven't been able to scale them as much as they would like internally. Right. Where they're adopted in pockets, but where we're still seeing really significant constraints upstream and downstream and across development teams so that if you 10x the productivity of those teams you're not, you know, you're getting two like 1.1x um, the outcome.

Speaker B: So that is so weird. It's uh, yeah, in fact I was having a, I had my second conversation with a director of dev Productivity at one of the uh, at one of the uh, uh, Frontier AI labs. And he literally said that, he's saying that, uh, you know, uh, obviously at these Frontier labs there are people who are really good at vibe coding, um, but there are, there are too many who are not adopting it and it's actually creating meetings. Um, and you know, their question is like, how do we elevate everyone's productivity so, so that it's not to reduce number of developers. Right. They're still hiring more developers than ever. The uh, question is like we need them to be more productive because they're in a race with all the other Frontier uh, labs. And so we met uh, uh, Jason Clinton, cisoanthropic. Uh, Right. And there's no question that uh, these people are all in a race, uh, uh, with each other, uh, with many entities that matter. Yeah. So, um, uh, isn't it interesting that uh, this person's title is the Director of Dev Productivity and he had a similar role at uh, one of the faangs before and he said it's just so similar what's happening, whether it's DevOps, uh, whether it's CICD. Uh. Right. It's the same sort of up leveling of developers that's very reminiscent of what happened a, uh, decade ago.

Speaker A: Well, and I believe the stakes will be even higher.

Speaker B: Right?

Speaker A: The stakes were high where in that last wave, uh, in the age of software in digital, we saw these organizations who got very good at technology, uh, basically grow to tremendous sizes and collectively become one of the world's largest economies. Um, somewhere between. Well, I guess that's still the third largest economy if you throw the tech giants together. Uh, but now I think the stakes will be even larger because the productivity, the amount of output you can produce is at least going to be 10x. And so organizations that can harness that are I think going to have an even bigger slice of the pie. And I think, uh, this has been the thing that's been for me the last couple years, this interesting question is how do we make more organizations participate in that? And the only way to do that I think is to actually understand why some of these organizations are very good at harnessing it. Like some of the organizations building frontier models or the tech giants, the hyperscalers. Uh, and then what needs to change in organizations that want to lean in beyond where they are today, which is some small portion of their development population is getting an expert.

Speaker B: Mick, why do you think that is?

Speaker A: Do I set myself up well there? Um, so, uh, yeah, I Think, I mean this is where I think the whole productivity thing is so interesting, right? Because if we look at any kind of product like work system, productivity system, the theory of constraint always tells us that there's some constraint. And this happened. You talked about one of the main constraints that was really limiting the whole technological systems around mass production, right? And that was the fact that to really scale work you needed to kind of decentralize that work away from a central drive shaft, um, and electricity enabled that. And we're now in the age of software. I think we've. The reason you've written, what is it now? Six books Gene, about this topic is around, um. Wait, sorry, is five coping six or seven?

Speaker B: I think it might be seven.

Speaker A: I think it is so published six books written seven, um, uh, around productivities. Because that's been the constraint, right. That's why I think some of these roles, uh, on delivering value to citizens, to customers, to markets, the constraint is how well can your technology teams innovate, work with the business, the organization and so on. So knowledge work of course in the age of software and digital has been how we do work. Uh, and the constraint has been that knowledge work. And the key part of that of course is development. Everything around development, um, and building value through software and digital assets. And so as I was looking at this, each of these technological revolutions that we have a engineering age of mass production, most recently since the invention of the microprocessor, the age of software and digital, uh, something happens where that constraint is loosened and production can be scaled. And so I think what's happened is we've had this knowledge work powered by, by very cheap compute in the age of software, digital the last few decades, uh, we're now at the point where we're actually building outputs, building knowledge outputs like software, um, that's going to become cheapened and highly scalable because cognition is powering this age of AI or age of super intelligence. And all of a sudden organizations that ah, put in place the right kind of production practices around this. Just like those organizations who were the first to electrify their assembly lines to create assembly lines through electrification, um, those organizations will be able to scale outputs basically indefinitely. Um, and of course there'll be constraints. And yes, AI and LLMs are basically uh, derived of electricity and other kind of compute limitations, but we're talking about 10x beyond productivity benefits. And again going back to the theory of constraints, then what becomes the constraint? I think what happens is teams and whether those teams are basically developers, uh, working directly, uh, and doing vibe coding, whether they're development teams mixed with agents, whether they're teams that are just agents, um, you're now going to be able to produce, let's just say 10x what you could before. And so the constraint's now going to move up the organization because if 10,000 agents need to ask permission 10,000 times of three different people, um, of course you're not going to be delivering at the pace that you deliver if they didn't have to ask permission, um, or if they didn't have to have some slower review processes or these other process constraints that we have in organizations. So I think the constraint moves up and the constraint actually becomes, which is why I think these teams around wiring the uh, winning organization are so key. But the constraints no longer the productivity of the team. And this is, the constraint is no longer building output through software. The constraint is now how do we deliver the most outcomes to our customers, our market, our citizens, uh, and how do we organize around outcomes in terms of, basically in terms of all of these structures? Right. We talked about the architectural structures of modularity, the structures of how people communicate, the structures of um, how outcomes are managed and how budgets flow through organizations. Because in the end I think the organizations that align all of those into an outcome oriented, a scalable outcome oriented structure that's able to leverage these 10x productivity gains, uh, will be moving at that 10x whereas the other ones will not.

Speaker B: I have two questions. One is I'm looking at uh, the updated Carlotta Perez Technical revolution technological revolutions graph and the chart. And it, it looks like uh, something that I have noticed over the years. Right. It was just never clear whether AI was part of the age of software and digital or does it represent something new. Right. And the question was, you know, is this, you know, was the age of software and digital, was that a gilded age or golden age? And uh, you know, was there one more squeeze left in the, in the lemon or whatever? How do we get to, you know, is this as good as it gets? I'm m dying to know. So it sounds like Dr. Carlotta Perez is actually saying age of AI is something new. I'd love to hear your thoughts on that.

Speaker A: This is this. I've been having this debate with her the better part of this year. And the good thing is she's writing another book on what it takes. These golden ages come. So and Carlotta makes this, this very clear distinction that between um, revolutionary technologies and technological revolutions. So she completely buys into the fact that generative AI is a revolution in technology. But technological revolutions actually take changes in sociopolitical and economic systems. So for example, to have a golden age. And this is one of the topics in her new book, which I think is fascinating, you need both, uh, elastic supply. So let's say we can actually the productivity of the economy, um, which is kind of where you and I get very interested. Um, then you've got a lot more supply of value that you can deliver through these knowledge, knowledge artifacts. Um, uh, but technological revolutions require elastic demand. So if all those factories that got electrified, uh, didn't have factory workers that could go then purchase those cars, then we wouldn't have had the age of oil and mass production rise as quickly as it did. So she studies a lot about the conditions needed for elastic demand. Are those going to come more from the global south? Like will chip fabs move south? And then there's going to be a lot more. Um, and of course you need trade and all sorts of other things that need to come together. So those are probably out of the scope of our podcast. But I think what's interesting to me is that we've got the makings of a technological revolution. So, so Carol and I debate when's it going to start? When will the age of software and digital have its golden age? And so on. But I think to me, the primary thing of her theory as well is that as soon as a constraint in production gets removed, which is exactly what generative AI is doing for coding and all sorts of technological and knowledge work, um, then you've got the makings of the revolutionary technology and the system of technologies. Because of course we need that to build on cloud and all these other things. They all build on each other, just like the management system of each age build on each other. Um, we then have the makings of this thing and then the questions for me is how do we make sure that it's not five or ten companies that participate in the spoils of this? It's actually as much of the global economy that can happen. And I think for that it really is around. We just need a new management model. So I think the way that organizations have been doing management in the age of software, digital, through agile, through product management, through these techniques that build on older techniques like project management and um, division of labor and so on, uh, now that outputs are going to be free or very cheap, M. We actually need a new discipline around outcome management.

Speaker B: Yeah. And by the way, uh, here's the way I feel about three reactions in that, uh, chart as we talk about industrial Revolution. Age of steam, railways. Age of steel and heavy engineering. Age of oil mass production. Age of software and digital.

Speaker A: Right.

Speaker B: What is the power, uh, thing. Water, steam, electricity, combustion, compute, cognition. It reminds me of, uh. So we were hanging out with Dr. Matt Bean, uh, who studied how automation changes surgery, uh, medical work, factory work, warehouse work, et cetera. Uh, he coined, uh, the term novice optional. The novice optional problem. You know, what happens like when say, surgery, which typically always required three hands, um, you know, that create a very natural pairing between senior doctors and junior doctors. Right. Because you, you know, the junior provides a third hand. But with the advent of, uh, surgical robots.

Speaker A: Uh.

Speaker B: Right. The senior can now do it themselves. And so often you have the junior surgeons having their, uh, you know, never getting enough time to become senior surgeons because, uh, you know, they take longer, they have higher accident rates and so forth. And so that's, you know, because. And that's a leadership problem. But, uh, yeah, he said something that just really, um, took me back. It startled me. He said like, uh, just like in the Soviet Union, the CIA would actually use. They, uh, would monitor electricity generation as a proxy for factory output. Yeah, right. In the same ways you can sort of measure how many tokens is an organization burning as a proxy for just how much cognitive, uh, just what are the equivalent for mechanical advantages. Right. That the electrical motor is giving you. How much cognitive advantage are you getting from, you know, AIs? I really find that like a super obvious construct, like, uh, you know, just measure how many tokens are they burning. The second thing that I.

Speaker A: That's fast. Uh, yeah, you could actually probably measure how advanced organizations adopting. In adopting AI right now by how many tokens they're burning.

Speaker B: Yeah, exactly.

Speaker A: Uh, it's a worry if you're not burning enough.

Speaker B: Right, exactly. Right, exactly. And then so that says a lot about like, you know, what are leaders doing to have people invite AI into their work. Uh, and I'll just say right now, uh, as part of writing this book, we burned 70 million tokens in part of the draft generation, critiquing, editing that process, the book, I think, um, it was done two and a half times faster than any other book I've done. Right. Um, and I'm so proud of it. It's like the best thing I've ever written. And uh. Yeah. And in fact, I want to put out a blog post that says, here's all the ways we used it. And um, I can't imagine writing a book entirely by hand anymore. So anyway, just let's put that out there. Um, the second thing is I was talking to Dr. Carlos Baldwin, uh, who you and I have shared ah, a tremendous amount of admiration for as she's the uh, premier authority on modularity. She was a student of Dr. Bob Merton, who won the Nobel Prize in Economics, uh, along with uh, uh, Scholes and Black, uh, for their option pricing theory. Um, and she said something wonderful when she was talking to Steve Yegi and Dr. Uh, Steven Spear and I. She said, uh, you don't do finance. Finance does you. In other words, she's saying that when you change the cost of production by 10x, that creates industry forces that rearrange the entire economy, uh, to accommodate that. So in some ways you don't have a choice. Uh, leadership either will get swept away by this or they will ride the wave to their advantage. And so, um, uh, I just thought Dr. Baldwin's way of phrasing that was just so powerful by saying that, you know, finance dictates the rules of how we participate in the economy. And then it's uh, um, part of it's a choice and part of it is not. Yeah, you don't get to opt out.

Speaker A: Right. And I think my big concern is that having studied the internals of many of these organizations and look at kind of the flow of value through their organizational structures, that most organizations are extremely poorly to leverage this. Right. Um, and I've noticed this very common thread, organizations that are well structured. Right. So we talk about modularity, right. And modularity is this use these principles of information hiding encapsulation. I think you relate those very well with um, uh, in wiring the winning organization. But most organizations don't have those kinds of structures. There are exceptions of course, right. Where you've got these very kind of clean organizational structures that line up to software architectures and let's say organizations like aws, well documented in the book, working backwards. But I think the interesting thing is that we've basically now got, here's my sense. We've got this very well understood concept of teams. Everyone knows how to make teams work, right. Vibe coding makes it clear how individuals of those teams can be 10x more productive. Right. Agentic, kind of. The evolution of agentic coding will make it possible for teams to collaborate with many more agents. And I think we'll end up with some teams that just are agents. And so the kind of metaphor I've had in my mind is that uh, we've got this kind of. If you think of the organization as a tree, um, it's probably the tree, the Teams are the leaves. The leaves can be attached anywhere in this tree. But if you don't have the right kind of scalable structure supporting the tree and getting those nutrients and also through the hierarchy.

Speaker B: Right.

Speaker A: Because every single natural system that scales is a hierarchy.

Speaker B: It's a modular system, it's a hierarchical set of modules. Absolutely.

Speaker A: Yep, exactly. Whether it's your capillaries and what's interesting in all these systems, or as we

Speaker B: Americans say, capillaries,

Speaker A: um, actually govern city growth as well. And I'll just quickly say, because I just can't get enough of reading and rereading this book, it was our mutual friend Ian Cockcroft introducing me to it years ago when I was growing my own organization. It's Jeffrey West's book Scale. Uh, yeah. So with this book, and smart organizations have applied this to their own organizational design is this is this hour law driven scaling, where you've got teams and teams of teams, but in the end what you're doing is supporting the productivity of those teams. Right. And back to the point of the capillaries or the leaves, those are kind of invariants. Right. The leaves in a tree are almost all the same in every single tree.

Speaker B: Right.

Speaker A: Capillaries are the same between a mouse and a whale. Like the aorta might be a foot wide in a whale and quite a bit smaller in a mouse. But in the end you've got this kind of scaled structure, um, supporting all those, you know, all those leaves, all those capillaries and so on. And then you've actually got, so that's a hierarchical structure. And then of course you've got structures that are able to connect across that hierarchy because we need that as well. Right. So if a tree notices that there's a drought, um, it will actually send signals, um, through abscisic acid to the leaves and the leaves will, um, actually stop evaporating as much water. Right. So similar to how market dynamics might change in your organization and, and you now need every single team to react accordingly. So what's been fascinating to me is that these very well designed organizations have these structures, these hierarchical structures, and mutually exclusive and collectively exhaustive hierarchical structures where every team maps into a value stream, those value streams map into higher value streams, you can call it some programs, um, and so on. But in the end you've got this very clear ownership structure entirely, basically entirely, um, uh, structured around delivering the teams, delivering outcome. And so this journey of the output outcome book has been studying is like, well, what is this for every single team, a team that has an outcome Loop. Right. You and Steve and writing by coding had this amazingly fast, faster than you've ever experienced outcome M loop and delivering, delivering value through this. It's the same thing for every team and has to scale up all the way up to the top of the organization. So what are those simple principles governing that outcome loop of taking inputs? Because we all have inputs, right? Um, we've got, there's a strategy, there's a budget, we all deliver outputs, so we're delivering activities and artifacts. But in the end what we need organizations structured around is optimizing for these outcomes. And so it's just been this fascinating study of uh, and to me it's been incredible how actually the principles that we know of modularity are what these elite organizations use in their organizational design and in their process design. And really how do we apply those? So we can scale to the levels of a coast redwood.

Speaker B: Right.

Speaker A: Coast redwood supports over 100 billion leaves. Um, so, uh, we're now going to be able to have tens of thousands of agents. What kind of organizational structure can actually manage that number of agents to deliver outcomes?

Speaker B: Yeah. I have like three reactions and this is why I'm so excited about your book. Because when you're done with it, everyone will say, it's obvious. Oh yeah, that's obvious. But until then, it's not quite as obvious to say exactly what those characteristics are. And I can think of no better person to actually enumerate, uh, what are those, uh, necessary and sufficient characteristics. And two, we see the absence of it everywhere. Right. In the wiring book we talked about, uh, what happens, what does it look like when a, uh, team doesn't have sufficient independence of action is that no one can do anything because no one has what they need when they need it, in the right format, at the right time, from the right people, etc. And it means everyone's stuck. Uh, and so it just says that there's something wrong with the wiring, uh, that is depriving teams of independence of action. And that's at 1x speed, right? For, uh, software teams, imagine when you can up the potential speed by 10x. Right? Uh, they are just as stuck as before. Uh, so that's observation number one. Uh, observation number two is, you know, just. I'll go back to that, um, OpenAI Codex team, right? It affects them as much as it does any other software team. Right before, you know, outside the ChatGPT model versus inside the Chat GPT monolith. And third is, uh. Oh, gosh, um, I told you about the conversation that Carlos Baldwin, Dr. Uh, Baldwin had with Steve Yegi, Dr. Steven Spear and myself about where we learned NK divided by T and Sigma. Yeah, can I please, can I just give a little punchline on that? So I had this. Oh, my gosh, it's probably ranks up there in the top 10 professional moments of my career where we got to basically be tutored by Dr. Carlos Baldwin. Um, on this topic of, like, my goal in the call was what does option value look like? How do you measure it? With a, you know, a, uh, stopwatch, uh, a yardstick, dollar signs. And. And the goal was, you know, um, let's go through Steve Spears experience in the Toyota production system. Where's option value being created? Let's go through Steve Yeggy's experience at Amazon as they went from one module to 10 to 100 to, you know, thousands, maybe tens of thousands of modules. Where's option value being created? And it was, it was kind of a tough sledding, you know, for a while because, you know, I'm just too stupid to. They're probably telling me the whole time. But everything became clear when she described this formula that literally changed the way I view the world. And this formula of N times K divided by T and sigma. So N is a number of modules in the system. Uh, so think Amazon when they were struggling to do tens of releases per year, right? It's because everything was coupled together. They had 3,000 people on one monolith. No one had independence of action, right? So N was one. Um, K is how many parallel experiments can you do in that system? Right? And there it was, uh, probably one. Everything interfered with everything else, right? Uh, you have to sort of, uh, uh, do it, you know, sequentially. T is how long does it take to perform an experiment? Um, so the duration, uh, how about a year to get something through the system? Let's call it maybe a half a year. And then sigma is what is the shape of the uncertainty risk reward. So when sigma is one, it, uh, means there's no uncertainty. You don't need modularity, you don't need experiments because you just pick the right answer and you'll always get be right. Sigma is super high when unconditional great uncertainty and conditions of high risk, high reward, uh, either or like now, no one knows what the payoff for AI is, right? But we suspect it's very high. But no one really knows. Um, and so think, uh, about what Vibe coding or think about what Amazon did. They went From n equals 1 to n to say, 1,000, uh, or 10,000 let's go 100. Let's go n to minus 100. How many parallel experiments can they do now? They can really ratchet that up. Um, uh, T went from say six months down to hours, maybe even minutes. Right? And, uh, you know, Sigma was high, right? It was highly competitive. Um, you know, it was before cloud computing, etc. So when in the context of the IBM system 360, the option value was created, she calculated around 25. So 25 modules. K was 1, t was small, whatever. But she said that was enough option value to blow the industry apart. Um, I, uh, think it must be orders of magnitude more for Amazon. Uh, but think about what Vibe coding does, right? Like N, right? We can't change. Maybe it can help you increase the number of modules and modularity, but it can certainly crank up T. K. You can do so many more experiments, you can crank down T. Right? The time to perform experiments is like 10x lower, right? And Sigma has never been higher. So I just think such a dazzling equation, right? Just think about as a leader, right, Just how your job is to increase modularity, increase the number of parallel experiments, decrease the number of time required to perform it, and you don't get to control Sigma. Right? But Sigma has probably never been higher anyway, sorry for the long winded answer, but like Mick, is that such a cool formula?

Speaker A: It is. And I think that this is the amazing thing with Amazon, right, is that they created a technical architecture to do that. Um, yes, and through APIs, through some of the things Steve Yeggi documented so well. But they also created the organizational and leadership architecture to do that. Right? So they were able to. Because in the end you need people executing those experiments, reporting their outcomes. And so in terms of their practices of doing this through six pagers and validating things and so on, those were as well as the organization, that single threaded ownership structure supporting this, um, those things were key because it allowed them to run and experiment and scale to that number of experiments. Right? And so to your point, with live coding now, we can scale experiments 10x. If you have the structure to do this, you'll never get there. And the thing that's amazing to me, and just going back to your first point, Gene, it's like, I think by the time you write, by the time I'm done writing this thing and I'm two thirds, not two thirds, like 40% of the, um, I really hope it's brain dead obvious, which was just so shocking to me, is how far organizations are from these things. So I think I'll just give you two quick examples, right? Which is, um, kind of cascaded ownership. So the way organizations manage ownership and let's say, do things, OKRs are one of the most common ways of doing that, including an enterprise. Now, um, there's kind of very clear approach to OKRs, uh, of actually creating this MU2 exclusive collective process tree where ownership cascades. You don't have one person, three different leaders owning one OKR and so on. Um, because possibly one of those is running a bunch of experiments. And in the end you need to know when the experiment's done, who's accountable for it and so on. Yet the way that we see these things happen, it's just this spaghetti mess that really ends up matching the organizational matrix. Right. I think, I think one of the important chapters in the book is matrix to modularity. The fact that organizations tend to keep just growing their wiring through saying need more collaboration, more innovation and so on. It's not completely counters to what we see working. And I think one of the big challenges of course, is that the way many organizations have brought in agile operating models is actually caused all these additional matrix line and all this additional spaghetti. So my hope is that the definition of the product operating model, project to product, stops short of defining the actual structural model of what a product operating model looks like, as well as these 10 simple shifts like going from matrix to modules, uh, going from objectives to ownership, um, where you've actually got people, leaders owning these things, whether it's agents delivering on them or teams of humans or, or a combination thereof. Right. But in the end, each of these shifts needs to come with a new way of working, a new model that again is out there. So the matrix to modules, that's just the independent action model. You need teams and teams of teams to act independently. Um, not to be right.

Speaker B: Communicate less, not more.

Speaker A: Communicate less, not more. Not be dependent on 10 things from other teams actually have independence of action, which then of course means they have independence of deployment, deployment of their tech stacks of all of that. And it's fascinating because these practices all there, but the organizations who don't have them in place at an organization level, they're just at the team level. I think they're getting nowhere near this 10x that's coming with vibe coding.

Speaker B: Yeah. Uh, and one of the, uh, fun things, so many fun things. Working with Steve Yegi, uh, who it was so fun having the three of us hang out on a call that was really, really fun to watch. Uh, but uh, you know, he shares these stories inside of Amazon. He was, I didn't know this, uh, until he told us. He was one of the first two pizza teams at Amazon, right, To reduce customer contact. And the goal was of autonomy, uh, and ability, right? Like it was a small team, cross functional, uh, where they had the authority to do whatever it takes across the organization, you know, to change any part of Amazon to reduce customer contact, whether it was, uh, billing, checkout, uh, inventory, fulfillment, etc. Uh, and, uh, you know, didn't mean direct authority. It was meant like, you got to do this, otherwise you're going to hear from Jeff. And one of the things that he said, one of the really funny things about Steve is that, uh, you know, he was, he lived in some ways, he's like the guy who's lived on the Galapagos Islands all his life. And now he. And now he's back on the mainland and he goes, have you heard of two pizza teams? It's like, oh, yeah. So all of us, trust me, all of us have heard of two pizza teams. But he said, you know, he said Jeff Bezos was so visionary, it's dawning on him that, uh, he was right about two pizza teams. And he thinks that vibe coding is going to enable more two pizza teams to really fulfill Jeff Bezos's vision of, like, true small teams with the abilities and the authorities to do whatever they need to do. Right, to your point. Right. Uh, what I find exciting about what you're saying is that, uh, we have the language for most of it. You know, we have the language already and some of the tactics, you know, to put into place once we know what the need is. So, like you, I care about this a lot. And yet I find myself with some equanimity, um, because I think the Darwinistic forces are going to be so large that it's going to force some action in a way that we didn't see, you know, um, for maybe in the last decade.

Speaker A: Yeah, I agree. And I. Oh, I can't.

Speaker B: One more thing. We were at an event in April, right, at the, uh, um, Enterprise Technology Leadership Forum, and Adrian Cockcroft again, he said something wonderful. He said,

Speaker A: uh,

Speaker B: in technology, we never had the board of directors inquiring about what the container strategy is or the Kubernetes strategy. But you have contrasted these days where every board of directors is like, what is your AI strategy? Uh, right. And he said it exposed him to the dynamic of the FOMO budget. Right? It's like if you're doing something AI related, there is a budget out there just by Looking under the couch cushions or whatever, they will find 5, 10, $15 million. Right. To make sure that they're not being left behind. Which is I think a dynamic uh, that we just didn't see uh, in technology leadership say 10 years ago. No.

Speaker A: And I think what I think I actually hope like vibe coding is one of the catalysts where there's just a ton more of that kind of experimentation and token burning that happens. Right? Because people realize, okay, it's not that hard, let's try it. It's not just around their top developers, it's actually let's give it to like, let's get everyone to do it. But then the, I think then I hope that to your point, we very quickly start addressing the challenge of the operating model of the organization not being suitable to leveraging the massive increases in outcomes. So just to give you back to you know, back to the team size thing. Right? Team. I think team size is so important and team, and then also team of team size because this is the branching factor of the organization. Right. How the top level outcome loop cascades into this tree of nested outcome loops is what your organization can deliver. It's how many experiments you can run in parallel, um, it's how many products you can bring to market. And of course the space of those feedback loops is critical. So uh, if your organization's structured, the first of these shifts is functions to flow. If you're functionally structured as ah, your top level hierarchy, you're never going to do that because you can never get the proper self containment. And to your point, maybe now we'll realize the 2 benefit. Well actually more M M organizations will realize the benefit of two pizza teams because those teams are constructed around outcomes, not around whether they're a data scientist or an engineer or a project manager or product manager. I think um, the evidence is all out there on what the structure of this team tree is. It's just that a lot of organizations are still functionally oriented, have project budgets, um, still fund initiatives, not capacity and so on. And none of that works.

Speaker B: Um, yeah, can I. Yes. Uh, and that I uh, just was listening to Steve Yeage, he was on the Changelog podcast and uh, he had this kind of provocative claim. Uh, so let's just start with the fafo, uh, faster, ambitious alone, autonomous, fun, optionality. So autonomous, uh, alone we call it, we used to call it alone. And then a lot of people had point out some like really some problems with that. Right. Uh, so we changed it autonomous but uh, you know, uh, very concretely. It means that like a developer can have more independence of action, but you don't have to coordinate with specialist teams like uh, the DBAs or like the uh, uh, Kubernetes specialist or the security specialists. It's not that we don't care. We don't have to get on the backlogs, coordinate, escalate, et cetera. Right. Because you can kind of get the expertise out of a box. Same with product management. Um, but it's also reciprocal. Right. Ux, uh, and product are often able to prototype the things themselves. Right. And give over high fidelity prototypes to uh, engineering. Um, because engineering is always busy. So there's a wonderful symmetry there. Right. And uh, yeah. So he takes it one step further. He said, imagine where developers now become sort of a gig economy inside of an enterprise.

Speaker A: Yeah.

Speaker B: Right. Is basically they are now like security consultants. Right. Uh, like how they, you know, security consults with um, you know, teams across enterprise. Yeah. Maybe developers are now helping vibe coders across the enterprise. Which is like pretty amazing to think about. Right. So, uh, and I'll just mention one more thing. It's like you know, 10 years ago, looking back, you know, I think dev and ops created infrastructure as code. Cloud created such a productivity advantage that it blew apart the infrastructure organization. It blew apart test. Right. Everything shifted left. I think we might see one more shifting left where dev shift left to uh, arm these teams that look very different from now, where it's not teams intaking work, it's actually teams intaking dev work and um, uh, a consultant developer coming in to help them get over the line. Just like we saw in the Daniel Rock example with the Drift. Anyway, just showing kind of like what is potentially possible. I just found that kind of a breathtaking, um, speculation.

Speaker A: Yeah. And actually the way I'd like to see it unfold is that, you know, we're going to see a lot more FAFO at the individual developer level, but we need FAFO at the team. And I think that gets very interesting, just FAFO at the team of teams level and then the team of, you know, the layer up. Right. Depending on the size of your organization, we need that same kind of autonomy to again to scale up. Um, and that that's exactly what we're seeing in organizations I think, that are able to leverage this. And of course, as you mentioned, the Codex team, you hit on barriers, but then you understand what the barriers are because the barriers in the end violate that kind of independence of action that you get to when you hit them on with or something of that sort. Right?

Speaker B: Yeah.

Speaker A: But yeah, I think these principles of what this operating model looks like, I think the evidence is there now. So, uh, it's been fun putting together the m. Absolutely founded.

Speaker B: I mean, I guess that's my main feeling is uh, right now is that what a time to be alive and what a great time to be in technology. It's not to say that there's not uncertainty because like, I think it's never been uncertain as now. Uh, but, uh, it's not boring. And I don't know, I just see so much potential coming within reach and it's just uh, so exciting to be a part of.

Speaker A: Yeah, no, and Gene, it's amazing to uh, see you kind of pushing it and hopefully uh, creating that same kind of uh, havoc that was created for test but Vibe Coin, but to bring down on the whole organization.

Speaker B: So hey, I have one last story for you in terms of like, you know, a little glimpse into the future. So we're doing the etls, um, uh, event in September again, huge AI focus. But one of the things I'm really excited about is uh, so we have Bruno Passos from booking.com will be there. I'm hoping, uh, Fernando Kronago will be able to continue talking about. But there's some really interesting case studies that I'm just so excited about. Like one guy, his name is Stuart Pierce. No, no, uh, Tim Howard. He's director of Cross Cutting Technology Services at UK defra. So that's the UK government agency in charge of air, water and food. So like the US would be the Food and Drug Administration or the Department of Agriculture. But he said um, for any government service to be digitalized it would be like $35 million. And so, um, there's a whole bunch of services that will never rise to that level. But he said we Vibe coded something in a week, um, and suddenly everything. Ah, like now to apply for a license to walk your pet pig or to open up a racetrack that becomes within reach. And uh, so the constraint is not development anymore, it's now. How do you train a whole bunch of government clerks who've never used PDF files or whatever to actually not process paper documents, but instead, uh, use a, uh, new app to do that for you. Uh, imagine how much we can benefit society. Uh, these are real world case studies that uh, give us a glimpse of what's coming.

Speaker A: Yeah, no, I can't wait to hear that one as well in the fall. Excellent. Well Jean, thank you so much again. Everyone who hopefully people can get their hands on your book. Late summer, early fall, soon.

Speaker B: Oh, you can pre order now on Amazon, which is. Ah, great. And uh, I'm so delighted that you'll also be sharing your work on, uh, uh, output to Outcomes also at the conference. And so. Yeah, man, what a, what a time to be alive.

Speaker A: Exactly. Very much looking forward to it. All right, thanks so much, Gene.

Speaker B: Thank you so much, Mick, and keep up the amazing work.

Speaker A: A huge thank you to Gene for joining me on this episode. For more, follow me in my journey on LinkedIn or using the hashtag Mick+1 or project to product, you can reach out to gene via LinkedIn. You can also search for Project to product to get the book. Thanks. Stay safe. And until next time.