Output to Outcome: When Agents Outrun the Org Chart

Host Intro (Gene Kim)

All right. I met Dr. Mik Kersten, our next speaker, in 2016, and it's difficult to overstate just how much he's influenced my thinking. In fact, so much of The Unicorn Project book that came out in 2019 was based on his work. It was really a thought exercise in just imagining what a worst-case software architecture and process could be.

Mik started his career as a research scientist at Xerox PARC. He founded Tasktop out of his PhD research, and he's written over a million lines of open source code that are still in use today, which was acquired by Planview some years ago. During that time, he wrote Project to Product, which described a 20-year journey trying to understand what it takes to unlock developer productivity. And by the way, here's a trivia fact. He was inspired in 2000 at Xerox PARC when he saw a talk by Dr. Carliss Baldwin, whose daughter is actually in the room. She's a professor — a professor emeritus at the Harvard Business School — who studied the economic value of modularity and has shaped his thinking for decades after.

So for the last three years, he's been thinking deeply about how AI changes software delivery and business outcomes, and it's led to his new book called Output to Outcome, which Jeremy just mentioned. So here to talk about what he's learned and the advice that he'll give to you — which I think explains so much of what we've already heard today — is Mik.

Mik Kersten

Hi, everyone. It's really great to be here on this learning journey with you. And as Gene mentioned, for my whole career I've been fascinated about modularity — at first it was all around coding and technology architecture, and then applying that to organizations as I was growing a team as a founder and CEO. More recently, after Tasktop got acquired by Planview, as Chief Technology Officer at Planview, as we were building an agentic system and trying to figure out how that would affect the wiring of teams. And I'm now an independent advisor helping large organizations make this kind of transition, this rewiring, and move away from managing outputs — which is something I think a lot of us got very good at in our careers. Gene clearly mentioned I counted actually how many lines of code I wrote. That's definitely an output.

But it's managing outcomes, because I think the thing that you're hearing throughout this entire program is that the constraint is no longer how much we can produce, how much knowledge work or code we can build. It's now moved somewhere else in the organization.

The thesis behind Output to Outcome is that the theory of constraints always applies to any organization — it applies to any complex system. And so the question is, where are those new constraints? And I think they've actually shifted into the organization.

As part of the research in Output to Outcome, I actually studied what happened with constraints over the last five or so technological revolutions. And this has been a fascinating thing, because I think we've had some of the same principles and dynamics apply. So some of you may have seen this "spot the car, spot the horse" image — actually, raise your hand if you've seen it. I'm curious. Not as many people as I thought. But what you see on the right there is 113 years ago, and that's Madison Avenue. What we're seeing is that there's only one car visible in that entire scene. And if we look only 13 years later, there's only a single horse visible in that entire scene. So in a period of only 13 years, the massive consumer demand that drove the automotive industry — really the early days of the automotive industry — made this dramatic a change.

These technological revolutions that we're a part of can move very quickly, and I think we all obviously realize that in the age of AI. But what I thought was just so fascinating is how we actually got to the point where we could fill the entire street with cars. How did all that car manufacturing come to be? How did organizations switch so quickly from jobs that were all around helping maintain horses to building and maintaining automotive engines?

And so this is now in the 1930s, and what was happening — obviously in Detroit and elsewhere — is that car manufacturing was scaling really quickly. And there was this really revolutionary technology of electricity that helped make that happen. But what happened with electricity and factory lines and mass production was that some companies who previously used steam-powered drive belts — you can see one on the left, that's the Peerless Auto Company — took that electrical engine and replaced the steam engine with it, and everything was still connected to the drive belt. And on the right, you've got the Ford Motor Company, who did something completely different. They rewired the entire assembly line, redesigned the assembly line around that decentralization that electricity enabled.

What happened since then — in the 1930s, I should say — is that the company on the left actually became a brewery, so they didn't quite make it through that technological revolution. Whereas obviously the Ford Motor Company and the others who adopted this completely new operating model were the ones who thrived and who really won out in that creative disruption.

I think we heard Gene say this morning that this AI thing happened to us all at the same time, but I think we're seeing very different reactions from various companies, and we're seeing this massive gap in the gains that some companies are getting. Some companies on the frontier are getting these massive gains from AI, whereas others are adopting it. I don't think there's an issue of adoption, but we're absolutely seeing an issue of what outcomes it's driving for these organizations.

So, for example, for SaaS companies — some of the statistics, and you of course see these statistics all over the place — the revenue per employee of an AI-native company is roughly five times that of a SaaS company, because some of the software-as-a-service companies have been too slow to adapt their operating model. Some incumbent organizations, large enterprises, are in the same boat. And so I think we're seeing this really massive operating model gap.

Today I'll tell you some of the lessons I've learned about how you can shift out of your legacy operating models as quickly as possible to really get the benefits of agentic engineering and AI.

And before we do that, I'll just quickly run through what we've seen in the past technological revolutions, because I think there are some good guides here. I think we're really learning as an industry how to adopt AI amplification and engineering practices in other parts of our organization. But until the management systems that we use for that change, again, the gains just won't be there.

So we've seen these management systems — this is a look at each of these five technological evolutions where some constraint on production was automated. Water power automated manual labor, and then steam provided automation, and electricity, combustion, compute, and in the age of AI, of course, cognition — which was a constraint of knowledge work — is now no longer a constraint. Whenever this happens, some organizations really just completely recreate new operating models around not having that old constraint.

Those previous models — that's really where we got agile. We actually are still using each of the principles of the last ages. We still use division of labor and org charts. We still use workflow management, which came from scientific management and lean. But it's no longer enough to simply apply the principles of agile and traditional operating models, and even digital operating models, to really leverage the benefits of AI.

So I think now that the constraint has become organizational productivity — and outputs, knowledge work outputs, are not the constraint — we need an entirely new way and a new set of management mechanisms that are basically in the bucket of outcome management, to help organizations shift to driving more outcomes.

And this slide I've reused a million times, but it still applies. By the way, for anyone who's interested in the data behind this, I finally wrote a long Substack article describing all of this data and the other findings. But the bottom line is: at Planview, we ran the State of the Project to Product Industry Report and asked organizations to submit data from their value streams. And this was not just a typical survey — this was organizations submitting data collected from their Jira, GitHub, GitLab, ServiceNow, and other repositories. We took that data, analyzed it, and what we saw is that end to end, only 8% of the time of value delivery is spent on teams.

Now this data ends in 2024, so this is kind of pre-massive adoption of AI. But the problem is that those heavy upfront management processes and the heavy downstream team processes are still in place. This community, I think, has been tackling a lot of those. But the challenge is: if your organization is still stuck with those processes, you simply can't move at the speed of AI, because your teams are not the constraint.

And so at this stage, for organizations to move at the speed of AI, we need to move as quickly as possible to remove those constraints and make sure that you can actually deliver value — and that this 8% becomes more like 80%.

To help do that, the mechanism introduced in Output to Outcome is the outcome loop. And this is as simple as I could construct — a way of getting a feedback loop to apply the theory of constraints to value streams, to understand where things are slowing down, where things are blocking.

Inputs into any value stream — and of course, think of value streams as ways of delivering end-to-end value to an internal or external customer through your products and platforms — inputs are strategy and budgets. Those processes around those are well understood. You plan the outputs that you're building — those are all the artifacts and activities that teams and agents do. And then you've got outcomes: employee and customer outcomes that you're trying to deliver. Together, employee and customer outcomes make business outcomes, and really that's what we want to deliver and measure. Objectives connect us there — those can be your OKR systems or something similar — and then you need a feedback loop.

What's happening in most organizations right now is that those outputs are no longer the constraints. It's possible for teams to deliver 10X the output if they're leveraging these technologies effectively. And the big question is then: where is the constraint in that particular value stream? And do you have the telemetry to understand where that constraint is? Do you have the telemetry to understand that when the team delivers 10 times more features, that you actually got the satisfaction, the profitability, the growth, the adoption that you wanted — and then feeding that back into your budget at a sufficient pace? Because of course, these things can now run at 2X, 5X, 10X the pace.

So the whole idea is to define and formalize your outcome loop, to make the primary job of leadership or value stream owners to measure and understand the constraints in that outcome loop, and then to resolve and remove those constraints.

And when you do this, pretty amazing things can happen. So one of the case studies in Output to Outcome is Cognition. This is from Swyx. Cognition famously created Devin — they call it "an engineer in a box." They famously went from one million to 70 million of revenue in one year, at which point I got the case study from Swyx. And more recently, a few weeks ago, they announced they were actually at 900 million run rate.

What's so fascinating is actually how their outcome loop runs so much differently than a lot of the organizations that I work with. First of all, they're not constrained by writing code, which I think is fairly obvious. But what's fascinating is they will often have 10 rewrites of Devin done concurrently. So the amount of experimentation that enables is just completely different. If you're in that mode where you're not output-constrained, you can actually completely parallelize your outcome loop. You can try many different experiments all within an iteration.

Their iterations are much different — they still have iterations. We still need the work that agents build to actually be reviewed by humans and to really drive the outcomes that we want for our teams, our customers, and our market. So they have these weekly iterations where the founders review what's produced every single week. And then in that weekly loop, the new agents and new capabilities that look like they're going to make an impact — those are kept, and the others are discarded. What's fascinating about this is that they will often discard more code and more functionality, more agents than they keep, which is again completely counter to the way a lot of agile prioritization and product management prioritization processes work. Because when you're constantly prioritizing, it's based on a scarcity of what you can deliver. Here, you deliver in parallel and discard the things that don't clearly drive the outcomes. And of course, to do that, you need this much faster feedback loop when outputs are no longer the constraint.

To do this — of course, most organizations are not just a single outcome loop. Most organizations have multiple teams, multiple products, multiple SKUs, multiple business units, and so on. And so there's a second mechanism introduced in Output to Outcome called the outcome tree. This is the cascade of value streams and outcome loops all the way down to teams. And the teams can be human teams, humans and agents, or purely agentic teams. But the key thing is that at each level there is an outcome loop, and this actually becomes the primary structure of the organization.

One of the big pitfalls I saw in organizations applying the product operating model — and that shift from project to product — is that they would overlay value streams and the product structure on top of their existing organizational chart. And that can put you into this complete mess of ceremonies and approvals. You're basically running two different operating models. It's a good first step, but I would not keep that notion of a synthetic product model around for very long, because what happens in the outcome tree is that the entire structure is around providing empowerment and autonomy to the teams.

The only way you can move at the speed of AI is if teams are empowered to deliver outcomes with AI, and are not constrained by asking for permission or having these 10 dependencies on platforms and APIs and data and so on. And so the outcome tree becomes this empowerment structure. It's a mutually exclusive and collectively exhaustive structure, which means that you basically take your budget, your strategy, and your objectives, and they're decomposed, and you've got full human ownership at every level. With autonomous value streams that are composed of agents always rolling up to human leadership — inputs cascade down, outputs cascade up — and you've got a scalable structure that can actually move at the speed of AI.

Now of course, a lot of organizations apply this kind of structure. This is how Amazon single-threaded ownership works. But the key thing is you need this kind of empowerment structure to drive the independence of action that's needed by teams. Because again — and that's straight from Wiring the Winning Organization, of course — that's the only way that you can move at the speed of AI.

So in Output to Outcome I go over three models: the product operating model, which is a key foundation but no longer sufficient — that product operating model is really for when our org charts were full of humans, and now our org charts can have many more agents than humans — the outcome loop, and the outcome tree. And then these seven shifts.

I won't go into all seven shifts right now, but I'll just give you a flavor of some of these.

The first one is the shift from slop to substance. This is based on the fact that, first of all, AI generates slop sometimes, but second of all, if you don't have clear outcomes defined, AI will always deliver — but what is being delivered is not actually based on the strategy that you've defined and the outcomes that you want to drive for your customers, when that feedback loop is not established. So just by definition, you end up delivering slop, because the agents don't have enough direction about what they're building. And the challenge is: if all you're measuring are the things that are easy to measure — these output metrics of deploys and story points and PRs and tickets closed and so on — all you're measuring is activity. So you're not actually giving your teams or your agents the right kind of direction. These things are easy to count, but they're disconnected from value. And agents, of course, just amplify this problem.

The idea in Output to Outcome is to shift from this. First of all, you measure flow. We know flow and the flow metrics as a way of measuring end-to-end value delivery to a customer, but flow has to be connected to those outcomes. So how many more features that you delivered or better experiences that you improved — how those drove customer retention and adoption and so on. The idea is that you're still measuring flow, you're looking for constraints in that flow to find improvement — the optimization of your outcome loop — and all of this is in support of outcomes, with whatever the inputs were. And the inputs are really the cost profile of your staff, your tokens, and your hosting costs.

What's fascinating to me — this is a chart that just came out earlier this week, or at least I read it earlier this week, from Andreessen Horowitz — is that even though 69% of the S&P 500 are applying AI, only 2% of them are willing to disclose a metric they track over time, and it's only around 20% that actually track a reliable metric. So even though these things might seem obvious to this community — yes, of course you should track flow — this is actually not happening at scale in the industry. It is, of course, happening within frontier labs and AI-native organizations who know how to track what they're delivering and connect it to outcomes. But we're still in this problematic state, and I think that's one of the reasons we're seeing this massive gap between the elite performers and the laggards. And of course, that's a story this community has heard over and over again.

So another case study in Output to Outcome of an organization doing things differently: this is TUI Group, the world's largest end-to-end travel organization. They were quite disturbed by the fact that for a couple of years there, almost every single frontier lab had an example of how LLMs would disrupt travel and provide great experiences without involving a travel company. So they took that very seriously. But rather than just throwing all sorts of AI transformation at the organization, what they actually did is they first optimized the value stream. They measured their flow time — a very, I think, obvious metric of how long it takes to deliver value end to end. It was 200 days a couple of years ago. They brought that down to 15 days, and then they layered this entirely new approach to agentic engineering on top of that. They lean in very heavily on agents and all of this, but on top of an operating model that could support it. Because now these agents are not going to be waiting 200 days to deliver something — they're actually iterating much more quickly and able to get value to customers much more quickly.

The next shift is this chaos to cadence shift. This is really, I think, an artifact of the fact that so many agile transformations were layered on top of existing organizational ceremonies and reporting processes. So you had your quarterly business reviews, your PI planning, your scrum planning, your board prep pack and reporting, and so on — and all of these had different time boxes. You had quarterly reports and monthly, and the PI cadence might not be the same as the business reporting cadence. And none of this scales to the speed of AI. You can't actually be moving and inspecting and adapting and learning at the speed of AI if you've got these multiple cadences running.

So the unified cadence model is all about accepting the fact that for most of our organizations, there probably will be some kind of annual cycle — because investors, or public companies, those things are important. You'll have a quarterly cycle where, for example — as Gene mentioned, I was obviously interested in applying modularity — pretty much every quarter for the 15 years I was CEO of Tasktop, I refactored the organization. Which drove my leadership team crazy to do reorgs that often. But we had small improvements and we got better and better at not blowing up teams, but moving teams, for example.

So you really do some things on a quarterly cadence, and then you have these monthly and weekly and daily cadences — but the key thing is you have a single cadence. Just like the outcome tree becomes your single structure — there's not this matrix structure, this HR structure, this project structure, this product structure — it becomes one single structure. You create one single cadence that runs on a daily, weekly, monthly, quarterly heartbeat.

My guidance to organizations — and it's been amazing to see even public companies apply this very quickly — is: just throw out all of those different separate cadences for how technology and business and board planning happens, create a single unified cadence, and include every section. And Stevie gave me this fascinating point today, that agents can move at a speed none of us can keep up with. This is the structure that will actually allow us to work at the speed of agents, and to match up those two structures, or at least create a common cadence where we review the work of agents. But all of that, of course, in large organizations needs to flow all the way up to much longer-term planning processes.

The next shift is matrix to modularity. The idea is that we go away from these matrix structures that we created — where again, you've got product value streams, an HR structure, and different functional roles in organizations — which don't quite make sense when we're leveraging AI, because of course we can be much more cross-functional at that point. And we actually need that end-to-end cross-functional ownership for each value stream, into a modular structure that is really around ownership boundaries. The roles in this are people owning the end-to-end outcomes for value streams, the teams and agents supporting that, having a roadmap that cascades up, owning their budget, and of course having visibility into the business outcomes they're driving. They need to see what those business outcomes are, whether those are adoption or retention and so on. And so again, that tree becomes the organizational structure. The ownership structure becomes the organizational structure.

And I do think it should be refactored regularly. None of us know exactly today whether the world is going to be teams of — like we saw with Stevie — basically a person being a CEO of a fleet of agents, or whether we're going to have more hybrid teams, two-pizza teams or two-person teams. Those are things that we're all learning as a community. So I think those organizational changes need to be made. But again, we need this single structure and this modular structure where it becomes easy, let's say, to move teams between value streams, to create new platform teams, and so on.

And of course, this affects the role of leaders as well. The last chapter of Output to Outcome is managers to makers — which could also be called makers to managers, because I think these roles are just completely blurring. I spend a lot of time leading engineering teams. That role of simply taking orders and backlogs and delivering on them, I don't think makes much sense anymore. In the end, we need all leaders at every level to own end-to-end outcomes and to support and remove friction for the team delivering those outcomes. So all this coordination, reporting, and escalation that have been key to managerial roles — those are going away. That just becomes free and easy. But we still need leadership structures that deliver on human outcomes. The purpose of organizations is to deliver on human outcomes. So in the outcome tree, there are some principles, like humans always report to humans. And it becomes this control structure for how we get large fleets of agents to deliver on the collective outcomes of the organization.

So with that, you can find the book at outputtooutcome.org. You can follow me on Substack, or if you want to get in touch, email info@outputtooutcome.org. And the help I'm looking for is this: I'm seeing a lot of organizations apply these concepts from Output to Outcome, and for me the key thing is any friction or any constraints of applying them at scale — for example, implementing the outcome tree as an org structure. Anything you're learning on your journey on that front, I'd love to hear about and talk more about. So with that, thank you very much.

Gene Kim

Thank you, Mik. All those managerial coordination jobs are going away. Perfect. All right, thank you. Yet so motivated by the evidence presented today. Super interesting.