The AI Productivity Paradox: Why 10X Output Doesn't Mean 10X Business Outcome

Speaker A: If you make your decision on cutting your software developers based on an output productivity gain, not an outcome gain, you could actually end up with reducing customer retention by 50%. Today's guest is Nick Kirsten, creator of the Flow framework and bestselling author of Project to Product. In his new book Output to Outcome, he redefines the operating model leaders need to thrive in the AI era.

Speaker B: Some people said they have tried to apply AI, but their productivity doesn't seem to increase by a lot.

Speaker A: What AI does is it actually automates cognition and the output of knowledge artifacts like software. It's going to be 10x easier to deliver those outputs. And so now that that's not a constraint, what is the new constraint? Are you able to get customer feedback at 2x the rate? Are you able to plan at uh, 2x the rate? Are you able to evolve your strategy at 2x the rate? But our organizations are not ready because they were really designed for scarcity of outputs, not abundance of output.

Speaker B: Some organizations actually opt for layoffs because they think software development is kind of like solved problem.

Speaker A: The traditional ways of coding they already does. It no longer makes sense to not leverage agents in your day to day work. As a developer, your productivity does go through the roof. You're now able to do so much more that you now need to bring in aspects that are outside of development tradition, like product management. You need to interact with stakeholders, get feedback from users more quickly. What is saying is we both need to understand what's the new constraint and then to create a new management model. We're managing that constraint just because of the way complexity works and AI agents are going to increase the complexity, not decrease it. We actually will need these layers of management and just a very different kind of management.

Speaker B: Hey, quick pause. My goal with Tech Lead Journal is simple. Learn from the best in tech so we can all grow together. If this resonates with you, hit subscribe to follow the channel. It's the biggest way for you to support the show and help us keep bringing great guests and insights to you. Thanks for being here and let's get back to it. Hello everyone. Welcome back to another new episode of the Tech Lead Journal podcast. I'm very excited to have Mick Kirsten with me today. Uh, another IT Revolution author. He's actually coming up with a new book titled Output to Outcome. Um, but previously actually Mick, uh, is well known uh, for writing this book titled Project to Product. I'm sure if you are maybe working in a startup or product management, you might have heard about this. You know don't do project, do product instead. So I think really excited to learn from Mick about his new book and also this project to Product, uh, operating model. So Mick, welcome to the show.

Speaker A: Thank you Henry. Great to be here.

Speaker B: Right, Mick, maybe let's start uh, with the question why did you come up with this new book? Is it something like a continuation from the previous book? Maybe tell us a little bit more about it.

Speaker A: Yeah, it started as a bit of a continuation. Right. There were some things in Project to Product that I wish I'd basically uh, uh, developed a little bit further. For example, how to work with platforms. Right. You start with building products and product value streams and then uh, you need to understand how platforms fit into this, how different life cycles of products, more transformational products fit into this. And really all of. But what happened of course is that all of us were involved closely in technology and building products. We're all starting to increasingly build them with AI. Right. So really since, and for many people that started towards the end of 2022 when some demo happened and of course this whole thing took a life of its own. I was working on uh, an Agentix solutions for two and a half years before I started writing the book and I realized, okay, we not only need to or really what I realized people were asking for and needing was not just more guidance and more specific guidance on a product operating model, but really how all of this changes in the age of AI and how development changes. And of course all of this was moving and evolving quickly. But more so than it being a continuation of Project to Product, I really wanted to be an AI centric operating model that encapsulated everything I'd learned to, to date building software and uh, building companies and technology organizations, but really entirely based on being an AI native. So the book actually stands alone from Project to Product. It refers back to it here and there. But I actually do things. And of course I think it's good if people read both books, but if you're only going to read one now, I think output outcomes, uh, separately while building on some of the principles of Project to Product.

Speaker B: Thanks for sharing the reason of your book. So definitely the AI thing definitely is one crazy thing that is happening. Uh, it can, I think it can be said it turns upside down the whole software development life cycle, you know, product management and even the company operating model. Right. So I think by reading your book, you know, in my preparation before this conversation, I think it's definitely very, very appropriate uh, to have such guidance, uh, for organizational transformation to succeed in The AI era. So maybe one trivia question before we go, uh, dive deep into the book. You mentioned in your book that you actually don't use AI at all in writing this book. Tell us the reason why, because I'm sure many people nowadays would have used AI to, I don't know, improve their writing, you know, getting polished or, uh, whatever. Right. So tell us the reason why you, uh, opted not to use AI.

Speaker A: Yeah, it was an interesting decision at the start and obviously I use AI very heavily, uh, for researching the book. Um, over the course of that years on the top, I noticed from that annual report of being in the top two, uh, percent of ChatGPT users because of how heavily I was using deep research and everything else. Uh, but I did decide early on to write every word in the book myself and not to use AI for that. And of course I do this for other formats, but, uh, not use AI for any revision cycles and just have it written, uh, in my voice. And it was largely because it was a personal thing in the sense that I think and evolve my ideas through writing. Uh, so that was a big part of it. And it's a bit like pair programming for me, right? If you're pair programming, it's really fun for certain things. But when I spent a lot of time coding, I actually preferred hand coding really big solutions or really complex parts of a framework. And I found the same thing with the writing is that the writing itself, the creative process worked better for me and I had the time to do it as well. I decided to dedicate the time to do it, um, so I was not rushing. I want to slow down and really think deeply about these ideas. And writing on myself helped me think deeply about it. So that I think that really helped. The other thing I was noticing as well is because there are quite a few new concepts in the book and I was trying to get all new concepts in the book. I think that will help us kind of expand, um, our understanding of these things. Uh, for a lot of the conceptual writing, neither Claude nor ChatGPT models that was always used on the latest and the top subscriptions, they would confuse the concepts more than usual, more than I use other things for, because there are a bunch of new things in there. So of course it's not that you can get interesting insights from them. Um, but I really was using it more for research and for discussing ideas I discuss with someone else and so on, but not for any of the outlining or structure of the book. I also wanted it to be a unique contribution because there is this thing that's going on where a lot of the things I'm reading, they're just all sounding so similar as well. Because there is kind of a similarity in voice similarity in idea generations that is coming from the models, uh, as well. And I did want to make sure that it was unique as well. So yeah, AI was used very heavily, but in none of the writing or outlining or those kinds of revisions and things.

Speaker B: Yeah, very interesting. Uh, definitely, uh, for people who are doing creative uh, work, maybe content creation, whatever that is, uh, do take this approach as well sometimes because the creative writing process itself I think can also help you coming up with unique ideas and novel things. Right. So one other thing that I noticed in your book, uh, this is also another unique thing. For almost every chapter I see prompts included, uh, inside. Right. So tell us, how can we use these prompts? Because I think sometimes, uh, some of the topics in the book are kind of like abstract, really high level thinking. How are we supposed to use these prompts to actually help us applying your output to outcome.

Speaker A: Yeah, and interestingly that is the one part of the book, and I of course mentioned all of this in the book where I did actually use AI to iterate on the content. So the prompt, every chapter ends with a prompt on how the prompt's obviously meant to be fed to a model or an agent to help apply the concepts of the book. Uh, and so to highlight some of the key concepts and how you can use them for really decision making around that. For example, this chapter on the outcome loop really how to approach, ah, helping the implementation of an outcome loop within an organization. So it's really meant. Because of course people are going to be using agents with how they do these kinds of changes and evolutions of their organizational operating model. And it's really meant to distill for the agents the key parts. Whereas the, and of course the narrative of the book is really meant for humans to absorb the ideas and the prompts really for the agents to highlight the most important aspects of the ideas and also to really double down on what's the role of agents or humans is. So for example, one of the concepts in the book, um, is that where the book talks about uh, organizational design and structure, we can dig into this or not, but humans should always report to humans. And so it took me a really long time to come to that conclusion, um, uh, and look at various alternatives. But so the prompt for that chapter says that in any organizational structure, do not propose structures where humans report to agents. And so that's kind of a specific instruction to. So that's the other thing about those prompts is there are instructions to models and agents on how to act on the book which are slightly different than the instructions to humans.

Speaker B: Right. So I guess it comes back also, like, maybe like what you said. Right. Uh, using it as a thinking partner. Right. Uh, putting specific guardrails, guidelines that you introduce. Right. Uh, from the concepts. Uh, and hopefully it can help humans to make better outcome and decisions, I guess.

Speaker A: Yeah, exactly. And it is guided for the model rather than for the person.

Speaker B: Right.

Speaker A: Because in applying these concepts, I think the models and agents will have different roles than the humans will. I think we're starting to better understand those roles. And yeah, one day it just dawned on me, like, why on earth would I not put that directly in the book?

Speaker B: So.

Speaker A: And it's kind of. I actually find it. I found it interesting both writing those, uh, prompts because it does help you think through what the role of human leaders is and what the role of agentic leadership is.

Speaker B: Right. Yeah. This is my actually second time knowing an author coming up with prompts. Previous one is, I think Vlad Kononov. I think he wrote this book about coupling, Balancing, coupling and all that. And yeah, lately he come up with all these prompts to actually help developers, uh, I guess, uh, to understand the coupling level within, uh, the code base.

Speaker A: Oh, neat.

Speaker B: Very interesting. Yeah.

Speaker A: Yeah. Because I hadn't come across it. Yeah, I'd never come across it. You're now making me realize I don't know how they're going to record it for the audiobook. I guess they should read it with a robot voice or something because the audiobook recording is underway right now. I should check on that.

Speaker B: Yeah, yeah. Interesting. So let's go into the topic of the book. Right. So I think, uh, we all know this, um, AI thing is happening at the moment, right. It's getting crazier and hot. You know, everyone seems to be, I don't. Feeling anxious, scared about, um, you know, how the world's going to be disrupted. Why do you think now this book is very timely for this. Right. Maybe give us a little bit of background. How does it suit really, really well in this era.

Speaker A: Yeah, absolutely. So I think, you know, and it's, of course, everyone is having various kinds of challenges and pressure and urgency and how to navigate this era. Right. This is, this is. It's that it's, I think, fair to say it's very difficult to navigate this area because there's so much change and so many unknowns. Uh, which also then makes it kind of difficult to write a book about it as well.

Speaker B: Right.

Speaker A: Because things are evolving. Um, but I think the book starts off with a, with a very clear assumption and premise which is that building and this was clear, you know, obviously like this is two years ago, was laying some of these foundations. I started writing it in January, um, 2025. Uh, but that if we extrapolate things some, you know, it's going to get 2x, 3x easier to generate outputs to write code, to create technology, artifacts, all those sorts of things. Uh, and then of course the book needs to be longer lived than that. So who knows how long that 2x and 3x timeframe is. And when I started the book we hadn't even seen uh, things like Claude code yet really materialize and more of. I was already working on some of the Agentix stuff, um, uh, in my role then as CTO at planview, but we'd not yet seen that full potential. So for the book I just made this assumption and it's of course a very quick coarse assumption that it's going to get 10 to 100, maybe more, maybe 1,000 times easier to produce output. So the book just is built on that premise. Let's assume that especially for coding, but for other domains of knowledge work and for coding it turns out to be easier than many domains of knowledge work. Um, which is why it's obviously a good place to start, um, that things get order of magnitude, it gets order of magnitude easier to create outputs. Uh, and of course some of this will take years. We're not there yet. Um, but no matter what it's happening, I think we're on that path. And if you buy into that premise, then how does your organization operate and need to adapt in order to be able to leverage that? Because of course many organizations are entirely structured. Their whole management model, um, is all around managing a scarcity of output. So managing it. Everyone's been hiring developers and investing in developer productivity, which of course was near and dear to me for most of my career. Um, but all of that is being flipped on its head. So what are the new roles? How do we actually adapt to the fact that the cost of building outputs is going to trend lower and lower, eventually to zero and year zero or the cost of electricity. Um, but our organizations are not ready because they were really designed for, ah, scarcity of outputs, not abundance of outputs.

Speaker B: Yeah, and interestingly you use past history to actually kind of like explain this because, uh, when I read that part of the book. Right. Uh, it actually dawns on me. Okay, this is actually a very good, uh, kind of like summary, a trend, a pattern. Right. Uh, from the past history. Uh, maybe elaborate a little bit. What's the like the pattern that you see from every major technological advancement that happened in our human history and why now is actually quite similar as well. Right.

Speaker A: Yeah. So I think I anchor the book because of course when we're living through this tremendous change right now, it feels like nothing like this has happened before. Nothing exactly like this has ever happened before. Um, but of course I think it's, it's useful to look to similar things of the sort that, that have happened uh, in history. And so we obviously know that electricity was a pretty big deal when it happened. Right. Um, the ability that mass production were a pretty big deal when that happened. So I lean on the really the model and framework developed by someone who's actually been a very helpful mentor to me initially for writing project, um, to product and more recently output to outcome. And Dr. Claudia Perez, who wrote the book Technological Revolutions in Financial Capital. And so she's created these models of these last five technological revolutions. The, the most recent ones being oil and mass production, then the age of software, um, and digital and really anchor how things had to change in those revolutions. Because. And this was the most interesting thing that dawned on me in having worked with our concepts is looking at each of those revolutions. This really was the genesis of the core concepts of output to outcome is looking at that through the lens of the theory of constraints. Because the interesting thing around. And she talks about the sum that each of those revolutions became the revolution technology eased some kind of constraint.

Speaker B: Right.

Speaker A: You had, um, obviously when we were automating human labor, uh, being able to power things with steam automated that constraint on how much humans could do with their muscles and such. So each of those revolutions and of course you're leading to. I kind of develop this in output to Outcome, uh, remove that constraint and electricity did a similar thing and then again mass scaling, mass production did a similar thing and then software did a thing. But each of those revolutions introduced a new or resulted in a new constraint. Right. So when we had the age of software, the constraint was producing knowledge, um, through artifacts like software and tangible assets like software. Which is why software developers were so core to all this because you were really limited by how much software output you could create as a tech company, hyperscaler, uh, whatever you were doing in that last period, that last technological revolution. Now of course what's happened with AI Ah, is that, and this is the case with each of these revolutions. That constraint of building software is no longer a constraint because what AI does is it actually automates cognition and the output of knowledge artifacts like software. Um, and so now that that's not a constraint, and this is really the question that output Evelyn asks at the start, what is the new constraint? And each of these revolutions has brought with it a new managerial model. Um, we got things like, um, scientific management or Taylorism, and we got things like tools like Gantt charts over these revolutions, um, which have become project management. Then we got product management. Before that we got lean, uh, and so on. And I think what M comes saying is we both need to understand what's the new constraint and then to create a new management model for managing that constraint. So that's where I think the way that the, uh, organizations navigate previous revolutions is relevant to this one, from this kind of first principles level.

Speaker B: Yeah, I like the way you bring up this theory of constraint and also, um, seeing the like, for example, the output constraint of producing something gets kind of like lax now, right? Almost uh, zero at the moment. I think for writing software you can easily churn out that stuff and hence, uh, by having that effect. Right. You will need a new management approach to actually deal with a new constraint somewhere. Right. So speaking about the cost of producing software, I think many people, software developers who are listeners, uh, in this podcast, are feeling anxious. And I think in your book you also mentioned Rod Johnson's quote that software developer as a profession is kind of like gone. Uh, is it true that it will be gone? Or how do you actually see the software industry because you yourself is a software developer as well.

Speaker A: Right.

Speaker B: So tell us your view on this.

Speaker A: Yeah, and so I think a lot of us are trying to answer this question. The book starts with that as a kind of provocative statement because when Rod and I, we were just on a call, this was back In, I guess January 2023, where we were all seeing, you know, before that you were really just accessing chatgpt APIs. Um, and then you started seeing how good it was at um, this language, the languages we were used to speaking, like Java and Python. Right. Not just English. Everyone else was seeing, lots of people were seeing how good there's English and French and all sorts of other languages. Um, and so I think what's happening is that the traditional ways of coding, they are done, right? It no longer makes sense to not leverage, um, agents and cloud code and codecs in your day to day work as a developer. Because so much of what we were all doing by hand is just now so easy to automate and so it can be very, I think the cognitive load increases a lot with working all of these agents and there's lots of, I think literature and experiences uh, out there that are about that. But fundamentally your productivity does go through the roof. Um, and you end up with new things that are difficult. A whole bunch of things are easy, obviously using existing applications, adding basically agentic development to existing applications and now properly modularized things get interesting, you have to rewrite things. And so I think there are all sorts of new challenges. Um, but yeah, my view on this is that the role of the developers needs to change fundamentally because of course now it's just a very lower level cranking out code. This is something I used to, a form of output that I used to love very much, um, is now more of a hobby thing. It's like more like back to like building Legos, which I still like to do. Um, and um, you're now able to do so much more that you're actually, you now need to bring in aspects that are outside of development tradition, like product management. Right. You actually need to think about the product because you can do so much more. You need to interact with stakeholders, get feedback from users more quickly and so on. And so I think the role of the developer changes fundamentally. I can't answer whether we're going to have more or less developers. One way of looking at it is that everyone, all sorts of new people will become the developers that weren't. So we're going to have 100 million developers in a year or whether there's going to be so much more software written that actually managing all of those services in a way that's uh, as we add more still challenging to some of the current models and harnesses out there will mean we'll need more developers to manage all of that software. So I think it's really hard for me and to say exactly what's going to happen to the profession, but I think the last chapter of the book, um, is managers to makers or I kind of joke, or is it makers to managers? Right. These roles are going to blend. You're not going to be just a pure software developer, pure full stack developer, a pure infrastructure developer or those sorts of things. Um, you're now going to be managing agents and working within a larger structure to deliver value. Um, because again the traditional development role is, I think it's uh, we're past that now.

Speaker B: Yeah, very interesting take. I'm sure. Everyone agrees that uh, the job will evolve, right? Our role will evolve. Uh, maybe it becomes more, I don't know, more full stack, more generalist, uh, going into the adjacent area, some people say, right, maybe like product management, design, whatever that is. So I think that. Thanks for sharing your view. Um, in some organizations actually, uh, when I read some research or maybe surveys, literature out there, some people said, uh, they have tried to apply AI, but their productivity doesn't seem to increase by a lot. Maybe some even quoted 20, 30% only while some other organizations is, I don't know, like 2x, 3x 10x. Right, whatever that is. And you put in your book this is like an AI productivity of like paradox. Uh, so tell us the reason why. Uh, and maybe this is something that is also a good segue to talk about the outcome thing that you propose in the book.

Speaker A: So I think there's the kind of two aspects to this productivity issue. Let's just say uh, that we're somewhere, but organizations are somewhere between like you know, 20% and 20x productivity gains, right? Depending on the nature of the applications, the nature of the business and the market and so on. Um, so I think part of this has to do with kind of the edginess and capabilities of the models, right? They work better for some domains, some languages and so on. They work better for more greenfield stuff than um, large legacy applications and so on. So I do think that the productivity gains of the models themselves, creating an authoring the software, we're still on that journey and that will just grow, right? And it's going to grow fairly quickly given the rate of growth you've seen, maybe level off, maybe accelerate. But um, I think it'll just get better. So I think what's happening, um, so I want to kind of extract this from um, that individual productivity journey because some people working for some domains, they're just not going to see 2x in the next year. And I think that's okay. I think we are on that journey. Some people are going to see significant gains in the code produced, but they'll have the usual code review bottlenecks. They'll have the usual challenges with getting distracted by agents or just getting demotivated for how much effort is to manage these agents. Whereas coding was kind of simpler and had less cognitive load in many, many respects. So I think we're all on that journey of learning how to get to let's say a 2x or a 10x for ourselves and for our teams. But I think separate from that, the AI productivity paradox is deeper, which is um, in order to get to even to 2 or 10x gains, um, for an entire organization is actually much, much harder because you can't just produce more of the same thing you're now able to produce. Let's say you're able to produce 2x. Are you able to get customer feedback at 2x the rate? Are you able to plan, uh, at 2x the rate? Are you able to evolve your strategy at 2x the rate and then at 10x and then at 50x and so on. And so I think the productivity paradox of actually getting proper yield from the coding and models, um, I think that's just going to get easier and easier. The harnesses will get better for the places where you need more harness and so on and the models of course will just continue getting better. Um, and then I think as soon as you're getting to those two x numbers, then you're hitting up against the organizational constraints where the way that you plan, the way you collaborate, the way that you fund initiatives, the way that you innovate and the way that organizations are structured, uh, needs to change in order to actually get benefits. Uh, not in terms of just 2x the output, but in terms of 2x the customer, the business outcome.

Speaker B: Yeah, I think it comes back to this theory of constraint, right. Where now one parts of the organization, which is a software development team, can produce more output, more productive. I think. What about the other parts of organization? Right. I think it's also analyzing your value stream and seeing where the new constraint, new bottlenecks is happening and if they are not equal. Right. I think it's also uh, not going to be producing the optimal outcome. I think this has happened before with agile transformation, digital transformation. Right. We always kind of like focus a lot on software developers, but actually the other parts of organizations probably a little bit of uh, waterfall silo and all that. So um, let's go into your approach which is called the outcome management. Right. First of all I want to clarify what do you mean by outcome? Because this term uh, is being used in many places. Right. I just want to level set the understanding for listeners. What is your interpretation of outcome?

Speaker A: Yeah, I think businesses, organizations, government organizations, nonprofits, all of those organizations exist to deliver some kind of outcome to a, ah, customer, a user or a citizen.

Speaker B: Right.

Speaker A: So organizations tend to be, tend to know how to define those outcomes. Those are in their strategic plans that really what defines success. Uh, those outcomes basically value delivered to a market, a customer, a citizen, um, and outputs are what we build to Deliver that value. And of course then we've got different methodologies for tracking and measuring outcomes such as objectives and key results and so on. So I think outcomes are this generally well understood concept of what we're trying to deliver, uh, to the customer in terms of value to that customer and value to the employee. And actually you probably know this, I actually split this out in the outcome loop is that you're delivering both customer value, employee value, because in the end it's happy employees that deliver customer value and together those create business value where that business value um, should also be measured in terms of outcomes. And that can be profit, revenue, market share growth, um, retention rates and uh, customer satisfaction, citizen satisfaction rates, all of those sorts of things. And so basically we've got inputs, strategy, budgets and so on. We've got outputs. That's all the activities that we do, so all the work that we do as humans, uh, and humans working with agents to create artifacts. And those artifacts are things like code and services and uh, digital assets and so on. And then those drive outcomes and basically business outcomes composed of customer and employee outcomes. And that's actually the whole outcome loop, it's this feedback loop. And what's happening with AI, uh, is that it's now becoming, we should assume it's going to be 10x easier to deliver those outputs. And if it's 10x easier to deliver those outputs because previously the outputs were the constraint how much value we could deliver. The constraint where is then the next constraint in our outcome loop. And going back we were talking about the constraints earlier for those less familiar with it, uh, what that theory says is that in any complex system you have a, ah, primary constraint that the bottleneck of that system and that if you make any other part go faster, it doesn't matter, the system will only go as fast as the constraint. So if you have the analogy I use, because I think it's a pretty obvious one, if you have a car manufacturing line and a phone as an example, uh, a common constraint and this has kind of evolved in project to product. I saved it for the end. I'll give the spoiler now, uh, uh, but a paint shop, it takes paint time to dry. So it doesn't matter if you automate other parts of the line. If cars are waiting on the paint shop or the bodies are waiting on the paint shop, um, or on the wiring harness installed. That's another common constraint in a car manufacturing plant. Uh, so I think the core of output to outcome is understanding and defining this outcome loop. Assuming and actually Seeking these productivity gains in how many outputs you can generate but making sure that those outputs are actually connected to outcomes and then back to the strategic plan.

Speaker B: Yeah, I think the outcome loop definitely is one uh, very, I uh, would say core to your idea. Right, because like what you said, right, if you can only just improve the output loop of certain parts of organization it won't be optimal as well. And uh, outcome loop is not just the only thing, right. There's another two other aspects, right, the product operating model and also the outcome tree model. So let's go maybe to the product operating model because this comes back to your previous book, right? Project to product. So looking at the industry do you think people are already adopting product uh, approach? Um, but from my experience I think I still see some organizations dealing with, I don't know, like software project or whatever that is as a project. Right. So from your view has this uh, picked up or becomes a norm in the industry or something that is still kind of like lagging behind?

Speaker A: Yeah, I would hope it'd be the norm now. You know tech companies, startups, hyperscalers, those companies work in a product model. Um, and product model is about having well defined product value streams, whatever you call them, can call them programs, platforms, products and so on. Um, and then fast flow through those value streams and able to invest in capacity of those value streams, not projects that are short lived or episodic. Um, and basically you're assigning people to projects rather than having stable capacity funded, um, stable teams of capacity funded value streams. So uh, I think the challenges, and this is going to uh, called out at the start of the book, some organizations never actually succeeded in their agile transformations because they didn't establish proper product value streams. And if you don't have that, if the way that you deliver has week long day or week long bottlenecks upstream of development teams and then multiple week long bottlenecks downstream of development teams,

Speaker B: it

Speaker A: doesn't matter how much AI acceleration you apply to the middle because it'll be constrained of those things upstream and downstream. And the data that the output outcome summarizes, uh, from the project to product state of the industry survey which we ran in 2023 and 2024 is that across this data set of three dozen organizations, um, that we studied and uh, 3,600 different value streams, we saw that only 8% of the end to end m time spent in delivering value through software was actually spent by the agile teams, the development teams and the rest was in these upstream and downstream constraints of those teams and So I think the challenge is if organizations should have already implemented a product operating model because you can't implement an AI transformation on top of a waterfall project management model. Which is why I kind of set this out as a foundation for that next step of the outcome and the outcome tree.

Speaker B: Yeah, and interestingly you also bring in Kinefin framework to actually kind of like explain why project makes sense in certain domain. Right. And why product makes sense in certain domain and why now with AI the equation kind of like um, becoming different. Right. So maybe tell us how, how do you bring this Kinefin framework so that people can also kind of like use that to apply it within their organization?

Speaker A: Well, yeah, and that was actually something that was a foundation of project to product. And I regretted not putting into that book, um, is the Cynefin framework because I always used it myself to understand it's a sense making framework. Uh, and it really partitions the world that you can deliver things in or deliver value in into four domains. There's the simple domain, um, complex and chaotic. And you can actually use project management successfully in the simple or sometimes the complicated domain. The complicated domain is like building data centers, um, or bridges. And they're complicated, there's lots of interconnects and expensive GPUs and things. Um, and you've got you know, complicated supplier relationships. I'm sure I can't imagine doing that right now. It seems like it's difficult to do. But fundamentally the laws of physics don't change on you and supply, you know, the um, you, you're able to actually forecast, you're able to build long term forecasts on how long it'll take you to get access to the electricity or the materials or the, or the chips that you need to build this thing. Um, so you don't actually need to have this very fast feedback loop. But once we get into the complex domain, um, in the complex domain, uh, you can't accurately predict what will happen in the future. And it's because there's too many. Complex domains are really things that have emerged. You're getting into emergent phenomena. For example, if I'm going to build a new AI native, uh, mobile chat solution tomorrow, I have no idea how many other companies just got funded to do the same thing. So I actually don't have enough information about the future. And this is where creating two year plans like you can do for a data center makes no sense. Right. Because things are changing AI and of course AI is accelerating that change in really important ways. Um, and so you actually then need to quickly be able to sense things and plan and replan and respond. Um, and that's why the product operating model is needed is to. Because product project bench works in simple and complicated domains, but it doesn't work in complex and chaotic domains. And so you need to first of all recognize which parts of your organization are functioning in the complex or chaotic domains, uh, and then apply the product operating model to those and then create these fast feedback loops. Like create the outcome loop as your fast feedback mechanism because in the end that loop is just around the speed of decision making as things change in that domain.

Speaker B: Yeah. And also one thing interesting in your book you mentioned that AI in the complex domain, uh, is actually much more appropriate to become like, ah, augmenting human decision making rather than actually doing the whole agentic thing. People now are kind of like crazy about it, building an agentic workflow such that it can even run the whole company and building the software by itself. So I think, why do you come up with this kind, um, of conclusion that AI in a complex domain can actually uh, augment human decision making, human, uh, process, thinking process, rather than going all by itself?

Speaker A: Yeah, this goes back to this, I think important concept, uh, around, um, and it's from there's this amazing book by Neil De Lance called um, Atomic Human. And he's kind of one of the forefathers of this current generation of transformers and models. And in the end, um, complex systems, some of them have irreducible, they have uncertainty. Um, and so if you have enough uncertainty, you have emergent phenomena and really chaotic behavior. Which is why it doesn't matter how many agents you spin up tomorrow. You can't tell me precisely what the weather is going to be three days from now where I am in Vancouver, because in the end that's a chaotic system. And so you would actually need a computer the size of the universe to compute that. Right. And the universe is the only computer like that that we have right now. Um, so I think this is a really, to me this was a really important insight as of course I, as a leader leverage AI more and more that there are some domains and of course leadership really involves this day to day, um, where you're going to get help from AI, from presenting the data in front of you. You can get an agent to make the call, but it's not necessarily going to make ah, a better judgment call than you, because that really depends on is your brain better at pattern matching than its brain. And in the end it should be these things working Together, because, uh, accountability and intentionality and this is kind of one of the, uh, foundations and one of the key prompts in output to outcome is human. Right. So we want AI to amplify those decisions, but as leaders, we're the ones who are accountable to those decisions.

Speaker B: Right.

Speaker A: If we just burn half the company's budget on tokens, the model is not getting in trouble with a cfo. Uh, you or I are getting in trouble with a cfo. Um, so we want to augment those decisions. Uh, we want to amplify them as much as we can with AI, but because they have this irreducible uncertainty, we can actually delegate all those decisions to AI. Um, and so I think, and this is just a foundational principle, this is not going to change with models that are 10 or 100 times more powerful. Uh, they still won't be that great at giving you the weather a week out or that much better than humans working with models on getting that weather. So, uh, yeah, this is kind of one of the core foundations that decision making and accountability are human but should be amplified by humans. And while many CEOs and other leaders will continue to use agents to augment their work, uh, the book actually proposes that decision making hierarchy, um, the network below that hierarchy, uh, is the domain of humans amplified by AI. The goal is to then answer questions, well, how do you structure that where we can be working with agents collectively?

Speaker B: Yeah, I find this is one of, uh, core interesting insight, uh, from the book. So definitely it makes sense. Right. So, um, the next model is the outcome loop model, which you have kind of like explained a little bit in the very beginning. Right. One thing that I want to ask you is that now every software development teams, I'm sure, kind of like into AI, they use agentic workflow, sometimes spinning up multiple agents to work on the task. And this is creating, uh, a lot of output. But in some organizations that you mentioned, they haven't really transformed other parts of organizations. What trends do you think would happen to those organizations? Um, because I think maybe this is my guess, right? Some organizations actually opt for layoffs rather than transforming the organizations because they think software development is kind of like solved problem. Right? You can produce output, um, so they decide to do layoffs. So what do you think would happen in some trends of organizations that you have seen?

Speaker A: Yeah, I think this is one of the most concerning and scary things happening right now. Right. Which is that there are lots of organizations under budget pressure, um, some of them because they're spending on GPUs, some of them because they're spending on tokens and inference and so on. Um, but we're seeing these gains in outputs. If you make your decision on cutting, let's say 20%, whatever percentage of your software developers based on an output productivity gain, not an outcome gain, you uh, could actually end up with, let's say reducing your outcomes like customer retention by 50% if you don't have actually this visibility and this ability to predict how changes to the inputs. Because a budget's an input to an outcome loop. Right. So I'm going to change the budget, I'm going to reduce the budget by 20%. Um, because now developers should be able to be 20% more productive. Um, but if I didn't actually have that connected properly to outcomes, uh, and all of a sudden the teams have cut, the developers have cut and so on, are not able to make up that gap, uh, all of a sudden my retention rates could go down by 30% instead of my initial assumption was that they would remain stable because the output productivity gain I baked in 20%. And this is the problem of applying just this kind of really simple financial model to output productivity gains that doesn't actually translate to the financial metrics, um, that determine whether an organization and its customers, uh, and employees are successful. And I'm seeing a ton of that. Right. Which is that there's leaders are saying let's assume X percent productivity gain and lay that same percent of the workforce off.

Speaker B: Yeah, I think it's ah, really happening a lot in the industries. People are feeling anxious about it. So one, um, aspect of this uh, outcome loop that I want to also ask you because I can see so many organizations, especially big organizations are really having troubles to actually do a ah, faster feedback loop on the strategy and budget. Right. Uh, I think planning is always very difficult. You have to uh, put people together, collaborate, align priorities and whatever that is the budget. I think in the financial cycle still kind of like not many people do this agile budgeting, whatever that is. Right. Typically it's like one year long or even quarterly maybe for some, um, but it seems like not fast enough. So what would you advise leaders to do, uh, in this situation to increase the feedback loop for strategy and also budgeting.

Speaker A: Yeah. And I've been part of budgeting cycles for a couple of decades so I won't say it's easy to do agile budgeting or like monthly budgets. Right. Like those things are at scale, those are difficult. So output uh, to outcome doesn't actually assume that you're going to switch to Much faster budget cycles at the top level. And this is where we get to the outcome tree. Um, so the outcome tree is really this, and we can talk about this more in a minute. But uh, it's this tree of outcome loops where you've basically got this cascade, uh, and you've got teams of agents and people and kind of like every node of that tree right down to the leaves. Um, and so at the top level you're probably still setting an annual budget. Right. That's just how these companies work. But what you need to do is create empowerment and independence of action at the lower levels of the tree so that those teams are able to actually respond and learn and deliver value and autonomously manage their own outcome loop. Because there is no way to move fast. Well, let's assume, I'm sure there'll be AI native organizations or like you know, one person companies with a billion of revenue or something where it really is the budget at the top level of the outcome tree. The budget can happen on a weekly monthly basis or something of that sort. Right. But for larger, more complex organizations with many humans and, and these kind of bigger cascades of down of budgets up and strategy up of outcomes, um, you have to, I think the only way through this is to apply that autonomy and empowerment at the lower levels down, uh, and just make sure you have transparency to the levels up and so that those lower level teams and value streams, uh, can actually adapt on a weekly basis.

Speaker B: Yeah. So definitely it's a harder challenge when you are bigger organizations where you have, I don't know, thousands of people. Right. So many different departments. So, um, definitely it's one challenge for leaders out there. You brought up about the Outcome 3 uh, model. Right. Uh, which is like how would you organize this? So many different outcome loops um, that are in the organizations. I want to ask you, uh, about this organization structure because I think I've heard with so many other guests as well, in order to reap the benefits of AI, uh become AI native organizations, you really need to structure your organizations differently. No more traditional, I don't know, functional silos. So many different departments, handoffs and all that. What do you think is the optimal organization structure for output? Sorry, Outcome, uh, management model. Right.

Speaker A: And to me this was one of the things I sort of questioned, was deeply about what I'd come up with and talk to the most people, um, about. But the outcome tree is a hierarchical structure. Right. And so much agile literature and so on is about getting away from hierarchies. Right. Um, but I think the only structure where autonomy can scale is actually a hierarchy is a tree. Right. Where you're able to actually provide autonomy at the leaves, that autonomy cascades up and you've got the self similar structure and it works. Right. We've got evidence of this working from the way actually many of the hyperscalers work. This is Amazon single thread structure. The way that GMs own their PNLs all the way down and they've got um, nearly a dozen of these levels. So it actually scales to enormous sizes because uh, just of the scaling laws of hierarchies, right, you can support a very, uh, to use a metaphor, um, ah, a single trunk can support tens or hundreds of thousands of leaves on a tree. And actually the same thing is true for organizations of people and agents. And so I think what's happened to a lot of organizations is that these hierarchical structures have been used for command and control and then the outcome tree is the opposite. It's an empowerment and ownership structure. Uh, and that's fundamentally, I think what's needed is to have that decentralized ownership, but with a cascade all the way up so that the leadership of the company can make the appropriate investment decision decisions, um, around how to structure the top levels of the outcome tree. Here are the products we're investing in, here are the markets we're investing in, um, but then really delegate that ownership down while having real time visibility into the outcomes being delivered. But give the teams at each level complete autonomy over what outputs they built, how they built those outputs.

Speaker B: Yeah, so instead of command and control, you give more empowerment, autonomy and trust to the team. And I also read in some of the literature, like what you mentioned, instead of giving them the output, how they should do something, give them the outcome and let the team kind of uh, resolve the problem. Right?

Speaker A: Yeah, they get the outcome. Um, exactly. The outcomes are specified. Now of course the team will often have to specify, be involved in specifying the outcomes. In the end you're giving them, there's a strategy, there's a budget, those cascade down. So there's still a control structure because of course company leadership needs some kind of control structure and a visibility structure. Uh, but the teams are empowered on exactly what outputs they create. Right. One team might decide they're going to build because they can 10 versions of a, ah, new mobile application, not one, and see which one is the best, um, and then see which one delivers on the objectives that were agreed upon in the planning process.

Speaker B: Yeah. One other thing that you mentioned about organization structure is to actually come up with a more modular approach, a modular ah, setup of organization. This is borrowed from architecture design where the best practice is always coming up with a modular thing. Um, so tell us, how can we apply this modularity in the architectural and code sense into organization as well?

Speaker A: Yeah, right. And this is really my background is in, for better or worse is in software architecture. Um, but I think the great thing with software and software architecture is that uh, in the decades of that discipline forming and maturing, uh, we learned how to deal with very complex systems with very many moving parts. And we learned that the uh, only way to deal with that kind of complexity effectively is with good modularity, um, where you have let's say high cohesion. That means I've got a platform component that encapsulates everything I need to encapsulate around, let's say graph data storage or something else and then everything can build on that. Um, because we've got low coupling, it means I can build many different services on that new graph storage graph database without actually understanding the internals of it. So I can then swap out different actual graph database technologies and I've got independence of action on the value stream. So the people and agents working on the graph database service. So I think that the amazing thing uh, around modularity is that we know it works for the actual software itself and so output uh.com applies those same modular principles to value streams. Where we want that independence of action on the value stream, both in terms of the software it's building, but in terms of how it's coupled to the rest of the organization. Because if we've empowered the team just to keep going this example, if we've empowered the platform team that's building the graph data service, uh, if we've truly empowered them, they should actually be able to determine what graph database technology they're going to use as long as it fits into that budget. Right. And how they're going to build it as long as it fits into the budget of the tokens and people, um, cost and hosting costs that they have. So uh, this providing value, really the whole concept here is to make it easier for teams and agents to work on these things. We actually need to create these modular boundaries of those things and then make sure that they're loosely coupled. And it really is applying the principles of good software architecture to organizational architecture.

Speaker B: Right. And I also think that uh, the interface between these modules is kind of also crucial. Right. Like how determines how teams actually collaborate with each other. What's the communication kind of like pattern? Right. What's the input and output?

Speaker A: That's right. With the goal of low coupling, which means fewer as few dependencies as possible outside of that tree structure between teams. And of course sometimes you have those dependencies, you have to keep managing those dependencies, you'll evolve that outcome tree based on those dependencies. Um, but really making sure it's as loosely coupled as possible. Which really just goes back to the principles that we saw working in kind of that era of software and cloud.

Speaker B: Right.

Speaker A: That's how cloud services became effective and large scale. So, and not to mention that the team supporting them, there's this, the concept's called socio technical congruence. When you're software architecture and your data architecture and your team structures are aligned.

Speaker B: Yeah. So definitely fascinating applying architectural best pattern to organizational pattern as well. So, um, after speaking about the model in your book, you outline these seven shifts that company can do, organization can do in order to move into this outcome approach model. Right. So, uh, there are seven of them. I don't think we will be able to cover, uh, all of them. So maybe if there are some favorites that you want to share to the audience here to kickstart, you know, switching from their output, you know, mindset into outcome mindset. Maybe some favorites of yours.

Speaker A: Sure. I think like the, the first one, um, the is the shift is from functions to flow. So it's kind of an obvious one. Right. You can no longer have this functionally solid organization. You need to have value streams and outcome loops oriented around delivering value, um, which really was part of that whole product model and approach and so on. Um, and then each of these shifts introduces a model to make it easy to talk about the ship. So that one was the dedicated leadership model is that you need, uh, basically for every single value stream, this whole hierarchy, these things nest and cascade. Uh, you need a dedicated leader whose entire role is focused on that value stream. Uh, they don't have dual roles, they don't manage multiple things. Uh, in the end they manage the team and agents for that value stream. And then as you go up the tree you might have the now a more senior manager who manages multiple of these. And it's really to create, to make sure that the leadership structure and the outcome tree are one structure. And you might go with a two in the box leadership if you have separate product engineering or three in the box if you've got separate um, AI engineers or ML people and so on, um, or designers. But the key thing is to simplify everything and to reduce coupling by making this single Structure that underpins the whole organization.

Speaker B: Yeah. The other one that you kind of also mentioned in the very early is like the manager to maker, maker to manager, um, shift. Uh, so I think everyone kind of like uh, these days have the capability uh, to use AI to transform their output. I think many people even say middle managers are not required anymore simply because everyone is doing something, everyone is building something. So this shift I think is kind of like important for individuals, not just at the organization level. What do you think uh, should happen to individuals when thinking about this shift?

Speaker A: Yeah, I think those things are intertwined. Right. Because let's just say middle manager is not required. So let's just say my organization is going to, the way that I'm going to deliver value through um, our offerings is going to be composed of a thousand different things between all the platform components and application components and so on. So if I don't need middle managers, then I just need one CEO and a thousand individual contributors building that. And I would not want to be that CEO. Right. To have to actually understand a thousand different services, um, and applications and so on, it just doesn't really. And even working with agents, it just doesn't make sense to me as a human to manage that. So then of course maybe I'll want like 10 lieutenants, um, who then. So each one of them um, is managing Ah, 100 of those things. But then maybe that's too much for them. And so I think the key thing is we're going to end just because of the way complexity works. And AI agents and agents are going to increase the complexity, not decrease it. I think we're going to need these, we actually will need these layers of management. It's just a very different kind of management, um, where reporting and project management and all those things are, those things that agents can do for a manager are just not necessary anymore. But we still need to manage that complexity with some kind of hierarchical modular structure. And that understanding and managing and leading that structure and owning the outcomes and being responsible and accountable, uh, for those and making sure we've got, you know, someone's always got to be applying the theory of constraints to the outcome loop for that value stream as well. Because no matter what you've got people and agents and you have to make the work easier, not harder. Um, you have to take friction out of the system and that's going to be that new role of leadership or management. Um, so I don't think we're going to the managers. The role of, and the nature of management and leadership Will disappear, will change fundamentally. Um, and you might have organizations that have a very different model. Right. Last I checked, Nvidia had 60 people reporting to Jensen. Right. So you might have different branching factors in your country where instead of, you might not have, you might go from two pizza sized teams to one pizza sized team to two person size teams. I know, four slices, four slice teams, something like that. Um, but you'll still need to have this kind of structure, this kind of leadership and ownership and accountability structure. And so I think that means middle management doesn't go away, but it changes fundamentally because it's quite possible for everyone at those management levels to actually be building things as well. Um, which is why that title chapter is called Managers to Makers.

Speaker B: Yeah.

Speaker A: Or Makers to Managers. Right. Because again that role of management changes. I don't think it goes away. And this is again where I think we can get these very problematic assumptions. Oh, AI can do management, let's get rid of all middle managers. But rather than let's figure out what the new role is, see who fits into that role. And I actually think what's going to happen. Well, m. I wonder if what's going to happen is that, and I do, I guess talk about this a little bit in that last chapter, that Managers to Makers chapter is that a lot of the people who understand complex systems and system thinking and software people who are coming back from a software development background will actually be very good for those new managerial roles. So.

Speaker B: Yeah. And not to mention software developers is able to break down things in a smaller uh, chunks. Right.

Speaker A: Yeah.

Speaker B: I was told that this is not apparent for some other people in other roles. Right. Um,

Speaker A: and I think it's the ability, as those of us with that kind of software background, we're accustomed to managing really large complexity and that's really what this is about in these new organizations going to be able to build so much, um, that making sure that you can manage what's built and create this feedback loop and continually um, uh, remove constraints and basically accelerate that feedback loop with AI, um, is a kind of systems thinking discipline.

Speaker B: Right. So Mick, we have covered a lot of things before we go to my last question. Is there anything that is important that you think we should also kind of discuss? Uh, a little bit uh, from your book or uh, maybe some message you want to give to listeners about the book as well?

Speaker A: Uh, I think the main thing is that I hope that there are, like you said, there's three core models, there's seven shifts. So there's a lot in the book um, but I think I tried to do it in a way where you can do a bit of choose your own adventure. Right. If you want to kind of unify your cadence, how you plan and strategize and iterate, maybe you start there. So I think there's a lot there, but I'm hoping that people. I would recommend reading it sequentially. It does not need. I've not tried reading it non sequentially, but I did make it modular enough, I hope to mean that you can kind of pick and choose the parts that you want to read, uh, and really the models that you want to apply. So yeah, I'm hoping it's helpful for people to kind of like decomplexify a lot of what's been going on around AI.

Speaker B: Right. From my view, you need to read part one and part two sequentially. And then for part two you can just pick and choose whichever shifts that you like.

Speaker A: I think that's exactly. Yeah, that makes sense. I should have said that.

Speaker B: Right. So, Mick, uh, as a tradition in my podcast, I only have one last question for you, which, uh, I call the three technical leadership wisdom. So just think of it like advice you want to give to the listeners before we part our way. Uh, end of our conversation. So maybe, uh, what is your version of wisdom you want to share today?

Speaker A: Well, I think one of the core ones is, especially around people navigating the changes in their careers, is again, to move away from the context that you came from, whether it was software management or leadership or go to market or those sorts of things and just learn as quickly as you can the other aspects of the roles. If you were more on the coding side, learn more about the product management side. If you were on more of the product side, learn more around the technical side. And I think the great thing with AI is they can actually help you accelerate that journey because you've got this thought partner who can be teaching you along the way.

Speaker B: Right.

Speaker A: Uh, as you're doing this, um, I think the other key thing is to really not just help organizations. And of course this is different the approach, this is different depending where you are in the organization. Do not take current organizational models, org charts, um, designs, um, as something that's going to succeed in the future. So if you're just an individual with a team, change how your team works. If you've got two teams reporting to you, again, apply wherever you are. I think it's key that apply these concepts. And that was another actually key aspect of the book is that it really is meant to look at the whole organization. But I do hope people who are just a member of a team can apply some of these concepts just to their team because it takes obviously, uh, longer to change the entire organization. Um, and then the other one I think that's really interesting is obviously right now learning to learn is key because there's so much change going on. Um, I think the other key thing that I think is a really important, I think career or helpful with careers is both obviously lean into learning to learn as quick as you can. But really this ownership. I think the more people, wherever they are in the organization, can take ownership of outcomes and really do that through their own initiative, the more value they'll provide their organization. I think we're entering this age where clarity and well structured ownership of outcomes is what determines organizational success at every level. So I think, uh, I work with a lot of individuals who are trying to figure out, figure that out. I think obviously you need some kind of strategy and direction from the top. But really if you're at the top, provide that strategy and direction. If you're at the bottom, just identify your scope of ownership, uh, define those outcomes and communicate those outcomes.

Speaker B: Yeah, very important advice. I feel like ownership of outcome. I think every one of us here can do that in some parts of the organizations. Right. So understanding the outcome that is uh, expected from your role, from your team, and knowing the kind of like the boundaries, right, where you can own something, I think that's very important in this era. So Mick, thank you so much for your time. If people love this conversation, they want to check out more resources from you, reach, um, out to you online. Is there a place where they can find you?

Speaker A: Yeah, Google, uh, for output to outcomes, probably the easiest thing. And then LinkedIn and I will have, I have not. Uh, I'll put that website up soon. That's my, the book. By the way, I should mention this is the first podcast since the book was finished. The book went to the publisher yesterday, so that's the biggest waterfall process ever. Um, because it's April right now, it'll take a while to get it all printed and audiobook recorded and so on. So it's July 14th is the publication date. Um, but yeah, so just LinkedIn. And uh, now that I'm done with the book, I'll put up the website.

Speaker B: Yeah, congratulations for reaching the milestone. I hope uh, you um, you have a very good success with your book and hopefully also transforming organizations out there to, you know, kind of like approach this using more outcome rather than output. Especially in this AI era. Thank you so much, Dr. Mick, for your, uh, time today.

Speaker A: Thank you so much, Henry.

Speaker B: Sam.