# Shifting From Output Metrics To Outcome-Driven AI Operations

**Podcast:** Tech Lead Journal
**Published:** 2026-06-29

## Transcript

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 Meek 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.
Some people said they have tried to apply AI, but their productivity doesn't seem to increase by a lot.
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 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 outputs.
Some organizations actually opt for layoffs because they think cloud software development is kind of like a soft problem.
The traditional ways of coding, they are done.
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 Output Outcome is saying is we both need to understand what's the new constraint and then to create a new management law.
model or 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.
Hey, quick pause.
My goal with TechLegional 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, another IT revolution author.
He's actually coming up with a new book titled Output to Outcome.
But previously, actually, Mick 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 Mick about his new book and also this project to product operating model.
So Mick, welcome to the show.
Thank you, Henry.
Great to be here.
Right, Mick, 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.
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.
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.
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 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 uh 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 more so than it being a continuation of project to product, I really wanted to be an AI-centric operating model that encapsulates everything.
learned to date, 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 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 Outcome stands separately while building on some of the principles of project to product.
Thanks for sharing the reason of your book.
So definitely the AI thing definitely is one crazy thing that is happening.
I think it can be said it turns upside down the whole software development lifecycle, product management, and even the company operating model.
So I think by reading your book 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.
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 don't know, improve their writing, you know, getting polished or whatever, right?
So tell us the reason why you opted not to use AI.
Yeah, it was an interesting decision at the start.
And obviously I use AI very heavily for researching the book.
Over the course of that year, I was on the top.
I noticed from that annual report of being in the top 2% of chat GPT 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.
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 it was a...
a personal thing in the sense that 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'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.
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 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 where I think that will help us kind of expand our understanding of these things.
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.
But I really was using it more for research and for discussing ideas I'd discussed 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.
as well and i did want to make sure that it was you know it was unique as well so so yeah i did i ai was used very heavily but in none of the writing or outlining or or those kinds of revisions and things so yeah very interesting uh definitely uh for people who are doing creative uh work maybe content creation whatever that is right uh do take uh this approach as well sometimes because the creative writing process itself i think can also help you coming up with the unique ideas and novel things, right?
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?
Yeah, and interestingly, that is the one part of the book, and I, of course, mention 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, you know, the prompt's obviously meant to be fed to a model or an agent to help apply the concepts of the book.
And so you highlight some of the key concepts and how you can use them for really decision-making around that.
For example, 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 evolutions of their organizational operating model, and it's really meant to distill for the agents the key parts.
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 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 it took me a really long time to come to that conclusion and look at various alternatives.
But so the prompt for that chapter says that, you know, regardless 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.
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...
introduced right from the concepts and hopefully it can help humans to make better you know outcome and decisions I guess.
Yeah exactly and it is 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, he's like, why on earth would I not put that directly in the book?
So, and it's kind of, I actually find it, I found it interesting both 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.
Right.
Yeah, this is my actually second time knowing an author coming up with prompts.
The 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, I guess, to understand the coupling level within the code base.
Oh, neat.
Very interesting.
Yeah.
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.
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 don't know, feeling anxious, scared about, 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?
Yeah, absolutely.
So I think, you know, and it's, of course, everyone is having various kinds of challenges and pressure and urgency in how to navigate this era.
I think it's fair to say it's very difficult to navigate this era because there's so much change and so many unknowns.
Which also makes it difficult to write a book about it as well, because things are evolving.
But I think the book starts off with a very clear assumption and premise, which is that And this was clear, obviously this was two years ago where I was laying some of these foundations.
I started writing it in January 2025.
But if we extrapolate things some, it's going to 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 time frame is.
And when I started the...
We hadn't even seen things like Claude Code yet really materialize.
I was already working on some of the agentic stuff 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 coarse assumption, that it's going to get 10 to 100, maybe more, maybe 1,000 times easier to produce output.
the book just is built on that premise is 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, which is why it's obviously a good, good place to start that, that things get order of, it gets order of magnitude easier to create outputs.
And of course, some of this will take years, you know, it's, 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 while 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 rules?
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 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.
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 elaborate a little bit.
What's the pattern that you see from every major technological advancement that happened in our human history and why now it's actually quite similar as well?
Right, 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.
But, of course, I think it's useful to look to similar things of the sort that have happened in history.
And so we obviously know that electricity was a pretty big deal when it happened.
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 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 most recent ones being.
oil and mass production, then the age of software and digital, and really anchor how things had to change in those revolutions.
The most interesting thing that dawned on me in having worked with her 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.
The interesting thing around...
talks about the sum that each of those revolutions became, the revolution technology eased some kind of constraint, right?
You had, obviously, when 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, as you're leading to, I kind of developed this in Output to Outcome, removed that constraint.
And, you know, 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, artifacts like software and tangible assets like software, which is why software developers were, you know, so core to all this, right?
you were really limited by how much software output you could create as a tech company, hyperscaler, whatever you were doing in that last period, that last technological revolution.
Now, of course, what's happened 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 Elkwood Evelin asks at the start, what is the new constraint?
And each of these revolutions has brought with it a new managerial model.
We got things like scientific management or Taylorism, and we got tools like Gantt charts over these revolutions, which have become project management, then we got product management, before that we got lean, and so on.
And I think what Output Acum 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.
So 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.
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 somewhere, right?
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 how do you actually see the software industry?
Because you yourself is a software developer as well, right?
So tell us your view on this.
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, before that, you were really just accessing JGP3 APIs.
And then you started seeing how, good it was at the languages we were used to speaking, like Java and Python, not just English.
Lots of people were saying English and French and all sorts of other languages.
And so I think what's happening is that the traditional ways of coding, they are done.
It no longer makes sense to not leverage agents and code and codecs in your day-to-day work as a developer.
So much of what we were all doing by hand is just now so easy to automate.
I think the cognitive load increases a lot with working all of these agents and there's lots of literature and experiences out there that are about that.
But fundamentally, your productivity does go through the roof.
You end up with new things that are difficult.
A whole bunch of things are easy.
Using existing applications, adding basically agentic development to existing applications are now properly modularized.
Things get interesting.
You have to rewrite things.
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 more like back to building Legos, which I still like to do.
And 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 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, 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 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 kind of jokers, or is it makers to managers, right?
These roles are going to blend.
You're not going to 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.
Yeah.
Very interesting take.
I'm sure everyone agrees that the job will evolve, right?
Our role will evolve.
Maybe it becomes more, I don't know, more full stack, more generalist going into the adjacent area.
Some people say, right, maybe like product management, design, whatever that is.
So I think thanks for sharing your view.
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.
So I think there's the kind of two aspects to this productivity issue.
Let's just say that organizations are somewhere between like 20...
percent 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 work better for some domains, some languages and so on.
They work better for more greenfield stuff than more legacy, you know, large legacy applications and so on.
I do think that the productivity gains of the models themselves creating and offering the software, we're still on that journey and that will just grow.
And it's going to grow fairly quickly given the rate of growth we've seen.
Maybe level off, maybe it'll accelerate, but I think it'll just get better.
So I think what's happening, so I want to kind of extract this from that individual productivity journey because some people working for, you know, 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 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 2x or 10x gains 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 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 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.
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.
Yeah, I think it comes back to this theory of constraint, right?
Where now one part 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 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 waterfall silo and all that.
So 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 is being used in many places, right?
I just want to level set the understanding for listeners.
What is your interpretation of outcome?
businesses, organizations, government organizations, nonprofits, all of those organizations exist to deliver some kind of outcome to a customer, a user, or a citizen.
So organizations tend to know how to define those outcomes.
Those are in their strategic plans.
They're really what defines success.
Those outcomes, basically value delivered to a market, a customer, a citizen.
And outputs are what we build to deliver the value.
So I think, you know, 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 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 should 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.
It's this feedback loop.
And what's happening with AI is that it's now becoming, you know, 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 were 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 in any complex system, you have a primary constraint, the bottleneck of that system.
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 an analogy I use because I think it's a pretty obvious one, if you have a car manufacturing line on a phone, as an example, if 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, but a paint shop, it takes 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 or on the wiring harness installed.
That's another common constraint in a car manufacturing plant.
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.
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 path 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.
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?
Yeah, I would hope it'd be the norm now.
Tech companies, startups, hyperscalers, those companies work in a product model.
And product model is about 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 they will invest in capacity of those value streams, not projects that are short-lived or episodic.
Basically, you're assigning people to projects rather than having stable capacity funded.
stable teams of capacity-funded value streams.
So I think the challenge is, and this is kind of 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, 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 the data that the Output Outcome summarizes from the Project to Project State of the Industry Survey, which we ran in 2023 and 2024, is that across this data set of three dozen organizations that we studied, 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 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 in the outcome tree.
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 becoming different, right?
So maybe tell us how do you bring this Kinefin framework so that people can also kind of like use that to apply it within their organization well.
Yeah, and that was actually something that was a foundation of project to product.
I regretted not putting into that book is the Kinefin framework.
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, completely 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 or bridges.
They're complicated.
There's lots of interconnects and expensive GPUs and things.
And you've got 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.
You're able to actually forecast, you're able to build long-term forecasts on how long it will 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.
you're getting into emergent phenomena.
For example, if I'm going to build a new AI native 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.
Because things are changing.
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 why the product operating model is needed.
Because project management 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, and 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.
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, 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 agent workflow such that it can even run the whole company and building the software by itself.
So I think, well, 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?
Yeah, this goes back to this, I think, important concept around, and it's from, there's this amazing book by Neil DeLorence 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 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, right?
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.
So I think this is a really, to me, this was a really important insight.
Of course, I, as...
as a leader, like leverage AI more and more, that there are some domains.
And of course, leadership really involves this day-to-day.
We'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 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.
accountability and intentionality, and this is kind of one of the foundations and one of the key prompts in output to outcome, is human.
So we want AI to amplify those decisions, but as leaders, we're the ones who are accountable to those decisions.
If we just burn 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 want to augment those decisions.
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.
And so I think this is just a foundational principle.
This is not going to 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 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 decision-making hierarchy, actually, and kind of the network below that hierarchy, is the domain of humans amplified by AI.
And the goal is to then answer questions, well, how do you structure that where we can be working with agents collectively?
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 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 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 transforming the organizations because they think cloud software development is kind of like a soft 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?
Yeah, I think this is one of the most concerning and scary things happening right now.
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 in outputs.
If you make your decision on cutting, let's say 20%, whatever percent, of your software developers based on an output productivity gain, not an outcome gain, you could actually end up with, let's say, reducing your outcomes, like customer retention, by 50%.
If you don't have 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% 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 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.
that determine what an organization and its customers 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.
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 want to 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 in this situation to increase the feedback loop for strategy and also budgeting?
Yeah, and I've been part of budgeting cycles for a couple decades.
So I won't say it's easy to do agile budgeting or monthly budgets.
Those things are at scale.
Those are difficult.
So output 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.
So the outcome tree is really this, and 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 and kind of like every node of that tree, right down to the leaves.
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 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 these kind of bigger cascades of down of budgets and strategy up 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.
Yeah.
So definitely it's a harder challenge when you are bigger organizations where you have, I don't know, thousands of people, 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 this so many different outcome loops that are in the organizations?
I want to ask you 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, 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 management model?
Right.
And this is it.
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.
And so much agile literature and so on is about getting away from hierarchies.
But I think the only structure where autonomy can scale is actually a hierarchy, is a tree.
where you're able to actually provide autonomy at the leaves, that autonomy cascades up, and you've got this self-similar structure.
And it works.
We've got evidence of this working from the way actually many of the hyperscalers work.
This is Amazon's single-thread structure, the way that GMs own their P&Ls all the way down, and they've got 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 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 ownership structure.
And that's fundamentally, I think, what's needed is to have that kind of 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 structure the top level of the outcome tree.
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.
Yeah, so instead of command and control, you give more empowerment, autonomy, and trust to the team.
And I also read in some other 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?
Yeah, they get the outcome.
Exactly.
The outcomes are specified.
Now, of course, the team will often have to specify, involve 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?
Because of course, company leadership needs some kind of control structure and a visibility structure.
But the teams are empowered on exactly what outputs.
they create.
One team might decide they're going to build, because they can, 10 versions of a new mobile application, not one, and see which one is the best.
And then see which one delivers on the objectives that were agreed upon in the planning process.
Yeah.
One other thing that you mentioned about organization structure is to actually come up with a more modular approach.
setup of organization.
This is borrowed from architecture design where the best practice is always coming up with a modular thing.
So tell us, how can we apply this modularity in the architectural and code sense into organization as well?
Yeah, right.
And this is really, you know, my background is in, for better or worse, is in software architecture.
But I think the great thing with software and software architecture is that In the decades of that discipline forming and maturing, we 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.
encapsulating on, let's say, graph data storage or something else.
And then everything can build on that because we've got low coupling.
It means I can build many, 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 that the people and agents working on the graph database service.
I think that the amazing thing around modularity is that we know it works for the actual software itself.
And so Output Outcome applies those same modulatory principles to value streams.
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 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 going to build it, as long as it fits into the budget of the tokens and people costs 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 really is applying the principles of good software architecture to organizational architecture.
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 and like pattern, right?
What's the input and output?
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 large scale.
And not to mention that the team supporting them.
There's this...
The concept is called socio-technical congruence when your software architecture, your data architecture, and your team structures are aligned.
Yeah.
So definitely fascinating applying architectural best pattern to organizational pattern as well.
So after speaking about the model in your book, you outlined 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.
Sure.
I think like the first one, 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 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 ship.
So that one was 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 don't have dual roles.
They don't manage multiple things.
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 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 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 and to reduce coupling by making this single structure that underpins the whole organization.
Yeah.
The other one that you kind of 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 everyone is doing something, everyone is building something.
So this shift, I think, is kind of important for individuals, not just at the organization level.
What do you think should happen to individuals when thinking about this shift?
Well, yeah, I think those things are intertwined, right?
Because let's just say middle managers are not required.
So let's just say my organization is going to, the way that I'm going to deliver value through our offerings is going to 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 want to be that CEO, right?
To have to actually understand a thousand different services 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, 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 going to end just because of the way complexity works and AI agents and agents are going to increase the complexity, not decrease it.
Right.
I think we're going to need these.
We actually will need these layers of management and just a very different kind of management where.
reporting and project management and all 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 for those and making sure we've got 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, you have to make their work easier, not harder.
You have to take friction out of the system.
And that's going to be that new role of leadership or management.
So I don't think we're going to...
The role and the nature of management and leadership 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?
So you might have different branching factors in the outcome tree where instead of, you know, you might not have, you might go from two pizza-sized teams to one pizza-sized team to two-person-sized teams, like two slices, I don't know, four slices, four-sized 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 is called Managers to Makers.
Yeah, or Makers to Managers.
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, 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.
Yeah.
And not to mention software developers is able to break down things in a smaller, chunks right yeah i was told that this is not apparent for some other you know people in other roles right so um so yeah 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 and that's really what this is about in these these new organizations you can be able to build so much um 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.
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 like discuss a little bit from your book or maybe some message you want to give to listeners about the book as well?
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.
But I think I tried to do it in a way we 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.
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 like decomplexify a lot of what's been going on around AI.
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.
I think that's exactly it.
Yeah, that makes sense.
I should have said that.
Right.
So Mick, 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 want to give to the listeners before we part our way, end of our conversation.
So maybe what is your version of wisdom you want to share today?
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.
So if you were more on the coding side, learn more about the product management side.
If you were more on the product side, learn more around the technical things.
And I think the great thing...
with AI is actually help you accelerate that journey because you've got this thought partner who can be teaching you along the way, right, as you're doing this.
I think the other key thing is to really, you know, not just help organizations.
And of course, this is different.
The approach is different depending where you are 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 an individual team, change how your team works.
If you've got two teams reporting to you, again, apply it 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, 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 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 trying to 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.
define those outcomes and communicate those outcomes.
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 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 will love this conversation, they want to check out more resources from you, reach out to you online.
Is there a place where they can find you?
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, 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 it's, you know.
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.
But yeah, so just LinkedIn.
And now that I'm done with the book, I'll put up the website.
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 kind of like approach this using more outcome rather than output, especially in this AI era.
Thank you so much, Dr.
Mick, for your time today.
Thank you so much, Henry.