Outcomes Over Output with Mik Kersten

Welcome And The New Book

Hello everybody, and uh I'm looking forward to a very exciting conversation today. Uh we uh Dave and I are joined by uh Mick Kirsten, who uh had a book out earlier in the year, which I am sure some of you have uh read. And so I think with no further ado, uh Mick, would you like to go ahead and introduce yourself?

Hello, Peter. Hello, Dave. It's great to be here. Yeah, so um Mick Kirsten um uh previously wrote this the book, Project to Product, uh that had, I think, an interesting mark on the industry in terms of how people thought about agility in the way it was, I think, always meant to be thought about, which is more end-to-end and more connected to the business and the organization. And then since then, I've been asked a lot about, you know, is a product operat model sufficient for agility? And uh my answer to that was this next book, which is output to outcome.

So you make I'm just gonna jump straight in because you just said a sentence there, which I think is really under um underserved in the market, which is that connection between business and technology, and that agility was never purely about technology, but it was always about that that communication channel between business, technology, and technology back to business. Can you speak a bit about how you've seen that change over time and what maybe your your perspective is on those two sides of that communication uh um channel?

Yeah, I mean, for me the the agile journey was interesting because it was, you know, I started just working on an agile team and back in gosh like '99, we were using Ken Beck's book, uh Extreme Programming. And it was, you know, we we we just did work agile, consumed customer feedback, and it all seemed normal. But for me, what happened is I started working with larger and larger organizations. And then I realized that that there's this kind of like agile middle, these these agile teams, and they were actually disconnected on, I guess, in time and space from the business, right? They were work was being passed to them through requirements and just long planning cycles and those sorts of things.

When Agile Teams Lose The Business

And and those teams were working, and they were also disconnected from the outcomes they were driving, right? Because there were such large delays in the feedback cycles. And you know, to me, and I think to a lot of others, we just realized well, this was agility was always around establishing these, you know, kind of full flow-based systems for consuming customer feedback, innovating, and all of that. And that's not what was happening. So that's I think that that disconnect, I realized there's a an issue of scale as well, right? You know, part of it was an issue of an organization starting point. Those organizations that started with treating technology as a cost center obviously were just accustomed to throwing work over the fence, right? Um, whereas, of course, we saw this rise of digital native organizations that actually had technology and digital innovation at their core. And I noticed there was this big mismatch. And the way those organizations structure their entire business around agility. And they often didn't call it that, right? They didn't they these were just you know the tech companies, unicorns, tech giants, and so on. And yeah, I noticed these kind of two very different structures where uh where the the sort of large-scale tech giant structure was much more like the structure that I was accustomed to working in open source and startups and and scale-ups. So I think that's the that to me was a became an interesting problem to solve is how do we take these traditional organizations who were not structured or wired that way at the outset and move them to this kind of end-to-end more agile operating model.

Yeah, so often when they don't even want to, of course.

Right. Of course, yeah. I was gonna um kind of dig into that in a little bit more detail, make around the on the on the business side. So one of the things that we see a lot and we spend a lot of time on is really helping the business queue work up in a way for the technical teams to deliver. And after 20 plus years of agile delivery, the technical teams really understand how to get things out of the door relatively well. I still see a lot of challenges on the business side about queuing up, thinking about their work in terms of these rapid iterations rather than, you know, let me give you what you need to do in 2027 and just tell me when you've got it. There's still a kind of a lagging understanding of that, I think, in many businesses about how to really work with a digital sort of native uh technical capability.

Yeah, and I think that's that was I was seeing the same thing, right? And it was foreign to me having you know worked in that much more iterative way where there's end-to-end iteration, right? Where like your business strategy, your planning, it's it's it's all connected to the feedback you're getting very incrementally, because whenever you work in a complex and domain with malleable assets like software, uh you've you've got the benefit of very fast feedback. And that helps deal with you know complexity,

Why Software Cannot Be Planned

with growth, with uh changing market conditions. But I think what we've all seen, and then I think what you just shared, Dave, is is a lot of uh leaders have grown up in a very different world and kind of more of that manufacturing paradigm where you do very long-term planning and you know, then have that plan implemented, however you define it as whether it's product requirements documents or or it's scan charts or or some other kinds of plans. And that kind of at the core of the product operating model, and the book Project the Product is the notion, this all comes from the Kinevin framework, uh, that that works when you've got very sort of predictable things you're building. Like if you're building a data center or a bridge, you can optimize resources with very long-term planning, right? You're not gonna have the laws of physics change for you. You know, you have some uh you might have some complexity to deal with, such as access to electricity or or concrete or something else of that sort, or your supply chains, but that's all something that you can you can forecast and plan out and create contingencies for. But if you're in in an actual complex domain like software, where you know consumer behavior is driving the way that your product is being adopted and built, uh, you can't plan out for 12 months. Like who could plan out 12 months of of adoption of a completely new software product? You just you just it's it's there's just too much complexity involved. And whenever we get into those highly complex domains, that's where the product operating model thrives because that's where we have a fast feedback cycle where instead of trying to bacon all risks and contingencies up front, we actually allow the teams to adapt to that feedback and create this learning loop.

Yeah, it's quite often you see that the the business uh views the generation as the scarcity part of it. And they're they're like, if I don't get my feature now, then I'm never gonna get my feature. And so I'm gonna have to pack everything into this release. I'm gonna have to make sure that everything gets done and that it gets released out to the customers. And that feedback cycle just goes on forever. And they keep quite often I've seen organizations will just keep pushing things out, waiting for the next big thing that gets uh pushed out and never actually getting the feedback from the customer to see if the very first thing they're doing is even going in the right direction.

Yeah, and Peter, I think that's that's a whole other key dynamic. Um that's that's actually just been the case in organizations where their software delivery capacity is a limiting factor, right? Where if if the team's ability to deliver actually limits how quickly you can get feedback, um, you get that dynamic. And everyone's trying to get their feature into the next plan and so on, right? But what's happened is, well, first of all, our data and with the data behind the state of the project, the project industry report, I've got a whole long article on it on my Substack now, kind of detailing all our findings for anyone who's interested. Um but it actually shows that oftentimes that A, the teams are not the constraint. But over if once you

Scarcity Thinking Creates Feature Fights

overload them, once once you basically create plans that they can never, you know, they're they're they're locked into for multiple quarters, you actually create that capacity as the constraint. And so it I think this this creates the dysfunction that you're talking about on the business side, because of course, why wouldn't you, given that you feel like you might not get something that you think is is a uh massive benefit to your customers, why wouldn't you negotiate and fight for getting that into the next plan and the next plan and so on, the next iteration? And then, of course, the dysfunction on the technology teams is they get completely overloaded. So, and then what's fascinating is all of these dynamics are changing because with AI, we're now seeing that the constraint on actually building the software is is actually going away. That you know, coding used to be a fundamental constraint, right? The number of hands-on keyboards, which is why you had at leading technology organizations such massive numbers of technology staff, right? Banks have tens of thousands and and so on. So it's it's just fascinating now that all of this is changing very quickly. And I think that connectivity between the business and technology, if it doesn't adapt, you end up with even bigger problems.

As you're describing that, Mick, what I'm hearing or what I'm I'm thinking of is that that uh that uh constraint, which used to be hands-on keyboard, is going to push out to customers consuming features. Because if I can generate features as rapidly as effectively commoditized feature generation, it means, and it brings us straight to the

AI Moves The Bottleneck Downstream

outcomes part of your your latest book, which is if the consum consumption of these features on the customer side is really where we're pushing all of the attention, is okay, you're going to, as a consumer, you're going to get more and more and more features, which on paper means more and more value, with the assumption that each of those features creates value for all of the customers consuming them, which of course is definitely not true. We're very bad at that outcome measurement. So, can you talk a little bit about how you came to the outputs to outcomes and what you're seeing around that outcome exploration, what the definition is.

Yeah, and Dave, I do think I'm definitely seeing that as a very common constraint right now, that's possible for some organizations and teams to overproduce to the point where their customers, as you're pointing out, they can't consume that might change that quickly, right? Especially organizations who've really leveraged agents to basically take down backlogs, deliver new features. Uh, you can very easily get into that state now. Now, for other organizations, they're not getting into that state because you know they might not even have enough visibility, the ability to deploy that those features being built, but they're not being deployed, or they're gated on business approving those features and so on. So, what I realized is it's kind of the core thesis of output to outcome is that AI and agents will you know basically create nearly limitless outputs over time, right? So we'll be able to take any kinds of specifications, whether that's from the business, directly from customers, um, that you know, done more or less iteratively, and just deliver on those in in you know, you know, say 10x, maybe at some point 100x the velocity um than we could before. So our value streams will no longer be constrained on delivering outputs, but that doesn't mean that we're not constrained on delivering outcomes, because in the end, outputs are you know that they're they're they're not what customers are after, right? In the end, we want to deliver customer and employee and business outcomes. And so this is a I think we're you know we're still in a very much the realm of a complex system. So I what I put as the core now put to outcome is this mechanisms for understanding, well, where is that new constraint? If outputs were no longer the constraint, where is it? They've it you know, it could be for one value stream. It might be the ability for the customer to consume for another one, and it might be security reviews or something else. That's things are not even making to the customer any faster, even though they're produced much faster.

The Outcome Loop Explained

Um, so that that core mechanism in output outcomes is the outcome loop. So basically you've got your inputs, your strategy, your budgets, uh, you've got your outputs. Those are the artifacts that the teams and agents are producing, um, and all the activities that are being done by them. Uh, and then you've got your outcomes, your business and your your employee outcomes, your customer and employee outcomes, which together make business outcomes. And the constraint can be anywhere in that loop, right? So let's say you've got your customers can consume enough features, your constraint might be the budget. So you might need to put more budget in. And so the key thing is just formalizing and basically putting telemetry in on that loop for every value stream, and then applying the theory of constraints to say, well, where is our constraint? You know, maybe this outcome loop is actually still uh output constraint because we've not given the team enough token budget to actually experiment enough. Um or we've not trained them, or they've not adopted the you know, the bit the basically the AI solution that we've given them. Um or again, it might be budget, or it might be customer adoption. And so the key thing is to uh, first of all, make sure that we've created mechanisms that assume that outputs are no longer a fundamental constraint, because that's what the age of AI has done for knowledge work, and then actually uh make a key role of leadership for each value stream is understanding and applying the theory of constraints, and then helping that team, that value stream, uh remove that constraint and moving on to the next one.

How do you suggest organizations that go about measuring whether it's a good outcome or not? Because one of the things that we very commonly see in organizations that if you go and ask the business side, hey, prioritize your top outcome out of this list, they've got no idea. A lot of the time that they there's but the constraint can often be even in the very beginning, in the ideation. Like, how do I even know what outcome I'm aiming for? So do you talk about that in the book and how explored?

Yeah, and I think it's interesting because I think at a at a very high level, the businesses are generally well structured to understand these high-level outcomes like growth, profit, customer satisfaction, um, market share, right? Those are those things are uh I think they're well understood best practices for creating business strategies around those, right? So I think that the challenge becomes how those actually cascade down into the organization, where you actually need a different set of say leading indicators, right? Like a single feature or product

Finding Constraints With Telemetry

is not necessarily going to change the profitability of a company tomorrow. There's gonna be a lag, right? Um, and so that's really where the the notion of the second mechanism and output outcome. By the way, the first model and about uh an output to outcome, there are three. There's there's the product operating model, which is just this notion of value streams. So you struck around customer value rather than functions, organizational functions. Then the next one's the outcome loop we just talked about. And the the third one is the outcome tree, which is this cascade of taking that high-level strategy and those financial metrics that organizations tend to be very good at defining and making sure they cascade into the various products and platforms and value streams that the teams work on. And so this is where I think, as as you're saying, Peter, there's a challenge, right? You actually need to be able to take, let's say, that growth objective that you have for the organization that we're going to grow by X percent this year and cascade it down into each team. And if you can't, well, then you actually shouldn't be working on anything because you you don't you've not defined the outcome that you're after. And I think what's what's happened, of course, is so many organizations have had such a big disconnect for the start of this conversation between those high-level business outcomes um and what the teams are delivering, that they you just don't have it's like a disconnected outcome tree. So yeah, uh in output to outcome, there's very set of these these seven shifts of actually how you take your high-level planning and then create the structure. And I think that basically cascades outcomes and to make sure that that structure can move at the speed of AI, right? Because the interesting thing is I think that we're you know, when you when you're moving at that fast speed and you you know you're getting that much faster feedback, uh, you can't have all of that roll up to the top, you know, to the top of the organization, right? You actually need to empower uh the leaves of the organization, the leaves of the outcome tree with ownership of outcomes and make sure that that cascades into the overall company plan and strategy.

It's uh what what's um one of the things that I've realized when looking at the difference between output and outcome, outcomes is um output is kind of somewhat predictable. If it's a machine building widgets or bricks or whatever it is that they're building, that's something that you can look at, but it doesn't really have too much uncertainty with it. So it's really good for evaluating progress as long as though those outputs correlate tightly to outcomes. And I think one of the realizations is they don't correlate tightly to outcomes at all. And but the outcomes are much harder to measure as a measure of progress because they take time as a lag before you start seeing them, or it's just unclear which weather an outcome is going to be and how to achieve it. If you're trying to reduce the amount of time people spend on your call center calls, for example, that doesn't necessarily mean you're getting a positive outcome. It can just be that people are hanging up quicker, or they're not getting a response that gives them the support that they were looking for. So there's lots of complexity around understanding outcomes, which isn't there for understanding output.

That's right. I think what's happened is outputs are they are easy to measure, right? They're nice and intuitive. They're they're how many things we delivered or how many tickets we resolved, and so on, right? And by the way, the the idea is not that we stop measuring outputs. I think outputs are still key to measure, but it's it's it's what you said, Dave, right? It's all that matters is that correlation of the outputs to the outcomes, which really is you measure in terms of flow. So, like let's take that ticket example, how many we have we we deployed this new agentic system, and now we can decide, okay, we're gonna measure how many cases are resolved, but if we're not measuring that's that's an output, right? If we're not measuring whether you know some kind of outcome, like we had better customers with better retention rates, because the way we resolve those those cases, then then we're probably measuring the wrong the wrong thing. Or if we're just measuring how much AI we're applying by measuring the the tokens or the what adoption rates we have for that solution. Again, we're measuring even less meaningful outputs at that point. And so it really is all around, and I guess you know, to your point, this is harder for organizations and leaders who've just had the benefit of doing the easier thing, which is which is measuring outputs. Um but I think that's the that's that's the key role for leadership right now, right? Like is basically making sure you're can decompose the high-level outcomes that you're after for your organization into the various value streams you're in your organization, and then set up this correlation between increasing outputs and flow to the customer and whether we're delivering those outcomes. And if you're not, let's say because that's a great example, Dave. Um your your kind of call center solution was flawed and was just kind of resolving tickets without getting at the core issue for the customer. Um you then see a disconnect between the output and the outcome, and then you go fix that. So this is the fact, you know, I think that the role of leadership is just is is key here because AI is not going to solve that for the organization tomorrow. AI could help you find, let's, you know, let's say detect some of those things, but then we as human leaders still need to, you know, evolve the value streams in the outcome tree to much match the outcomes we're after. So and and really that becomes the specification for what for what AI should be doing for us, but it's a continuous iterative journey.

Yeah. Yep.

It was already broken, is part of the problem, is that uh they never decomposed the the strategy or the direction of like if they just set a target of, hey, we're gonna go make X million of dollars, and that's our growth number for the year. Now, how do we actually cascade that down into the organization and set outcomes for people to aim for? That that becomes far more critical than it ever was before. Once you introduce AI into the mix and it can start to generate at such a much higher rate.

That's right. Yeah, I agree, Peter. I think that's right, it's already broken, right? And so now we're just it's we're just moving a broken system, we're trying to move it faster. And and then we we basically what happens at that point, once you remove the thing that was slowing it down, which is some of the delivery and output pieces, you now see that you know that disconnect between strategy and and budgets and outcomes just becomes clear.

Outcome Trees And Strategy Cascade

Have you do you talk in the book at all about um how the people already in the systems, how their roles start to change as a consequence of this? I do.

In the book, I have these seven shifts, um which have to do with with you know those those three models that we talked about the product operating model, outcome loop, and outcome tree. And then there are these seven shifts. Like the first one is functions to flow to make sure that you're actually able to measure and your organization is structured end to end. So you can actually see end to end value delivery and measure it. The next Have to slop the substance. And this is again output metrics just become slot metrics at some point, right? Because if you're not delivering an outcome, you you're then overproducing. And that overproduction, just by definition, if it's not connected to a business outcome, it becomes slot. Um, and the last chapter, the hardest one to write, and the one that took me the longest to write, is uh is uh managers to makers, and it really is around, and it's really kind of both sides of it, it's both makers to managers and managers to makers, or this blending of roles and a change of leadership within the organization that's needed to bring about this change. And so I think that's that is definitely one of the most interesting things is how you know today's leaders need to become outcome owners. And kind of the more senior you are, the more you need to empower people below you to be actually able to move at the speed of AI and to create this clean outcome ownership structure. It's sort of similar to the way that sales organizations create a uh you know, a clean cascade of sort of uh regional ownership. Um and uh let's say you know, quota attainment, those sorts of things. So there's, I think there are various best practices in how to create these mutually exclusive and collectively exhaustive hierarchies, it just hasn't been done for technology, other than, of course, and the organizations that thrive, right? Like, you know, the Amazons and Microsoft of the world have been running this way for ages already. So that they've got this very clean technology management system in place. So again, I think this is you know, this is no longer optional, and it really does redefine the roles both on the technology and the business side of the organization, because to be a let's say a first-line engineering leader um is you know, without actually understanding and owning the outcomes for the team that you're leading, is it's no longer a sensible role. The team doesn't need that anymore, right? Um, it doesn't need someone who's just a people manager who does just escalations um and reporting, right? AI can do all that.

Yeah.

Role of leadership.

Can I can I explore that a little bit more? Because one of the things that I really liked in the introduction to the book, you talk about the different ages, this sort of technical revolutions, technology revolutions, and how specifically how that influenced management over these kind of cascading waves of techno technology advancement. And when you talk about the age of software to the age of AI, I'm really intrigued because a lot of our audience, a lot of ourselves, we're embedded in the leadership skills being built for the age of software. And the age of AI, you're just touching on this now, this managers to makers. But what is it you see as the, you know, the last 20 years, the primary focus of leadership has been and where it really has to shift in terms of maybe capabilities they have to build that they didn't have before, which I guess is part of that is around understanding outcomes. But there's there's so much more nuance to a lot of that, right?

So right. And I think for me, I I did get a chance to to research this at a at a pretty interesting level of of depth, um, in terms of these technological revolutions. And one of the most interesting things to me was um realizing that with each one of these revolutions, we we got this whole new set of management systems. And you know, the the first one was the industrial revolution was division of labor, right? But then the age of steam and railways that gave us the the organizational chart. All of a sudden, organizations were decentralized, and so you needed a a way of way of actually managing that and a new set of managerial mechanisms for it. And we still use orc charts, we still use division of labor, right? And we're going to continue to do that. And so I think what happened in the age of software and digital, we basically got agile and and product management. Um and we're gonna, I think those those remain as key managerial um methodologies and mechanisms. And so I think we've got those, but all this the the the yeah, and those those basically allowed us to build on how we looked at, let's say, lean manufacturing. So lean was of course the the innovation before that, um, and apply it to intangible assets like like software. And now what changes with that is where you know this this notion of scarcity of knowledge work output so that prioritization is you know the the core thing where you know everyone's fighting for the feature, and uh that that really has changed in AI native organizations who could actually rather than fighting for which feature goes first, you build them in parallel, you evaluate which one had the biggest impact on your customers. Um, so I think those principles of agile and product management still apply. Uh, and of course, those were also around, you know, all of these things were around delivering customer outcomes, right? Lean was around delivering quality cars or widgets as well. So these things were always around delivering outcomes. It's just that we now need a new set of mechanisms uh for leaders to adopt because it's no longer around scarcity of outputs, it's around identifying and and and removing the constraints elsewhere in the organization to be able to allow speed teams to move at the speed of AI.

Measuring Outcomes With Slow Feedback

And and and how do you over so if you're a Facebook, for example, then you don't have scarcity of feedback. You've got you've got millions and millions of customers. You can put a new feature out and within seconds evaluate whether that performs differently to what you had before. But for example, in B2B or in most other organizations, even though they may be digital through and through, it still takes time to get enough customers using new functionality in such a way that you really have data that shows that the outcome is that you're you're trying to achieve is being achieved. So is that mean does that mean that the sort of scarcity comes to getting feedback? And how do organizations handle that? Where they just don't have enough customers over a short enough period of time to get decent feedback on outcomes before another feature comes forward or before some other decision around which of these different features needs to go forward comes along. How do you address that or how have you seen that addressed?

Yeah, Dave, I think that's that that's that's I I think that's a very common occurrence, especially in in some industries. So I think that's that's another great point. And almost the flip side of what you said before, right? Like in some cases, you might be overproducing your customer for your customers. And so you might be, you know, constrained around how quickly you can get feedback from what you're producing. In other domains, uh, you might have a massive lag between when you produce something and when you get feedback, right? Um and so this is where we get back to like what is the constraint on the outcome loop? Um, like if I'm producing a new car and it's not going to be in market for another year and a half because it's waiting for a new, I don't know, electrical platform. Um, and the software for that that I'm writing for that car, I might not get feedback for two more years, right? So you've got these, you've got these very significant lag times built in. And so, you know, in some cases, uh, there'll just be a fundamental constraint, right? You you're not gonna get feedback for another six months. In some cases, you can, of course, uh bring in a portion of the customer base to get that feedback earlier. But the key thing is that you're always the whole point of the outcome loops, you're always managing to that constraint. So the majority of your team's efforts starts going to, okay, understanding how do we get that feedback as early as we can. Or in some cases, what we you know, what we see organizations do is actually say, well, we're not gonna get real user feedback, we're gonna have to simulate it, right? Um, automotive manufacturers have long had to you know simulate how cars drive before they can make physical prototypes because the lag times are so massive before they get, let's say, crash test result. So they they'll do, of course, a lot of virtual crash tests on simulations. So I think the key thinking there, the managerial thinking there is like, okay, that that's our constraint. Um, or our constraint is that you know, we our customers, the flip side, our custom like the point you made before, our constraint is that we can't, we're uh we can only we're limited how quickly customers can give us feedback where we can produce faster. Um, and then you really set up that value stream entirely around the constraint, and then you invest in addressing that constraint, whether that's through simulation, uh through creating subsets, internally adoption of the thing, and so on. So it's just again that kind of and it does get back to lean thinking, right? Um, it's just applying the theory of constraints to the outcome loop and investing your and your team's time there. And of course, accepting these fundamental constraints, right? You're doing drug delivery, it's you know, they might have years. So yeah, yeah.

Operating Models That Actually Stick

And building it into the uh fabric of the organization is a critical part because it has to be a part of the actual operating model. I know that's something else you talk about in the book there, because a lot of organizations don't necessarily think in terms of operating models, or they have they've been sold this by lots of big consultancies for a very long time, but uh actually changing the operating model of the organization and actually making it ingrained to how it works so that it survives past whichever leader is promoting it, leaving the organization. That's the sort of the critical piece of this.

Yeah, absolutely. And I think yeah, I think there's to your point, Peter, there's there's a bunch of fatigue on operating model changes and target operating models, and you know, consultant after consultant after strategic consultant coming in and redefining those. But I guess on the positive side, in terms of you know the how much how ground shaking AI is right now, I think a lot of leaders are saying, okay, well, what is that operating model that's going to survive the next few frontier model releases? Um and yeah, Peter, I think that obviously I guess the way I see it is when we look back the last 10, 20 years, um, the technology changes have been slower than than you know the the uh time uh leaders spend in organizations, right? Like I remember the last like you know, CIOs will spend between two and four years at organizations, something like that, right? Whenever time you look at. Um now the changes are moving so fast, people are realizing, okay, we need we can't we can't wait for that leader to get to the next leader. Like the operating model has to change now. So the technology is now shifting faster than leaders are entering and exiting the organization. And that's yeah, that that's creates a very different dynamic.

Yeah. Well, raises that whole question of sort of um ownership, objectives to ownership, I think was one of the I'm just looking at your um the taxonomy that you have there. But I'm just thinking that we've always had this leadership, this sort of single person who's providing the strategy for two to four years, keeps a sort of a true north of the organization. And then as the market shifts, you typically end up with a another person coming in that shifts their view, or that individual is moving with the time somewhat. But when things are changing in the order of months and quarters, not years, then it really either puts pressure on ownership being pushed into the organization so that aspects of your organization can really shift with the sort of market and how things are changing in the technology space, or that individual at the top has to be very much more driven, not by kind of a clear true north and objectives, but more ownership and pushing that ownership down. I think that's probably where you're talking about with the outcome tree about how do you get these concepts into the organization so you're not tied directly to that one individual having a handle on the objectives.

Yeah, and I think that's that's just a uh a fundamental dynamic now, which is that with you know, given how much velocity and speed we can get out of AI and agents, uh, the only way to move at that speed is by pushing that ownership down in the organization. Um, you can't centralize it. Now, of course, organizational structures are changing, right? That's not to say that you might not have leaders who can constantly are defining and redefining strategies like you have with NVIDIA, right? With where Jensen Klein's got you know 60 direct reports or or whatever the number is today, right? So you might have very sort of flat organizations, but still with teams owning the outcomes. Yeah. And the it's just kind of there's both less need for coordination, um, but I think the sort of the structure for delivering on the on those outcomes is much less dependent on that one leader, right? Whereas before, what we used to see is a new leader comes in, they put in place their whole, you know, the their playbook from their last company, re change and rewire everything. And that's not I don't think that makes sense anymore. There isn't that kind of playbook. You're not going to take you know your playbook from your last company. Um, they're there are now just these AI native playbooks, which all have to do around again this, I think, clean decomposition and cascade of outcomes based around outcome ownership um and uh and empowerment of teams. I I would argue that that never worked.

I've uh only seen that badly.

Three Takeaways And Closing

Well, on that note, I mean it's been a fascinating conversation, and uh I've really enjoyed it, uh Mick. Uh but at this point in our conversation, we normally wrap it up and leave our audience with uh three points to take away from the conversation. Uh and as our guest, I'll let you go first. What point would you like the audience to take away?

I think the main thing is that the these new organizational structures, these AI native structures, are all around empowerment and outcome ownership. Right. So to look for how you get that into your organization and and the steps, steps that you take to get there. And really those all those shifts in our path are really around helping you kind of navigate those those steps.

Awesome. Dave?

I'm going to there's a lot of really interesting talking points, and I feel like we can keep going for a while. But let me go back to right at the beginning, we talked about um that communication channel and cooperation between business and technology. And I think there's um it's a lot of it's driven through technology right now, still. I mean, the AI by definition is a technology-driven shift. Uh, and yet that bringing business to the table and really understanding what business needs in terms of outcomes, what business is looking at when they're looking at customer behavior, how the organization benefits, I think that's something that is um really not talked about enough, not fully understood. And I think we have to really recognize that business coming to the table and how they partner up with the change.

Awesome. I think uh the the point I would take away is the the importance of the the operating model and the changes in the roles as the it has to become a part of the fabric of the organization as it moves forward, but just even starting to think about that and uh how you're going to incorporate that into the the organization as it evolves. And I think a lot of organizations uh don't even think that way today. So to being able to take that step back and start to think about like uh where do we want to go? What does this model look like in the future and uh how do we operate? So awesome. Well, thank you everybody. Uh that uh was a wonderful conversation, and uh I'll leave it there for the day this uh week.

Thanks again, Peter. Thanks, Megan for joining us.

Thanks, I'm gonna be able to do that.