#262 - The AI Productivity Paradox: Why 10X Output Doesn't Mean 10X Business Outcome - Mik Kersten

[00:02:02] Introduction

Henry Suryawirawan: Hello everyone. Welcome back to another new episode of the Tech Lead Journal podcast. I’m very excited to have Mik Kersten with me today, another IT Revolution author. He’s actually coming up with a new book titled Output to Outcome. But previously actually, Mik is well known 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 Mik about his new book and also this project-to-product operating model. So Mik, welcome to the show.

Mik Kersten: Thank you, Henry. Great to be here.

[00:02:40] What Makes Output to Outcome Different From Project to Product?

Henry Suryawirawan: Right. Mik, maybe let’s start, 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.

Mik Kersten: Yeah, it started as a bit of a continuation, right? There were some things in Project to Product that, you know, I, wish I’d basically developed a little bit further. For example, how to work with platforms, right? You start with building products and product value streams, and then 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, you know, involved closely in technology and building products, we’re all starting to increasingly build them with AI, right?

So really since, and you know, 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 an agentic 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, you know more so than it being a continuation of Project to Product, I really wanted to be an AI-centric operating model that encapsulate everything I’ve learned to date, you know, building software and building companies and technology organizations. But really around entirely based on being an AI native.

So the book actually stands alone from Project to Product. It’s, 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 gonna only gonna read one now, it’s, I think Output to Outcome has, stands separately while building on some of the principles of Project to Product.

Henry Suryawirawan: Thanks for sharing the reason of your book. So definitely the AI thing, definitely is one crazy thing that is happening. It can, I think it can be said, it turns upside down the whole software development lifecycle, 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 to have such guidance for organizational transformation to succeed in the AI era.

[00:05:02] Why Did Mik Write Every Word of This Book Without AI?

Henry Suryawirawan: So maybe one trivia question before we go 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 dunno, improve their writing, you know, getting polished or whatever, right? So tell us the reason why you opted not to use AI.

Mik Kersten: Yeah, it was an interesting decision at the start, right? And then obviously I use AI very heavily for researching the book. You know, over the course of that year was on the top. I ended up, I noticed from that annual report of being in the top 2% of ChatGPT users because of how heavily I was using deep research and everything else. But I did decide early on to write every word in the book myself and not to use AI for that. You know, and of course I do this for other formats, but not use AI for any revision cycles and just have it written in my voice. And it was largely because, I mean, for, it was a personal thing in the sense that, I, you know, I think and evolve my ideas through writing. So that was a big part of it. And it’s a bit like pair programming for me, right? Like if you pair programming, it’s really fun for certain things. But when I spend 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. So I was not rushing. I want to slow down and really think deeply about these ideas and writing out myself helped me think deeply about it. So that, you know, 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, you know, I was trying to get all new concepts in the book where I think that will help us kind of expand our understanding of these things. For a lot of the conceptual writing, like neither Claude nor ChatGPT models that, you know, that was always used, you know, on the latest and the top subscriptions, they would confuse the concepts more than usual. Like more than I use other things for, because there are a bunch of new things in there, right? So of course, it’s not that, you know, you can’t get interesting insights from them. But I really was using it more for research and for, you know, discussing ideas and discuss with someone else and so on. So just – 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, right? Because there is kind of a similarity in voice, similarity in idea generations that is coming from the models as well. And I did wanna make sure that it was, you know, it was unique as well. So yeah, I did, AI was used very heavily, but in none of the writing or outlining or those kinds of revisions and things and so.

Henry Suryawirawan: Yeah, very interesting. Definitely, for people who are doing creative work, maybe content creation, whatever that is, right, do take this approach as well sometimes, because the creative writing process itself I think can also help you coming up with a unique ideas and novel things, right?

[00:08:18] How Do the AI Prompts at the End of Each Chapter Work?

Henry Suryawirawan: So one other thing that I noticed in your book, this is also another unique thing. For almost every chapter I see prompts included inside, right? So tell us how can we use these prompts? Because I think sometimes some of the topics in the book are kind of like abstract, really like high level thinking, right? How are we supposed to use these prompts to actually help us applying your output to outcome?

Mik Kersten: Yeah, and interestingly, that is the one part of the book, and I of course mention all of this in the book that this co-op where I did actually use AI to iterate on the content. So the prompts, every chapter ends with a prompt on how, you know, the prompts obviously meant to be fed to a model or an agent to help apply the concepts of the book. And so, you know, to highlight some of the key concepts and how you can use them for really decision making around that. For example, you know, this chapter on the outcome loop, really how to approach, 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 the evolutions of their organizational operating model. And it’s really meant to distill for the agents, the key parts, right? 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 of humans is.

So, for example, one of the concepts in the book is that where the book talks about organizational design and structure is, and we can dig into this or not, but humans should always report to humans. And so that there, you know, it took me a really long time to come to that conclusion and didn’t. And looking at various alternatives. But, so the prompt for that chapter says that, you know, regard 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.

Henry Suryawirawan: Right. So I guess it comes back also like, maybe like what you said, right? Using it as a thinking partner, right? Putting specific guardrails, you know, guidelines that you introduce, right, from the concepts. And hopefully it can help humans to make better, you know, outcome and decisions, I guess.

Mik Kersten: Yeah, exactly. And it is guided for the model rather than for the person, right? Because in applying these concepts, I think, you know, the models and agents will have a 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, it’s like why on earth would I not put that directly in the book? So, and it’s kinda – I actually find it, I found it interesting both, you know, writing those prompts, because it does help you think through what the role of human leaders is and what the role of agentic leadership is.

Henry Suryawirawan: Right. Yeah, this is my actually second time knowing an author coming up with prompts. The previous one is, I think Vlad Khononov, 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, I guess, to understand the coupling level within the codebase. So I think very interesting.

Mik Kersten: Yeah, cause I haven’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 record it for the audio book. I guess they’ll, they should read it with a robot voice or something. Because the audio book recording is underway right now. I should check on it.

[00:11:53] What Happens to Organizations When AI Makes Software Output 10 to 100 Times Cheaper?

Henry Suryawirawan: Yeah. Yeah, interesting. So let’s go into the topic of the book, right? So I think we all know this AI thing is happening at the moment, right? It’s getting crazier and hot. You know, everyone seems to be, I dunno, feeling an anxious, scared about, you know, how the world’s gonna 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?

Mik Kersten: Yeah. absolutely. So I think, and it’s of course everyone is having various kinds of challenges and pressure and urgency in how to navigate this era, right? This is, it’s I think it’s fair to say it’s very difficult to navigate this area because there’s so much change and so many unknowns. Which also then makes it kind of difficult to write a book about it as well, right? Because the things are evolving. But I think the book starts off with a very clear assumption and premise, which is that building – and this was clear, you know. Obviously like this is two years ago I was laying some of these foundations. I started writing it in January 2025. But that if we extrapolate things some, you know, it’s gonna get 2X, 3X easier to generate outputs to write code, to create technology artifacts, all those sorts of things. 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, like we hadn’t even seen kind of the, you know, things like Claude Code yet really materialize and more of – I was already working on some of the agentic stuff in my role then as CTO at Planview. But I was not, you know, I, we’d not yet seen that full potential. So for the book, I just made this assumption, and it’s of course a very coarse assumption that it’s gonna get 10 to 100, maybe more, you know, maybe 1000 times easier to produce output, right? So the book just is built on that premise is let’s assume that especially for coding, but for other domains of knowledge work and of for coding, it turns out to be easier than many domains of knowledge work. Which is why it’s obviously a good place to start, that things get order of mag, it gets order of magnitude easier to create outputs. And of course some of this will take years. You know, it’s not, we’re not there yet. 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’s operating model need to adapt in order to be able to leverage that? Because of course many organizations are entirely structured. Their whole management model is all around managing a scarcity of output. So managing it, you know, everyone’s been hiring developers and investing in developer productivity, which of course was near and dear to me for most of my career. 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 or near zero or the cost of electricity? But our organizations are not ready because they were really designed for scarcity of outputs, not abundance of outputs.

[00:15:03] How Do Past Technological Revolutions Help Us Understand the AI Era?

Henry Suryawirawan: Yeah. And interestingly you use past history to actually kind of like explain this because, when I read that part of the book, right? It actually dawns on me. Okay, this is actually a very good kind of like summary, a trend, a pattern, right, from the past history. Maybe, yeah, elaborate a little bit. Well, what’s the, like the pattern that you see from every major technological advancement that happened in our human history, and why it now is actually quite similar as well.

Mik Kersten: Right. Yeah, so I think, I anchor the book – ‘cause of course, when we’re living through this tremendous change right now, it feels like nothing like this has ever happened before. Nothing exactly like this has ever happened before. But of course I think it’s useful to look to similar things of this sort that have happened in history.

And so, you know, like we obviously know that electricity was a pretty big deal when that happened, right? 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 to Product and more recently Output to Outcome, and it’s Dr. Carlota Perez, who wrote the book Technological Revolutions and Financial Capital.

And so she’s created these models of these last five technological revolutions, you know, the most recent ones being age of, you know, oil and mass production and the age of software, 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 her concept 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 of technology eased some kind of constraint, right? You had, obviously when you were, we were automating human labor, 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 that’s, as you’re leading to, I kind of develop this in Output to Outcome, remove that constraint. And, you know, the 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 through, you know, and through artifacts like software and tangible assets like software, which is why software developers were, you know, so core to all this, right? Because you were really limited by how much software output you could create as a tech company, hyperscaler, whatever you were, whatever, you know, whatever you were doing that, in that last period, that last technological revolution.

Now, of course, what’s happening with AI 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. And so now that that’s not a constraint, and this is really the question that Output to Outcome asks at the start, what is the new constraint? And each of these revolutions has brought with it a new managerial model. You know, we got, you know, things like scientific management or Taylorism, and we got things like – and you know, tools like Gantt charts over these revolutions. And which have become, you know, project management, then we got product management. We, before that we got lean, and so on. And I think what Output to Outcome is saying is we both need to understand what’s the new constraint and then to create a new management model for managing that constraint. That’s where I think the way that the organizations navigate previous revolutions is relevant to this one, from this kind of first principles level.

Henry Suryawirawan: Yeah. I like the way you bring up this theory of constraint and also, seeing the, like for example, the output constraint of producing something gets kind of like relaxed now, right? Almost zero at the moment. I think, for writing software. You can easily churn out that stuff. And hence by having that effect, right, you will need a new management approach to actually deal with a new constraint some way, right?

[00:19:25] Is the Traditional Software Developer Role Gone for Good?

Henry Suryawirawan: So speaking about the cost of producing software, I think many people, software developers who are listeners 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. Is it true that it will be gone? Or like how do you actually see the software industry? And because you yourself is a software developer as well, right? So tell us your view on this.

Mik Kersten: Yeah, And so I think this, you know, 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. And then you started seeing how good it was at this language, the languages we were used to speaking like Java and Python, right? Not just English. It was everyone else was seeing how, lots of people were seeing how good it was, English and French and all sorts of other languages.

And so I think what’s happening is that, you know, the traditional ways of coding, they are done, right? Like you can no longer, it no longer makes sense to not leverage agents and Claude Code and Codex in your day-to-day work as a developer. Because so much of what was, you know, what we were all doing by hand is just now so easy to automate. And so it’s, you know, and 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 out there that are about that.

But fundamentally, you know, your productivity does go through the roof. And it’s, you know, you end up with new things that are difficult. Some, a whole bunch of things are easy. Obviously, you know, it’s using existing application but adding basically agentic development to existing applications and now properly modularized things get interesting. You have to rewrite things a ittle. And so I think there are all sorts of new challenges. 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, that’s something I used to, a form of output that I used to love very much, is now more of a hobby thing. It’s like more like back to like building Legos, which I still like to do. And you’re now able to do so much more that you’re actually, you know, 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. You know, I, can’t answer whether we’re gonna have more or less developers. You know, one way of looking at it is that everyone, all sorts of new people will become developers that weren’t. So we’re gonna have, you know, a hundred million developers in a year. Or whether there’s gonna be so much more software written that actually managing all of those services in a way that’s, 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 more 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 is managers to makers or, I kind of joke is, or is it makers to managers, right? These roles are going to blend. You’re not gonna be just a pure software developer, a pure full stack developer, a pure infrastructure developer or those sorts of things. You’re now going to be managing agents and working within a larger structure to deliver value. Because again, the traditional development role is, I think it’s, we’re past that now, so.

Henry Suryawirawan: Yeah. Very interesting take. I’m sure everyone agrees that the job will evolve, right? Our role will evolve. Maybe we become more, I dunno, more full stack, more generalists, going into the adjacent areas, some people say, right, might be like product management, design, whatever that is. So I think thanks for sharing your view.

[00:23:30] Why Do Some Companies Experience an AI Productivity Paradox?

Henry Suryawirawan: In some organizations, actually, when I read some research or maybe surveys, literature out there, some people said, 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 kind of like paradox. So tell us the reason why, and maybe this is something that is also a good segue to talk about the outcome thing that you propose in the book.

Mik Kersten: So I think there’s the kind of two aspects to this productivity issue. Let’s just say, that we’re somewhere, 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. So I think part of this has to do with kind of the edginess and capabilities of the models, right? They’re, they work better for some domains, some languages and so on for, they work better for more greenfield stuff than more legacy appli, you know, large legacy applications, and so on. So I do think that the productivity gains of the models themselves, creating and writing software, we’re still on that journey, and that will just grow, right? And it’s gonna grow fairly quickly given the rate of growth we’ve seen. Maybe it’ll level off, maybe it’ll accelerate, but I think it’ll just get better.

So I think what’s happening – So I wanna kind of extract this from that individual productivity journey because some people working for, you know, some domains, they’re just not gonna see 2X in the next year. And I think, you know, that’s okay. But I think we are on that journey. You know, some people are gonna see significant gains in the code produced, but they’ll have the usual code review bottlenecks, they’ll have the usual challenges with getting, you know, distracted by agents or just getting demotivated for how much effort is to manage these at these agents. Whereas coding was kind of simpler and had less cognitive load in 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 in order to get to even, you know, to 2 or 10X gains for the 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 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, I think that’s just gonna 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. And then I think as soon as you’re getting to those 2X 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, needs to change in order to actually get benefits not in terms of just 2X the output, but in terms of 2X the customer, the business outcome.

Henry Suryawirawan: 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, 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’re not equal, right? I think it’s also not gonna be producing the optimal outcome. I think this has happened before with Agile transformation, digital transformation, right? We always kinda like focus a lot on software developers. But actually the other parts of organizations probably a little bit of waterfall, silo, and all that.

[00:27:47] What Does “Outcome” Mean in Outcome Management?

Henry Suryawirawan: So let’s go into your approach, which is called the outcome management, right? First of all, I wanna clarify what do you mean by outcome? Because this term is being used in many places, right? I just want to level set the understanding for listeners, what is your interpretation of outcome?

Mik Kersten: Yeah, I think businesses, organizations, government organizations, nonprofits, all of those organizations exist to deliver some kind of outcome to a customer, a user, or a citizen, right? So organizations tend to be, tend to know how to define those outcomes. Those are in their strategic plans. They’re really what defines success. Those outcomes, you know, basically value delivered to a market, a customer, a citizen, where an output are what we build to deliver that value. So I think, you know, and of course then we’ve got tech, 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 to the customer in terms of value to that customer and value to the employee. And then, 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 is, should, you know, also be measured in terms of outcomes. And that can be profit, revenue, market share growth, retention rates, and 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, and humans working with agents to create artifacts and those artifacts are things like code, and services, and 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, is this feedback loop.

And what’s happening with AI, is that it’s now becoming, you know, we should assume it’s gonna be 10X easier to deliver those outputs. And if it’s 10X easier to deliver those outputs, because previously the outputs were the constraint, right? How much value we could deliver with the constraints. Where is then the next constraint in our outcome loop? And going back, I meant we were talking about the theory of constraints earlier, for those less familiar with it, what that theory says is that any, in any complex system, you have a primary constraint that’s 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 the constraint, right? So if you have a, the analogy I use ‘cause I think it’s a pretty obvious one, if you have a car manufacturing line or a phone for example. If a common constraint, and this is kind of evolved in Project to Product, I saved it for the end, I’ll give the spoiler now if – But if a paint shop, like 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. So, or on the wiring hardware that’s installed, that’s another common constraint in a car manufacturing plant.

So I think, you know, 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.

Henry Suryawirawan: Yeah, I think the outcome loop definitely is one very, I would say, core to your idea, right? Because like what you said, right? If you can only just improve the output loop of a certain parts of organization, it won’t be optimal as well. And 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.

[00:31:50] Has the Product Operating Model Finally Become the Industry Norm?

Henry Suryawirawan: So let’s go maybe to the product operating model, because this comes back to, you know, your previous book, right? Project to Product. So looking at the industry, do you think people are already adopting product approach? 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 picked up or becomes a norm in the industry, or something that is still kind of like lagging behind?

Mik Kersten: Yeah, I would hope it’d be the norm now. You know, tech companies, startups, hyperscalers, those companies work in a product model. A product model is about defined, having well-defined product value streams, whatever you call them. You can call them programs, platforms, products, and so on. And then fast flow through those value streams and able to invest in capacity with those value streams, not projects that are, you know, short-lived or episodic. But that’s, you basically, you’re assigning people to projects rather than having stable capacity funded, stable teams of capacity funded value streams.

So I think the challenges, and this is going to, you 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 you’re, 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, you now – it doesn’t matter how much AI acceleration you apply to the middle, because it’ll be constrained of those things upstream and downstream.

And this, the data that the Output to Outcome summarizes from the project state, the project to product state of the industry survey, which we ran in 2023 and 2024, is that across the, this data set of three dozen organizations that we studied, and 3,600 different value streams, we saw that only 8% of the end-to-end time spent in delivering value through software was actually spent by, you know, 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, it’s because you can’t implement an AI transformation on top of a waterfall project management model, which is why I kinda set this out as a foundation for that next step of the outcome within the outcome tree.

[00:34:24] How Do You Apply the Cynefin Framework to Your Organization?

Henry Suryawirawan: Yeah. And interestingly you also bring in Cynefin framework to actually kinda like explain what, why project makes sense in certain domain, right? And why product makes sense in certain domain. And why now with AI, the equation kinda like becoming different, right? So maybe tell us how do you bring this Cynefin framework so that people can also kind of like use that to apply it within their organization well.

Mik Kersten: Yeah, and that was actually something that was a foundation of Project to Product. Like I regretted not putting into that book, is the Cynefin framework ‘cause I always used it myself to understand. It’s a sense making framework and it really partitions the world that you can deliver things in or deliver value in into four domains. There’s the simple domain, complicated, complex and, chaotic. And you can actually use project management successfully in the simple or sometimes the complicated domain. Like the complicated domain is like building data centers, right? Or bridges. And they, you know, they are complicated. Like there’s lots of interconnects and expensive GPUs and things. And you’ve got, you know, complicated supplier relationships. I’m sure I can’t imagine doing that right now. But that seems like it’s difficult to do. But fundamentally the laws of physics don’t change on you. And supply, you know, the, you’re able to actually forecast, you’re able to build long-term forecast on how long it’ll take you to get access to the electricity or the materials or the chips that you need to build this thing. so you don’t actually need to have this very fast feedback loop.

But once we get into the complex domain, in the complex domain, 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 around, that have emerge, you’re getting into emergent phenomena. For example, if I’m gonna build a new AI-native, you know, mobile chat solution tomorrow, I have no idea how many other companies just got funded to do the same thing, right? 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. And so you actually then need to quickly be able to sense things and plan and replan and respond. And that’s really the, that’s why the product operating model is needed, is to, because project plans when it 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, then apply the product operating model to those, and then create this 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, so.

[00:37:18] Why Should AI Augment Human Decision Making in Complex Domains?

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

Mik Kersten: Yeah. this goes back to this, I think, important concept around, – and it’s from, there’s this amazing book by Neil D. Lawrence called Atomic Human. And you know, he’s kind of one of the forefathers of this current generation of transformers and models. And in the end, complex systems, some of them have irreducible and they have uncertainty. And so. If you have enough uncertainty, you have emergent phenomena and really like chaotic behavior, right? Which is why you, it doesn’t matter how many agents you spin up tomorrow, you can’t tell me precisely what the weather’s going to be three days from now where I am in Vancouver, right? Because there’s, it’s, in the end, it’s, that’s a chaotic system. And so you would actually need a computer the size of the universe to compute that, right? And that only, you know, the universe is the only computer like that, that we have right now.

So I think this is a really, you know, to me this was a really important insight. As of course I, as you know, as a leader, like leverage AI more and more, that there are some domains, and of course, leadership is really involves this day-to-day where you’re gonna 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 gonna going to make a better judgment call than you. ‘Cause that really depends on is your brain better at pattern matching than its brain or… And in the end it should be these things working together because accountability and intentionality, and this is kind of one of the and one of the key prompts in the 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, right? If we just burn the half the company’s budget on tokens, the model’s not getting in trouble with a CFO. You or I are getting in trouble with a CFO. So we wanna augment those decisions. We want to amplify them as much as we can with AI. But because they have this irreducible uncertainty, we can’t actually delegate all those decisions to AI.

And so I think this, and this is just a foundational principle. This is not gonna change with models that are 10 or 100 times more powerful. 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, yeah, this this is kind of one of the core foundations, that decision making and accountability are human but should be amplified by humans. And while, you know, many CEOs and other leaders will continue to use agents to augment their work, the book actually proposes that that decision making hierarchy, actually, and kind of the network below that hierarchy, is the domain of humans amplified by AI. And tries, you know, the goal is to then answer questions. Well, how do you structure that where we can be working with agents collectively.

[00:40:52] Why Are AI-Driven Layoffs a Risky Bet Without Outcome Visibility?

Henry Suryawirawan: Yeah. I find this is one of core interesting insight from the book, so definitely it makes sense, right? So 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 wanna ask you is that now every software development teams I’m sure kind of like into AI, they used agentic workflow, sometimes spinning up multiple agents to work on the task. And this is creating 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? Because I think, maybe this is my guess, right, some organizations actually opt for layoffs rather than, you know, transforming the organizations, because they think now software development is kind of like solved problem, right? You can produce output. So they decide to do layoffs. So what do you think would happen in some trends of organizations that you have seen?

Mik Kersten: 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. Some of them, because they’re spending on GPUs, some of them because they’re spending on tokens and inference and so on. But we’re seeing these gains and outputs. If you make your decision on cutting and, you know, let’s say 20%, percent of your software developers based on an output productivity gain, not an outcome gain, you could actually end up with, you know, let’s say reducing your outcomes, like customer retention by 50%. Like you, if you don’t have this, actually this visibility and this ability to predict how changes to the inputs, because the inputs, a budget is an input to an outcome loop, right?

So I’m gonna change the budget, I’m gonna reduce the budget by 20% because now developers should be able to be 20% more productive. But if I didn’t actually have that connected properly to outcomes and all of a sudden the teams have cut, the developers have cut, and so on, are not able to make up that gap, 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 can’t, 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, but that determined within an organization and its customers are, and employees are successful. And I’m seeing a ton of that, right? Which is that there’s, you know, leaders are saying, let’s assume X percent productivity gain and lay that same percent of the workforce off.

[00:43:32] How Can Leaders Increase the Feedback Loop for Strategy and Budgeting?

Henry Suryawirawan: Yeah, I think it’s really happening a lot in the industries. People are feeling anxious about it. So one aspect of this outcome loop that I wanna also ask you, because I can see so many organizations, especially big organizations, are really having troubles to actually do a faster feedback loop on the strategy and budget, right? I think planning is always very difficult. You have to, you know, put people together, collaborate, you know, 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. But it seems like not fast enough. So what would you advise leaders to do, you know, in this situation to increase the feedback loop for strategy and also budgeting?

Mik Kersten: Yeah, and I’ve been part of budgeting cycles for a couple decades, so it’s, I won’t say it’s easy to do Agile budgeting or like monthly budgets, right? Like those are, those things are, at scale those are difficult. So Output to Outcome doesn’t actually assume that you’re gonna switch to much faster budget cycles at the top level. And this is where we get to the outcome tree. So the outcome tree is really this, we can talk about this more in a minute, but it’s this tree of outcome loops where you’ve basically got this cascade, and you’ve got teams of agents and people in kind of like every node of that tree, right, right down to the leaves.

And so at the top level, you, you know, 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 the independence of action at the lower levels of the tree so that those teams have, 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 enough – Well, let’s assume. I’m sure there’ll be AI native organizations are like, you know, one person companies with a billion of revenue or something where it’s, 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 these kind of bigger cascades of, you know, down of budgets out of, and strategy, out of outcomes, you have to, I think the only way through this is to apply that autonomy and empowerment at the lower levels down and just make sure you have transparency to the levels up. And so that those lower level teams and value streams can actually adapt on a weekly basis.

[00:46:07] What Is the Optimal Organizational Structure for an Outcome Management Model?

Henry Suryawirawan: Yeah, so definitely it’s a harder challenge when you are bigger organizations where you have, I dunno, thousands of people, right? So many different departments. So definitely it’s one challenge for leaders out there.

You brought up about the outcome tree model, right, which is like how would you organize these so many different outcome loops that are in the organizations. I wanna ask you, about this organization structure, because I think I’ve heard so with so many other guests as well, in order to, you know, reap the benefits of AI, become AI-native organizations, you really need to structure your organizations differently. No more traditional, you know, I dunno, functional silos, so many different departments, handoffs and all that. What do you think is the optimal organization structure for, you know, output, sorry, outcome management model?

Mik Kersten: Right. And this is a, like to me, this was one of the things I sort of questioned most deeply about what I’d come up with and talk to the most people about. But the outcome tree is a hierarchical structure, right? And, you know, so much Agile literature and so on is about getting away from hierarchies, right? But I think the only structure where autonomy can scale is actually a, is a hierarchy, is a tree, right, where you have, 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, right?

This is Amazon single threaded structure, the way that GMs own their P&Ls all the way down and they’ve got, you know, nearly a dozen of these levels. So it actually scales to enormous sizes because just of the scaling laws of hierarchies, right? You can support a very, to use a metaphor, a single trunk can support, you know, hundreds, 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 the, you know, the challenge, I think what’s happened to a lot of organizations is that these hierarchical structures have been used for command and control, right? And then the outcome tree is the opposite. It’s an empowerment, and it’s an empowerment and ownership structure. And that’s, you know, fundamentally I think what’s needed is to have that kind of, that decentralized ownership, but with a cascade all the way up so that the leadership of the company can make the appropriate investment decisions around how to, you know, structure the top level of the outcome tree to, here are the products we’re investing in, here are the markets we’re investing in. 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.

Henry Suryawirawan: Yeah. So instead of command and control, you give more empowerment, autonomy, and trust to the team, right? And I also read in some of the literature instead of, yeah, like what you mentioned, instead of giving them the output how they should do something, right? Give them the outcome and let the team kind of like resolve the problem, right?

Mik Kersten: Yeah.

Henry Suryawirawan: That’s a very…

Mik Kersten: 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, right? ‘Cause of course, company leadership needs some kind of control structure and the visibility structure. But the teams are empowered on exactly what outputs they create, right? One team might decide they’re gonna build because they can 10 versions of a new mobile application, not one, right? And see which one is the best. And then see which one delivers on the, on, you know, the objectives that we’re agreed upon in the planning process.

[00:49:50] How Can We Apply Architectural Modularity to Organizational Design?

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

Mik Kersten: Yeah, right? And this is really, you know, my background isn’t, for better or worse, isn’t software architecture. But I think the great thing with software and software architecture is that in the decades of that discipline, you know, forming and maturing, learned how to deal with very complex systems, with very many moving parts. And we learned that the only way to deal with that kind of complexity effectively is with good modularity, 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. Because it’s, we’ve got low coupling, it means I can build many different services on that new graph, you know, 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. And so that the people and agents working on the graph database service, right?

So I think that the amazing thing around modularity is that it’s, we know it works for the actual software itself. And so output outcome applies those same modulary principles to value streams where we want that independence act 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 with this example, if we’ve empowered the platform team that’s building the graph data service, 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 gonna build it as long as it fits into the budget of, you know, the tokens and people costs that that, and hosting costs that they have. So this, providing values – So 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’s really is applying the principles of good software architecture to organizational architecture.

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

Mik Kersten: 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. 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, right? That’s how cloud services became effective and in large scale. So and not to mention that the team supporting them, there’s this, the concept’s called sociotechnical congruence. When your software architecture and your data architecture and your team structures are aligned.

[00:53:17] What Are the Seven Shifts in the Output to Outcome Model?

Henry Suryawirawan: Yeah, so definitely fascinating applying, you know, architectural best pattern to organizational pattern as well. So 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 there are seven of them. I don’t think we will be able to cover 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?

Mik Kersten: Sure. I think like the first one 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, which really was, you know, part of that whole product model and approach, and so on. And then each of these shifts introduces a model to make it easy to talk about the shifts. So that model is the dedicated leadership model is that you need, basically for every single value stream, this whole hierarchy, these things nest and cascade. You need a dedicated leader whose entire role is focused on that value stream. They, you know, they don’t have dual roles, they don’t manage multiple things. In the end, they manage the team and the agents for that value stream. And then as you go up the tree, you know, you might have the now and 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 AI engineers or ML people and so on. Or designers. But the key thing is to simplify everything by, and to reduce coupling, by making this single structure that underpins the whole organization.

[00:55:10] Will AI Make Middle Management Obsolete?

Henry Suryawirawan: Yeah. The other one that you kind like also mentioned in the very early is like the manager to maker, maker to manager, you know, shift. So I think everyone kind of like these days, have the capability to use AI to, you know, transform their output. I think many people even say middle managers are not required anymore, simply because, you know, 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 should happen to individuals when thinking about this shift?

Mik Kersten: Well, yeah, I think those things are intertwined, right? ‘Cause let’s just say middle managers are not required. So let’s just say my organization is going to, the way that I’m gonna deliver value through our offerings is gonna be composed of a thousand different things, right? 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 wanna be that CEO, right? To have to actually understand a thousand different services, and applications, and so on. It’s, 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, you know, maybe I’ll want like 10 lieutenants who then, so each one of them is managing a hundred of those things, but then maybe that’s too much for them.

And so I think the key thing is we’re gonna end – just because of the way complexity works, and AI agents and agents are gonna increase the complexity, not decrease it, right? I think we’re gonna need these, we actually will need these layers of management, it’s just a very different kind of management, 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, you know, understanding and managing and leading that structure and owning the outcomes and being responsible and accountable, for those and making sure we’ve got, you know, someone’s always gotta be applying the theory of constraints to the outcome loop for that value stream as well to – because no matter what, you’ve got people and agents and you have to make their work easier, not harder. You have to take friction outta the system. And that’s gonna be that new role of leadership or management.

So I don’t think we’re going to, we’re the managers, the role of and the nature of management will and leadership will dis – will change fundamentally. And you might have organizations that have a very different model, right? Last I checked, Nvidia had 60 people reporting to Jensen, right? Like, so you might have different branching factors in the outcome tree where instead of, you know, you might not have, you know, you might go from two pizza sized teams to one pizza sized team to two person sized teams. Like two slice, I know four slices, four slice teams, something like that. But you’ll still have this, 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. Which is why that title chapter’s called Managers to Makers.

Henry Suryawirawan: Yeah. Or makers to managers.

Mik Kersten: Or makers to managers, right? ‘Cause again, that role of management changes I don’t think it goes away. And it, this is again, where I think we can get these very problematic assumptions. Or 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, I’m not, 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.

Henry Suryawirawan: Yeah. And not to mention software developers is able to break down things in a smaller chunks, right?

Mik Kersten: Yeah.

Henry Suryawirawan: I was told that this is not apparent for some other, you know, people in other roles, right? So, yeah.

Mik Kersten: And I think it’s that, it’s the ability, you know, 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. And you have to build so much that making sure that you can manage what’s built and, you know, create this feedback loop and continually remove constraints and basically accelerate that feedback loop with AI, is a kind of systems thinking discipline.

Henry Suryawirawan: Right. So Mik, 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 like discuss a little bit, from your book or maybe some message you want to give to listeners about the book as well?

Mik Kersten: I think, you know, the main thing is that, you know, I hope that the, like there are, like you said there’s three core models, there’s seven shifts, so there’s a lot in the book. But I think I try to do it in a way where we can do a bit of choose your own adventure, right? If you wanna kinda unify your cadence, how you plan and strategize and iterate, you know, maybe you start there. So there’s, 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 and really the models that you want to apply. So, yeah, I’m hoping it’s helpful for people to kind of decomplexify a lot of what’s been going on around AI.

Henry Suryawirawan: 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.

Mik Kersten: I think that’s exactly, yeah, that makes sense. I should have said that.

[01:00:55] 3 Tech Lead Wisdom

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

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

I think other key thing is, to really, you know, not just help organizations. And of course this is different. The approach to this is different depending on where you’re in the organization. Do not take current organizational models, org charts, designs, as something that’s going to succeed in the future. So if you’re just a, if you’re an individual team, change how your team works. If you’ve got two teams reporting to you, again, apply the wherever you are, I think it’s key that apply these concepts. And that was another actually key aspect of the book is that, you know, it really is meant to look at the whole organization but I do hope people, you know, who are just a member of a team, can apply some of these concepts just to their team, right? Because it takes obviously longer to change the entire organization.

And then the other one I think that’s really interesting is, obviously right now, like learning to learn is key because there’s so much change going on. But so I think as the other key thing that I think is a really important, I think, career or helpful with careers, is both of 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 kind of clarity and well-structured ownership of outcomes is what determines organizational success at every level. So I think, I work with a lot of individuals who are, you know, trying to figure that out. I think obviously you need some kind of strategy and direction from the top. But really if, you know, if you’re at the top, provide that strategy and direction. If you’re at the bottom, just identify your, you know, your scope of ownership, define those outcomes, and communicate those outcomes.

Henry Suryawirawan: Yeah, very important advice. I feel like ownership of outcome, I think everyone of us here can do that in some parts of the organizations, right? So understanding the outcome that is 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 Mik, thank you so much for your time. If people love this conversation, they wanna check out more resources from you, reach out to you online, is there a place where they can find you?

Mik Kersten: Yeah. Google for Output to Outcomes is probably the easiest thing and then LinkedIn. And I will have, I have not, I’ll put that website up soon. That’s my – And 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 it’s, now it takes, that’s the biggest waterfall process ever. Because you know, it’s April right now and it’ll take a while to get it all printed and audio book recorded and so on. So it’s July 14th is the publication date. But yeah, so just LinkedIn, and now that I’m done with the book, I’ll put up the website.

Henry Suryawirawan: Yeah. Congratulations for reaching the milestone. I hope 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. Mik for your time today.

Mik Kersten: Thank you so much, Henry.

– End –