Jul 24, 2026

Move from outputs to outcomes with Dr. Mik Kersten

Description

In this Mission O/S Live, Rise8's Max Reele (VP of Delivery) sits down with Dr. Mik Kersten—Executive in Residence at Planview, creator of the Flow Framework and author of Project to Product and his new book Output to Outcome.

Through the Flow Framework and his work founding Tasktop, Mik helped shape Value Stream Management before turning to the operating-model shift: moving leaders from output-driven management to outcome-driven operating models, and harnessing AI in a way that keeps humans at the center. Max has brought that shift to life inside some of the most constrained delivery environments in the federal government.

They'll cover:

  • Why "we want outcomes" fails when funding, reporting, and structure still reward outputs
  • What value stream thinking reveals about where work stalls: between teams, not inside them
  • How AI changes the output-to-outcome equation, and how to tell real change from faster output theater
  • What human-centric AI adoption requires inside a government delivery environment

If you're leading a government software program and you're tired of a system that praises outcomes while it pays for output, this conversation is for you.

Dive Deeper

Mentioned in the Conversation‍‍‍

Related Content

‍

Transcript

Max Reele (00:21):

Hello everybody. I'm Max Reele, VP of delivery here at Rise eight. Excited to be here on Mission OS Live with Dr. Mik Kirsten. Mik is the creator of the Flow Framework, author of Project to Product, and his latest book just released Output to Outcome. You can find links to that material in whatever venue you're watching on. We'll post the links there to outputtoutcome.org. If you've ever struggled to explain the leadership of why shipping a ton of features didn't get you to the mission movement that you were expecting when you first put it on contract or put it into its strategy, we're speaking to the right expert today to help get you answers to those questions. Mik has spent an entire career managing digital transformations for large enterprise and he's seen it all. He certainly has seen the merge between where business outcomes and technical outcomes seem to be talking past each other on what progress really means.

(01:17):

So Mik, thanks for joining us here today on Mission OS Live. We're excited to get into a bunch of these topics with you.

Dr. Mik Kersten (01:24):

My pleasure, Max. Great to be here.

Max Reele (01:26):

Yeah. Mik, also by virtue of your new book, he's got a clear eyed take on how AI is influencing everything as it comes to creating a lot more content and how do we vector that content into the funnel of achieving real outcomes versus just much more outputs on our teams? So with that being kind of the placement for what we're going to get into, I thought the right through line to start with is kind of tactics to sense-making maybe. And so we've had quite a few people on Mission OS Live so far. And so you're coming in a batting order of real industry experts that have followed a good sequence for us to get to this material. We had Karen Martin talking about value stream mapping. We had Paul Rayner talking about domain-driven design, and we most recently had Simon Wordley on. So from your perspective, as we build out through VSM, DDD, worldly mapping, how do we get to where we are now?

(02:27):

Once a team can actually see their system, what are they supposed to do with it? Where does that break down in terms of the vision with the mission domain?

Dr. Mik Kersten (02:38):

Yeah, so I think just to rewind a little bit, I think we've been in terms of there's the aspect of seeing the system, seeing how value flows through the system, through things like worldly mapping, understanding how your system might be differentiated or how you'll evolve it to make sure that you're building the right things or focusing resources and investment in the right portions of the system. And I think we've got this very, at this stage, deep set of literature and best practices on that kind of systems thinking. I think systems thinking is often a challenge. I think it's important to keep investing in those. But I think what we're going through right now is just the biggest shift in how the systems that we build and that we deploy work that we've ever seen. Because so much of how we build these systems has been around what we produce.

(03:36):

The features that we add to them, the services, the APIs, the capabilities, the requirements we implement, the cyber physical components and all of that. And what I realized is happening, having spent a lot of time understanding, measuring, doing research around value streams, is that companies that have really optimized the flow of value through their value streams have been very good at really pushing the outputs, the value that they're creating, the features they're adding through those value streams. That's been the point. And of course, it's always been around driving some kind of mission, vision, outcome. Everything's been around that. But the constraint has been the outputs. Really what RFPs are about, what contracts are about, what value creation's about is how much you can build. And it dawned on me as working with my own teams, leveraging agents and AI, that all of a sudden those outputs were becoming for my own teams 10 times easier to build.

(04:45):

And that soon they would become a hundred times easier to build. And what does that mean? We've lived in our systems thinking, we've lived in this world where we're output constrained. And if all of a sudden outputs are free, our outputs are really cheap because AI can create them, what does that mean to our systems?

Max Reele (05:06):

Yeah,

Dr. Mik Kersten (05:07):

Go ahead, Max.

Max Reele (05:08):

Sorry. Yeah, I forgive the interruption. It seems like it's almost innate to our behavior as humans. It is the more measurable thing. And so I think this is what you wrestle with mostly in the book is sure, outputs are the more easily measured thing. How do we break through that and get to how we're measuring against the actual impact that we're achieving with the outputs produced?

Dr. Mik Kersten (05:33):

Yeah, exactly. Now again, I think just going back to the speakers that you've had on and really understanding systems and systems thinking, I think whenever we look at a system, every complex system has a constraint. Every complex system has a bottleneck. And basically, I think in my entire career of working on developer productivity, of working on value stream productivity, that constraint has been how much we can build. That's why prioritization's been so important. That's why understanding core versus context versus differentiation versus which services we build on versus which platforms we build ourselves. Those have been key decisions. And now again, I realized, okay,

(06:21):

With my own teams, it was not so much now do we build on this platform? We can rebuild the platform very quickly all of a sudden. All of a sudden, all those dependencies that we were struggling with, we can now recreate the whole system ourselves, something that would've taken years, can now happen in months. Remember some colleagues at AWS, they were struggling with one of their core components that the top engineers were saying would take years to rebuild, but somehow they got rebuilt in three weeks with AI. So I think we have to completely change the way we inspect systems and the way that we measure systems to assume again that A, the theory of constraints will still apply. We'll still be constrained on delivering value somewhere, but that constraint will no longer be how quickly we can write code, how quickly we can add capabilities or APIs or data layers to the system.

(07:13):

So I think the key thing is the theory of constraints, which is really behind a lot of systems thinking and lean thinking still applies, but the constraint has now moved somewhere else.

Max Reele (07:24):

Yeah, fantastic. So let's dig into that on where the motion of this constraint has kind of gone in the process. You talk a lot in the book too, specifically around there needs to be a single product leader, a single owner over each slice of the value stream that's making that decision about where is this constraint? And then how do we weigh the build versus buy decision relative to the value stream that's being analyzed here? How do you think now, you mentioned it earlier, we could potentially rebuild this platform much more quickly than we could, or maybe makes more business sense than potentially paying for it. How do you think that assignment of a single owner over each individual value stream plays out? And how does their decision-making on build versus buy evolve now that the teams driving the productivity underneath can be a lot more productive?

Dr. Mik Kersten (08:21):

Yeah. And so I think in the end, we need these mental models and tools to help address these questions. These are complex questions like buy versus build is AI doesn't immediately simplify buy versus build. I kind of trivialized it in my last answer, but there's certain things you definitely don't want to rebuild. There's certain core services and then open source packages or cloud services that you're not going to want to rebuild. So I think it's a great question to look at is the buy versus build is always a complex question. And sometimes it means there's a one-way door, you end up building something you shouldn't have built, or it seems like agents and AI made it easier to build, but it really wasn't and so on. And so in the end, we actually needed mechanisms for making those decisions. We need a leadership structure that supports effective and fast decision making.

(09:09):

And then I think we need to be able to learn and inspect the effect of the decision-making. So I would put to outcome, this new book that's available now. In output to outcome, I introduce the core concept of an outcome loop. So an outcome loop is this feedback loop where you've got inputs, you've got your strategy, your budgets, this is really the work you're undertaking. You've got your outputs, that's the stuff we're used to optimizing. Those are all the activities and artifacts that we build as part of building software, building value. And then you've got outcomes, and those are your customer outcomes as well as your employee outcomes. And together, those make your organizationally your business outcomes. And so the key thing is to actually apply, and this is really the core of output outcome, to apply the theory of constraints to the outcome loop.

(09:57):

To say, okay, we're now getting, AI is helping us amplify. We can build twice as many features. What's our constraint? Perhaps our constraint is actually somewhere in the planning process, somewhere in the kind of client communication process. Perhaps it's actually in getting feedback from the deployment because the software can be deployed into the field effectively. And now that's a constraint. So maybe we have to think about simulating deployments to really accelerate. So the key thing is understanding what the outcome loop is. And really each value stream, each team has an outcome loop. And then seeing how AI amplification accelerates the outcome loop. Or maybe you're not ready for AI amplification. Maybe you still need some additional automation because that deployment, the outcome loop is not connected end-to-end. In that case, you've got a disconnect outcome loop. I know colleagues in the. I know some kind of famous disconnects with colleagues who worked in the US Air Force where the last step of the outcome loop was giving someone a CD.

(11:01):

That's not for them to install the software with. That's not a fully connected outcome loop, but you can still apply the three constraints too and say, okay, we just have to do more simulation because that last step is actually a physical software install process. So our outcome loop is going to change this way and we'll still have to manage that last constraint of those last manual steps. But once you've got the outcome loop, I think the key thing is that there's, and I'll put that in proof, is that each outcome loop needs to have completely dedicated leadership and completely dedicated ownership. So the team is only working on that outcome loop. The team is managing the agents supporting the outcome loop. And the leader is responsible for basically excelling the outcome loop by eliminating constraints. Yeah.

Max Reele (11:52):

I love the way that you painted it in the book. I'm glad that you pushed us directly into the conversation on the outcomes loops and how we measure them. And even in your example about pushing CDs at the end of the value stream for your Air Force customers, man, that one hits home a little bit too hard.

Dr. Mik Kersten (12:05):

Sorry if that

Max Reele (12:06):

Hits home. But that's okay. I

Dr. Mik Kersten (12:07):

Just could not believe it when I heard it. So that one's

Max Reele (12:09):

Not really sad. Yeah, it's happening all over the place. I'm sure there's many listeners on right now that are smiling and crying inside. Because of our widest network here for Rise8 in particular and with the Mission OS Live series is in gov tech. And so delivering in a lot of high compliance federal spaces. And that means high compliance in terms of policy as well as high compliance in terms of tech and tech choices that can get used and tech integrations that can be made. So relative to the outcome loop and re-centering on where the constraint is moving within the value stream and within the outcome loop, it sounds like what you're calling for, and forgive me for leading the witness, is there needs to be a lot more involvement that's real time, dare I say, continuous governance to follow the high productivity that's happening at the engineering levels.

(12:58):

Do you have any suggestions for how we can engage with stakeholders in those governance bodies, whether it be cybersecurity compliance, perhaps it's a policy around use of data? How do we bring them into the outcome loop so that they can open their eyes to recognizing that they don't get their own review plateau of the outputs to determine something's value, but they have to actually be involved in the outcome loop to make sure that the outcome is progressing continuously?

Dr. Mik Kersten (13:27):

Right. Yeah. So I'll address this with introducing this kind of second mechanism, the second mental model of output to outcome, which is the outcome tree. So in the end, we're building complex systems, we have complex contracts, we have complex missions we want to deliver on, and it takes more than one outcome loop. It takes more than one leader. It takes more than one team to do all that. And so we need a structure that will actually allow us to scale that kind of delivery. And output the outcome says this needs to be this cascading tree structure called the outcome tree where just imagine it as kind of like a tree with nodes going down. The teams are generally the leaves of the tree. They're the ones delivering value either just purely through humans or hybrid human agents. In some cases you can have autonomous value streams, which are purely agents.

(14:16):

But the key thing is you've got human leadership at each level of the tree. And that team has full ownership of what they're doing. And actually in my research around output.com, I realized the old way of working is having teams own outputs. They're just getting the requirements and they're delivering the outputs. And then you check how the outputs work and then someone in more senior leadership, this meets the client's needs and so on. I don't think that scales to the pace and speed of AI. I think with AI, the teams need to own outcomes.

(14:50):

And teams owning outcomes is not an entirely new concept. The challenge is, it's the exception, not the norm in many organizations. And I really think of the outcome tree as an ownership structure. So again, at each stage you've got leaders who are removing those impediments. Those leaders are also understanding what the strategy, the vision, the mission is, helping the teams translate that into outcome. Giving the team, the team should, in my view, have full autonomy on the outputs they built to deliver on the outcomes.

(15:23):

Now that's back to your point, Max, that has to have constraints around things like governance. The team can't have autonomy on the security posture of the software. They can't decide, okay, well, we're not going to focus on security for the next six months. That just doesn't work. So you've got non-negotiable compliance at each level and governance as well. You've got certain ways that you need to build things. You've got certain kind of IL levels that the software needs to meet, which then imply you can only build on these kinds of components, not those. You can't rebuild everything with AI because you're at IL4 and can only use these specific cloud services or something of that sort.

(16:04):

But the real shift without what outcomes say is the team's responsible for all of that. So if they've got ownership of outcomes, they have ownership of governance as well. And they've got ownership, again, for their value stream, for what they're building. They've got end-to-end ownership of delivering outcomes, which means that the teams are just naturally more cross-functional teams. Because you then need someone on the team who's an expert in governance. And maybe they're liaising with someone who's actually working on the policies and processes and so on. And it's not dissimilar to the team of team Stanley McCrystal type things where there's outcome ownership at the team level. The teams are very cross-functional, but the only way you can truly scale that is actually with a hierarchy. And this is an interesting thing. I think in the military, and it makes it a little odd. I actually thought it was a bit odd that my research took me there, that the ideal structure is actually a hierarchy.

(17:06):

I think that team of teams thing says it can't be just a pure command and control hierarchy. You're not just always pushing requirements down. You're pushing ownership and outcome ownership down, but you're doing that through a hierarchy so that things cascade properly up as well. And to do that, you need these very cross-functional teams. You'll always have some networks. You'll always have dependencies between this team and that team, this service and that service and so on. But if you're accelerating for velocity and outcome ownership and mission outcomes, you actually need to have this as clean a hierarchy as possible with as few dependencies as possible, as much independence of action on the teams. Because of course you're working in a secure environment and these sorts of things with significant governance and compliance. You actually need governance and compliance ownership on the teams.

Max Reele (17:55):

Yeah, fantastic, Nick. I love where you're taking this. We have been fighting hard with our clients on working to fuse these principles of a generative culture and kind of meritocracy around ideas and around technical solutions with what is this hierarchical potentially decentralized execution that comes from a centralized command point. And so executing some sort of mission command principles along with a generative culture is a really hard mashup because there are people who crave structure and hierarchies. And then there are people who crave freedom of though and best ideas, meritocracy structures. It's different. Yeah.

Dr. Mik Kersten (18:41):

And by the way, the functions, there's these seven shift chapters. I mentioned the models, by the way, just the three models output to outcome are the three core models, product operate model, which is all the value stream stuff that's already understood. I just went to more depth in it. The outcome loop, which we talked about and the outcome tree. But then the first shift is the shift from functions to flow, which is how you structure an organization. And I spent a lot of time in that chapter talking about the role of hierarchy. A lot of people think we need these very generative structures, as you said, Max. But if you take out hierarchy, things just do not scale properly. You look at organizations that are elite tech organizations, they have a very strong hierarchy. I had a good conversation about this with someone who was actually working with Joe Selling McCrystal.

(19:33):

That book doesn't talk much about the command control hierarchy because it's so focused on that empowerment and the networks and so on. But all of that worked with. The magical thing about that is in terms of my takeaway from that conversation was that it worked within a very well-defined hierarchy.

(19:54):

So the question is not do you need a hierarchy? The question is what hierarchy is it? And in the way that we deliver value through software, through technology and so on, I think that hierarchy needs to be around the structure of the value that we build. So it's really a value stream hierarchy where the key component is ownership and empowerment for the teams to deliver outcomes. So it's a different hierarchy than the org charts maybe that people typically create. But you actually end up with a strong discipline hierarchy built on empowerment so that teams have independent action.

Max Reele (20:31):

Yeah, fantastic. I'd like to click in a little bit deeper on that actually. You kind of highlight in the book, I mean, you've talked about the mental models at the top three, but as you get a bit deeper, you highlight in the book that we're past the point of anybody being able to evaluate things from the sidelines. Everybody has to have hands-on, even if they are in a governance role. Can we unpack that a little bit, dig into that? In my mind that you're talking about the entire team owning their outcomes, meaning that the entire team is mission aligned and they have to bring people in that may have governance equities, they have compliance equities and policy equities, but they have to also be on the team with the mission alignment of the team.

Dr. Mik Kersten (21:14):

Yeah. And this is, I think the challenge is that if you look at the traditional pace of building things, and if we look at the cascade of a very complex system that has to be delivered, by the time you get to the teams, maybe we've gone through a few levels of hierarchy and the teams become the further down you go, the more disconnected the teams might feel from the mission and the outcome. And it's partly because they're building things, they're building these capabilities, but there's just this really big delay on how long it takes for those capabilities to turn into the actual outcome. And what's happening with AI, with our ability to simulate environments much more easily and so on, is that it's now possible to establish much faster feedback loops, which means if the team is going to be able to move much faster, they have to be directly connected to the mission because in the end, you cannot always, and this is the whole point of the independence of action.

(22:13):

If the team has to go and ask, okay, we built this. Did this deliver on the mission? Or their leader or something, and then there's a delay with the client and so on, they actually are not able to move at the pace that they can move enabled with AI. If the team has direct connectivity to their portion of the mission, and of course it's not the entire mission because this thing cascades down. It gets broken out into the different products and services and applications and capabilities and APIs and data platforms that they're building. The team has to have, if you're going to be outcome aligned, the team has to know exactly what portion of the mission they're delivering on, what the objectives are so that they're responsible for that mission. And then we can get into the more detailed mechanisms of the book, which has an outcome roadmap, which basically means these are the things everything we deliver is actually connected to the outcome and the mission in this way.

(23:06):

So there's direct line connectivity, and then they have the freedom basically to deliver on that. So it is a change because it means, and this gets back to that empowerment, the generative culture thing. If you really want that, you have to give the team their portion of the mission to deliver on. And those portions have to be cleanly separated.Because

Max Reele (23:29):

You can

Dr. Mik Kersten (23:29):

Have this team stepping on that team's toes. They won't have full ownership. They'll have to be meeting every three hours to understand who's doing what. And so it's that clear separation of the mission and the cascade down of the mission through whatever side of hierarchy you need to deliver on the mission. That's so key to give the teams that outcome orientation and ownership.

Max Reele (23:48):

Yeah, that sounds exactly right with what we try and work on most notably within our Mission OS model where our outcomes orientation is our way of thinking. So you tying everything to the outcomes roadmap that is agreed upon for everybody involved in terms of here are the outcomes we're really trying to achieve is exactly what we subscribe to as well and why your book has been so interesting for us to have a personal reflection and a cultural reflection as a company on how we execute this. Even our listeners, this seems to be really resonating. We had a comment in a chat about how ownership and incentive structures are more important than ever, especially when you start having teams responsible for their own outcomes.

Dr. Mik Kersten (24:32):

Yeah. That one, by the way, so I think that's an interesting problem that I just decided to tackle head on in the book. So there's a chapter called Objectives to Ownership.

Max Reele (24:41):

There's

Dr. Mik Kersten (24:42):

These seven shifts in the book, that's one of them. And that one actually does talk about incentive structure because I've seen a lot of organizations create these OKRs or OGSMs or these kind of well-intentioned and well-thought-out objectives and tracking models. And if that structure, that objective structure, which really is around, those tend to be outcomes naturally. The way people, you do a good job to your OKRs or OGSMs, they are about mission outcomes in the end. If that structure is different than the incentive structure, guess which one wins? And that's back to Dustin Warner's comment. And so I think the key work and the guidance and mechanisms proposed in the outcomes, you have to make those one structure. Otherwise, you'll be wondering why the team didn't deliver on objectives, but you've just misaligned the objectives of leaderships because basically the team will always get the objectives in that structure.

(25:44):

But if the leadership incentive structure's not aligned to that or slightly skewed from it, you're just introducing friction to the system.

Max Reele (25:54):

Yeah, absolutely. I like that you're making reference to your seven shifts as well. And in fact, I think we probably don't give you enough airtime to talk about the last of them and how we shift from managers to makers across the board. We have just about four minutes left before the referee announces how much stoppage time there is. And so please, if you don't mind, talk to us a little bit about managers to makers and what that does for us in terms of the traditional management structure and how we oversee what's going on across all the different teams that are operating autonomously against their own outcomes.

Dr. Mik Kersten (26:33):

Yeah. Yeah. And Max, that was for me the trickiest. That chapter took me longer, twice as long to write as any other chapter in the book because I think we're still seeing the changing roles of management evolving and they're continuing to evolve with AI capabilities that we're getting. So I think some things are obvious, like manual reporting and all those sorts of things, all those ceremonies that can be taken care of through AI much easily, but that's just information flow through organizations. So those things get much easier. This chapter, I just went back and forth. Is it makers to managers or managers to makers? Because makers, people building things like hands on keyboard, the role I had for over a decade, which I love, by the way, I love building outputs. It was really fun.

(27:21):

In terms of my time doing open source coding, you no longer have, that role's gone of just writing code or just building systems through AI because it's so much easier to do it now. You're naturally having to coordinate much more with other people because you're looking at, did this deliver on the mission or not? It becomes more of this product management managerial role, every individual contributor. At the same rate, every manager can now prototype things and test things out and test out ideas. And so managers are actually becoming empowered to become makers as well through AI. And so I think the main thing that we're seeing is the blending of the two roles. We're now going to have individual contributors who are managing fleets of agents and having these more product management-like in coordination roles and discussing roadmaps and truly owning outcomes because each person can deliver and own so much more.

(28:20):

Whereas managers now, we're going to be able to leverage the capabilities of AI for understanding how to evolve those roadmaps, how to really think outside the box on these missions and dedicate more time to the longer term strategic thinking. But I think the thing that doesn't change is, again, these leadership and ownership structures. We need to change what underlies that structure. It needs to be this empowerment structure so that we can leverage all of that amplification. But I think those leadership structures and the way that we structure the organization, the way we incentivize leaders that hire and cascade are as important as ever.

Max Reele (28:53):

Yeah, that makes perfect sense. I know we're coming up close on time here, but we haven't got a chance to really talk about your true motivation for writing the book. If you can, share with us and the whole audience, what was it that made this a must-write book for you right now relative to all the work that you've been doing and all the research you've seen throughout a career?

Dr. Mik Kersten (29:17):

Yeah, the main motivation was I was just seeing, it's a little bit similar to the motivation of project to product. My motivation is not royalties. As with product to product, all the royalties are being donated to a scholarship supporting women in underrepresented groups in tech and AI. And it's been great to see what's happening with the project and product scholarship. So this will add on in a nice way, I think. But the motivation was I was seeing some companies who had structured themselves around value streams, really leveraging AI at five, 10X the rate of organizations that hadn't. And this was two, three years ago. And that created for me the significant concern given that I think we're What's going to happen in terms of the evolving capabilities of frontier models and agents is that we would have some companies building value a hundred times others, which means we end up with the set of elite organizations, and you can think of those as federal government, the entire supply chain, all of the commercial organizations, all of those sorts of things, a very small number of them getting very good and very fast, and everyone else being dependent on them.

(30:31):

And I think that's not the kind of world we want in terms of driving innovation, driving diverse economy, driving national security in the right ways, that kind of concentration on very few organizations being very good at this is not a healthy thing for the world. So my goal was to help establish organizations, incumbents and others, adopt these practices that are many of which are already in play at the tech and AI elites and frontier labs and hyperscalers as quickly as possible to get the same kind of benefits to their missions as the frontier labs are seeing for evolving their models.

Max Reele (31:10):

Yeah, it makes perfect sense. I love the content of the book. I thought it was a fantastic read. I thought it applied wholly to what we do in gov tech, working in really high compliance industries and working off of what are generally really specific contracts with contract requirements versus outcomes we're trying to get to and outcomes-based contracting and outcomes-based relationships between federal agencies and the services companies that are building great software for them. And so as a community, I think this book is valuable to us and it's something that we can all lean into. We're at time now. Anybody who left questions, please know that we will get a response to all the questions back out to you. So stay tuned wherever it is that you're following this, either on YouTube or LinkedIn, and we'll make sure that we get answers to your questions back out to you.

(31:59):

Mik, can't thank you enough for joining us here on Mission OS Live and talking in depth about output to outcome. And we'll have the link for anybody who wants to click in even deeper on these topics by reaching out to Mik and his team or by getting the book and diving in yourself. And so we look forward to hearing from everybody. The last plug that I'll make is the timing of this has been really fantastic, Mik, because we have a conference coming up at the end of August, which is Prodacity, August 25th to 27th. It's in Nashville, Tennessee, and it's a gathering of all the change makers in the GovTech community who really want to start driving towards outcomes orientation and delivering outcomes that really push the mission forward with every bit of execution that we put on contract. So excited to talk to that community and have them use this as a launching point for those discussions.

(32:53):

For anybody who has anything else lingering, please drop a question and we'll make sure that it gets responded to. I appreciate everybody coming and joining us today, and a special thanks to Dr. Mik Kirsten for joining us here on Mission OS Live.

Dr. Mik Kersten (33:06):

Thanks so much, Max. Thanks for having me everyone.

‍