Dr. Mik Kersten

Hello, everyone. My name is Mik, and for the majority of my career, I've been on this kind of manic quest to figure out a 10X increase in productivity and how software is built. I got this bug back when I was working at Xerox PARC, the Xerox Palo Alto Research Center, which brought us things that Gene likes, like functional programming languages and some other really key concepts like the mouse and graphical user interfaces. And I was working on a team whose goal was actually to find that 10X increase in programming languages by introducing functional concepts into object-oriented programming. This is why I get pretty excited when Gene starts to educate our community on things like passing by reference and passing by value, even though at first I thought that was kind of crazy to be going to that level of detail. But what's been so fascinating to me is that the things that we've learned in building software and the technical practices around building software are actually starting to permeate how we think about software delivery and technology and innovation at a business level. And this is why I think things like the five ideals in the Unicorn Project are such key tools for changing how we think about software delivery.

So I actually continued this quest. From PARC, I went to a company called Intentional Software and worked for Charles Simonyi, the former chief architect of Microsoft, on intentional programming. We tried to take that route. It didn't quite work. And I then decided to try all these different 10X experiments by doing a PhD at the University of British Columbia. And I didn't want to take too long to do this PhD. I had no aspirations to be an academic. So I asked my supervisor, "How can I get this thing done in three years?" And I hadn't done my master's yet, so it was quite rushed. And she said, "Well, the only real way that you can get through this that quickly is to do something that's a bit rare, which is to measure the outcomes of your experiments. You have all these weird, interesting ideas on how we can make developers more productive. If we can find a way to measure whether those are making improvements or not, maybe we can get you out of school faster and get you graduated faster." So Gail and I then spent all this time trying to figure out how the heck you measure developer productivity. And I think a lot of us have read the ways that you shouldn't do it in books like "Accelerate," which show us the fallacies of counting lines of code and function pointers and those kinds of things. And we came up with this novel measure. We called it the edit ratio. It actually allowed me to evaluate these experiments with professional developers, and it did get me out in 3.3 years. So through this, I learned the power of actually being able to measure all these great ideas that we have, figure out which ones work and which ones don't. And you'll recall yesterday, Gene mentioned these Kuhnian moments, these paradigm shifts. One thing that's been so fascinating to me is that each one of them has been underpinned by some major innovation in how we measure, whether that's telescopes or microscopes or tunneling electron microscopes. In order to really improve with the scientific method, you need to measure. And when we find new ways to measure, we find entirely new ways to innovate and to drive technology. So I'd like you to consider for a second, in terms of your practices, your organizations, your own work, how do you measure what you do? How do you measure how successful your organization is? And what is it that you measure? What are those core metrics? Are people seeing them differently? Are people seeing the same way?

I went on this quest, the one that led to the book project, the product that I'll be telling you about today. And three or four years ago, I started doing all these customer meetings, and for the first time with more senior IT executives, as organizations were getting more interested in turning into software innovators. And I kept asking these questions, "So what do you measure? How do you measure value?" And I would get, bizarrely, these blank stares from IT executives who are spending into the millions or hundreds of millions and sometimes billions on their software portfolios, their growing software portfolios. I would ask this question all the time, where is your bottleneck? Because of course, if you've got a large production process, even if it's a creative production process, we know from the last 100 years of manufacturing or so that understanding where your bottleneck is should drive all of your investment, all of your thinking as a leader in terms of how you're removing impediments and where you're investing. And again, every single time I asked this question, I would get blank stares back. So you try this when you get back to your organizations. Ask the most senior leaders, where is the bottleneck in your portfolio? And again, you'll get these oddly blank answers to something that should be the most obvious question. You'll get all sorts of, well, I would get all sorts of answers about, well, we have to invest in more developers. We think we've got a problem over here. Mainframe's holding us back, and so on.

But once you start to dig in and asking more of the whys, you'll see that there isn't a clear understanding of where the bottleneck is because there's no clear understanding of what it's a bottleneck to. What are we trying to optimize for? Are we trying to go from 50 to 5,000 builds a day? Are we trying to get the number of story points that we're finishing 100 times higher? I remember when I first told my CFO about story points five years ago, he looked at me like I was crazy and I think briefly regretted joining Tasktop because he'd actually come from a lean manufacturing background, and they had such a clear notion of what's produced, what costs are, what value is in those organizations. So I realized that something was really wrong. And even a couple of years back, Nicole Forsgren and I said, okay, we've got our ways of measuring that we studied for our PhDs. Let's put our heads together. Let's come up with some principles around DevOps metrics. We put this article in ACM Queue on the fact that your biggest mistake might be collecting the wrong data. Nicole and Dora had all this really important survey data. We realized that what was actually happening in a lot of companies were people were taking that survey data and those metrics and completely misapplying them. In the same way as I was seeing organizations misapply metrics they were getting out of tools, right? Misapplying basically user story open to user story close in Jira to be representative of customer value and customer delivery. So I realized that there's something very core here that by not being able to measure and not having a common representation of how we measure value. Organizations were going astray with the best of intentions. And so I'll recount one of, I think, to me, the most poignant stories of project to product. A top 25 bank on

its third transformation with a billion-dollar budget. So the costs here are extremely large and extremely clear. Everyone's bought in. Executives, the board, the CEO want to transform. They want to bring all these great things that we've learned in the last 20 years of Agile and the last five or so years, 10 years of DevOps to the organization to make them be innovative. Again, multibillion- dollar budget overall, billion-dollar transformation budget. And then I got to learn how they're measuring this transformation and the success of this transformation. And they're doing it with this project management layer, between what the business sees and how they spend those costs, and how they decide whether things are on track in this transformation or not, and what IT is doing. And two years later, I learned how to do these sets of interviews for my PhD. I do another set of interviews with executives and engineering leaders and IT leaders in this organization, asking them how this transformation went. And every single person said, "The transformation's been called successful by all its measures. We're delivering a lot less to the business than we were before." And people on the business side said they did a whole bunch of things, IT changed for itself, and now we feel like we're getting a whole lot less than we were before. So I realized, okay, maybe there really is a fundamental measurement problem here if this whole thing was deemed a success and there's less value being delivered than there was before. So I realized this is where I learned the concept of watermelon projects, where everything is green on the outside for a year or two, and then, of course, comes time to ship, time to complete the project, and it turns out it was all red on the inside. So

there's just something fundamentally wrong, I learned, with this lens of tracking activities and actually only tracking costs. That these proxy metrics for transformations actually will destroy them by not giving you any sense when things are going sideways.

Gene told that Nokia story this morning, same thing. Proxy metrics measuring how many people are trained on Agile, how many people are using the tool chain. That completely led the company astray and results in a whole bunch of bad decisions. Because where they should've been investing was in the technical debt, in the architecture of their core platforms of the SIM and operating systems. So we're now getting to the point that my sense is if we don't come up with a common set of metrics, with a common language, and a common way of measuring productivity and value in software delivery, rather than, again, falling back to these project plans and cost centers, more and more companies' stock valuations will start looking like this. We've seen early warnings in retail. You've got a company there on the left, their stock price changed over the course of the decade. They've become so good at measuring and managing to value, and at structuring, becoming, as Gene pointed out, this dynamic learning organization that's able to align their software architecture through microservices, their organizational structure through two-pizza teams, and their product value streams, the way they innovate for their customers and create a disruption machine. Invest heavily in their core, producing things like AWS. Then you've got these other companies who are

just simply being disrupted by that because they're trying to do the same things, but they're not succeeding. Some are succeeding more than others, the ones to the right of the chart, but this is just not happening quickly enough for them to prevent being disrupted. So this rate of disruption is now at a pace, again, I think I need to keep reminding myself of this, where it's accelerating, not slowing down. So half of the S&P 500 is projected to be replaced over the course of the next decade, and something has to change. And what's so interesting about this is that almost no industry is immune. So even banking, where you'd think they would have a fair amount of security in terms of the amount of investment they have in technology and the fact that they've got significant control over how transactions are processed, tech is next, of course, rating banks. And what's even more stark to me was this study published on Bloomberg that collectively, banks have spent a trillion dollars on their digital transformations. So that's about a percent of the world GDP. So that's a lot of the world's wealth. And few have reaped the rewards, and the rewards are simply not measurable. So back at that bank story, I basically felt like I saw a billion dollars of value go up in flames, which to me was a really big problem because, again, everyone wanted the right thing. We could be seeing a trillion dollars go up in flames because, again, these transformations are being steered the wrong way. And it's not that we, as a community, don't understand what the right things are to do, it's that the business has not adapted, especially in traditional organizations, whereas it has in technology companies. So I got to thinking, this is the kind of quick history lesson part. I got to thinking, has this happened before? And as I was writing "Project to Product," Gene introduced me to the work of Dr. Carlota Perez. Gene showed you the stuff this morning. What Carlota showed us is there have been these, basically, if you're looking back, these five longer waves, can also be called Kondratiev waves, of innovation. And what's so interesting about her work is the way that she's modeled the way that these have rolled out. So they always roll out with some new means of production becoming cheap, and some small set of companies mastering that new means of production. So that could be the 2,000 fintech startups that we have today, or the even faster-growing number of insurtech startups on the market. Then you get into this turning point where some of those companies learn how to truly master software at scale. And then at that point, the creative destruction just accelerates. More and more companies that are traditional businesses from the last age get displaced. So where we are today in terms of this wave, and Dr. Perez, I've been continuing the discussions with her regularly throughout the book and through to today. She still sees us and all the research I've seen still places us directly inside this turning point, where a small number of companies have become extremely effective at managing software delivery and innovation at a business level and creating these amazing offerings of theirs that we use today. Those are the FAANGs and Microsoft, so Facebook, Amazon, Netflix, Google, the BAATs, Baidu, Alibaba, and Tencent in China. These companies only exist in the US and in China, and taken collectively, they have currently the size of the economy of Japan, in terms of the amount of wealth they've accumulated to drive this kind of innovation. So taken collectively, those nine companies are equivalent to the third largest economy on the planet, and they are leaving everybody else in the dust. So what Dr. Perez predicts is, at some point, other companies start to learn. I think it's been happening quite slowly in this particular turning point, but other companies start learning how to be software innovators, and that's really the amazing thing about this conference, is this is where we learn how to do that, how to take those practices that work, and tech startups and unicorns and tech companies, and bring them into our organizations. And as Gene said this morning, the faster and more effectively we can do that, the quicker we will get into this deployment period where production capital actually takes over, rather than financial capital, and where you end up with what can be this golden age of innovation as more and more companies adopt these new ways of working and bring them into their particular market segments. So one thing that Dr. Perez also notes is that with each of these waves comes a new kind of managerial innovation. And one thing I want to make perfectly clear through all of my learnings is the managerial innovation that's going to get us through this turning point is not project management. So, it could be what Gene showed this morning, but it's not treating people as people being cogs in the machine. That works for building the Hoover Dam. Gantts were created for building the Hoover Dam. But if you've got creative and complex work, it just doesn't apply. Even Ford realized that, that he needed to invest in his staff to help them master their work, because it was more complex work. And of course, what we do in software is even more complex. So I got to thinking, how can we actually shift? How can we make progress through this? How did some of the other companies who made it through previous turning points survive? Because we went from a world with, I opened up Life magazine at my mother-in-law's house from the 1930s, and there were about 50 car brands in there that I did not recognize to the car brands that we recognize today. And to learn more about this, I visited one of our largest customers, BMW Group. You heard from them this morning. And in their flagship Leipzig plant, as I walked through it, I learned something that I just had not learned or understood from all that lean literature and Toyota production reading that I had done, which is that just this embodiment of lean principles and how it really is different than I was thinking about software. So first of all, the lean principles from Jim Womack's book are precisely specify value by product. Product embodies that fifth ideal of customer obsession. Customers consume products. You can call them services. You can call them different things. You can ignore internal customers. But the lean principles that stated are precisely specify value by product, identify the value stream for each product, which is why you're hearing this word more and more, thankfully, make value flow without interruptions because those three ways of DevOps are still key. The flow and feedback, it's how you get to continual learning and let the customer pull value from the producer. So production is all about, and delivering customer value is all about pull. It's not about your internal activities. It's about what's being pulled by your customer and by the market. So contrasting what we see in IT today with what I was seeing in, again, one of the most advanced manufacturing plants on the planet, is these integrated production lines that were beautifully orchestrated to what we've got today is these disconnected tool chains and handoffs and basically people throwing requirement stories, whatever their abstraction is, over the fence to IT, right? Or the support desk throwing a bunch of tickets over it or incidents. Again, this is exactly we're trying to break through. But what was so interesting is everything in car production is managed as these products. That's a primary concept and abstraction rather than project. It's about flow and value rather than about tracking activities. This is a really interesting one is in car production, what I saw is that everything is architected around flow. So rather than this one massive enterprise architecture that's going to meet every current and future need, which is what I always like to build in terms of the SDKs and frameworks I was building, you actually are making trade-offs specific to the flow for that product, which means you might actually have some redundancies in the architecture, which means you might not go containerize everything tomorrow, but you'll focus on a cloud-native architecture for a fast-moving product value stream while using a strangler pattern for something that could actually stick around a bit longer. And this is the key one. Everything was optimized end to end. So this focus on telemetry local to one part of the value stream, be that change success rate or be that user stories completed, that's all secondary. We still need to track all those things, but the primary thing being measured is lead time. That's the number one predictor of company performance in automotive. And once you start optimizing and measuring end to end, and it's again where the measuring is the key thing, you start actually seeing the customer's perspective of time and of value, and you start measuring to business results rather than these proxy metrics. So the core story and the core, I think, contribution of project to product is to provide a framework to identify what flows in software delivery, to build on some of the steps and missteps of what we learned through academia and industry on this, and to provide a set of very simple customer-centric abstractions and business-centric abstractions that our leaders can understand. I think we, as technologists, already get them. At Tasktop we've got-Dozens of different work item types, basically based on the Scaled Agile Framework. Everyone understands how those work. But again, my CFO did not think that any of those things made sense. Our developers and product managers need to use story points. He did not quite see the value in them. But if we take a customer-centric view of value, if we look at what's being pulled by our customers, of course, our customers want more features. That's what makes them decide to use your mobile experience rather than the competitors, because you've created a user experience that delights them. So customers pull features, they pull value. They don't pull releases, they pull what's in those releases, and you just have to make sure they're able to pull it very frequently. Defects, because sufficiently complex software has defects, has incidents, and our ability to resolve them quickly, and focus on meantime to repair, rather than the meantime to failure is critical. Again, those things are our value streams need to be optimized for that. Risks are now a first-class part of software delivery. So data privacy, compliance, all of those kinds of things that make sure we're providing a trustworthy user experience to our customers, and debt. Technical debt, infrastructure debt, value stream debt itself, problems that we have in the flow within our organization are also critical. So these are the four flow items, and they're mutually exclusive and comprehensively exhaustive. Which means if you do more of one, you do less of the other. If you've just had your teams implement a bunch of compliance, a bunch of work for the new regulatory rules such as GDPR, you're going to get fewer features. And the ability of our business leaders to understand those trade-offs is absolutely critical, as I'll illustrate through the next few stories. So the goal of the Flow Framework is to provide today's business leaders and today's technologists with a common language of understanding that, and a set of abstractions for implementing this new approach to measuring software delivery. And when you think of those four flow items again, you might be using existing agile frameworks such as SAFe, say five others actually quite compatible with a scaled agile framework, with the Flow Framework, as are other approaches. Think of this as the layer above, as the layer that you expect your business leaders to understand. For example, as a way of elevating the need to understand technical debt at a business level rather than just at the level of the technologists. So the way it works is at the bottom, and this is a key thing, the ground truth of what we do, of the work we do is captured in those tools. It's captured in the development tools, in the support tools, in the planning tools, and so on. It's all there. And this is the amazing thing. We think that software is this intangible thing, but the level of information that we actually have in our tool repositories is at such a high fidelity, we can find that information and that flow within those tools. Then the key thing is we have to look beyond the tools and to actually model and define product value streams. And I think one of the big, I'll get back to this towards the end, one of the big misconceptions that there's this one value stream for your company. No, if you're thinking of customers and product innovation, you've got a set of these product value streams. You define them, and then in the Flow Framework, what you do is you measure flow distribution. So this is how much of each of those flow items you're going to focus on, on this release. This isn't your backlogs. You still use your agile tools for tracking your backlog sizes. This is what's actually flowing through a product value stream, so that you can look at what should be the amount of focus that we put on technical debt versus feature delivery. Is it 20%, as I heard from the last three people I asked, or do I actually need to tailor it to the needs of this product value stream? As I'll show you in a moment. The flow metrics are flow velocity. So this is a throughput rating, how much you got done over a period of time of each of those flow items. Flow efficiency, the ratio of weight and active states. Flow time, again, so how long it took end to end to deliver this, and flow load, which is a work in progress metric of how much load you put on the value stream. And that these are correlated, and this is the key part, to business results. So a value metric for each product value stream specific to that customer. This could be revenue. For an internal API, this could simply be adoption of that new API as you're trying to move off some legacy data backends. The cost for that value stream. So not the cost of ops, not the cost of infrastructure, not the cost of development or testing, but the end-to-end cost of that whole product value stream of everyone involved. We actually measure hosting costs separately for product value streams. A quality metric, and then this absolutely key one, a happiness metric. So the happiness of the staff working on that product value stream. And I'll show you in a moment why that's so important. So here's a story kind of through the lens of the Flow Framework. This is something that was shared by Nationwide Insurance a year ago at this conference, where we were working with them and helping them understand basically from the business perspective and the customer's perspective, how long it took to deliver value to the customer. And so we did some measurements, and it averaged out to 120. So it took 120 days to deliver value to a customer, which might seem like a long time, and of course, then the reaction from business leaders and CIOs is, "Okay, in that case, we need to hire way more developers so that we can get things to customers faster." Now, when you actually start measuring a value stream and you measured across these value streams, you can look to layer down. So we said, "Okay, well, how much time is spent in development?" And it turned out it was 2.5% of time was spent in development. So you can hire three times the developers. You're going to get basically no more velocity out of that because the bottleneck here was not development, it was all the wait states developers had, and it was different in different value streams, in some cases on security reviews, in some cases waiting on screens because this company actually, they were constantly waiting out. They're trying to innovate new user experiences. So the really important thing is that by taking this different way of measuring time, not measuring only code commit to code deploy, not measuring only how long it takes to open and close a user story, but measuring flow time from end to end was actually critical. And note that there's a distinction in the Flow Framework between lead time and flow time, because we have so many more requests on our IT backlogs than we actually have capacity to do that work. Lead time starts when a customer makes a request. Flow time starts when you take work into the value stream, the moment you start doing any analysis on it. You measure both, but you optimize to flow time, again, because of the size of those backlogs. And so the key thing here is relating this to Gene's five ideals in The Unicorn Project, it's critical that we take a customer-focused version of time and of delivery, rather than, again, focusing on these local optimizations of the value stream and making development go twice as fast while delivering no more value to our customers. So of course, as you're doing this, the key question is when you're trying to get from 120 days to 14 days, let's say, you're asking: Where is my feature delivery bottleneck? So we dug a little bit deeper and in this case, we realized there were wait on a couple of the key value streams that were very critical to the business because they were about the innovation. There were too few designers that were causing too many wait states for developers. So there's been this pretty big trend, of course, as our systems of engagement get more sophisticated, companies like Atlassian have gone from one in 25 designers to developers to ratios like one in nine, and even smaller in some cases, to become more innovative. And of course, by actually digging into where those wait states were, you can do this with data because in some product value streams, you might be perfectly fine in terms of your UX bandwidth. While with others, you're completely constrained, and that's where you need to hire. So you actually get that metric through flow efficiency, and again, it provides you this data- driven way of approaching this next ideal of improvement of daily work. So not only at the individual level, which individuals tend to be very good at, they know what they want, but at the level of how you invest in the organization across multiple sets of teams by identifying their bottlenecks. And you do that, again, by measuring efficiency, the wait states versus active work states across the end-to-end value stream, not just an agile team's work. So another interesting one is why is delivery slowing as we add developers? And too often, the answer to this-- actually, the most common answer I've seen to this in deployments of the flow framework over the last year, is that the software architecture has been created, again, for some massive enterprise architecture rather than to be aligned to value stream flow. So we now have taken this principle where the only time you invest in architecture is if you can increase future flow rather than making these overly generic architectures as developers like myself really tend to enjoy doing. So really the way that you track this, the way that you plan this, is by focusing on flow velocities, understanding will we actually be able to get this next set of features done faster if we invest in the cloud-native technology and have A/B testing? And this is exactly how you make the business case for those kinds of investments. So again, this is back to that ideal of locality and simplicity, where we want this not just at the level of the code base, we want that next set of innovation for the customer to be much easier because the value stream and the software architecture were aligned. So. And another key one is why are the teams working on this product less happy? The number one reason we've seen for that is technical debt is causing overly high flow load, so there's too much of a backlog of features. The business is always feeling like they're not getting enough. And it's this basically the-- you saw Gene's charts on this today. It's this death spiral of more and more load, meaning more and more thrashing, and less and less output. And again, what we want is that focus on flow and joy on that ideal. And to do that, we-- basically overloading value streams, not investing in things like tech debt reduction, does not give you a chance to do that. There's statistics that show that developers who are working on tangled architectures are more likely to quit an organization. So making these investments is absolutely critical. So I'll give you just a quick story right now of how we do this at Tasktop. We connect our value stream, and it doesn't really matter what the tools are. You connect across the tools to get these end-to-end flows. Our flows tend to start in tools like Salesforce, and support desks, go into product management tools, Jira, and so on. And so here's a quick story from earlier in this year where what we saw, we were putting out the very first release of this new product. This was the first early access release, the first beta release. And of course, we did the thing that I was just telling you you shouldn't do, that you would think we wouldn't do, which is we overloaded that product value stream with features that felt very critical for that first release. We knew that the more of those features we delivered, the more successful that early access release would be. So you see the flow load spike at that point. Once that happens, you can see something very interesting happen, basically in real time on flow time. So the flow time gets about 10x slower, which means developers are thrashing, and we're getting way less done. So just completely counterproductive. We all do this, but the difference for us was that we saw it, and we were able to adjust, again, at a business level and actually help the teams, which of course knew what was going on, which is they were now thrashing and doing way too much at once. Their WIP, their flow load was way too high. So of course, the only way to really finish this, to fix this, is we actually do need more capacity, right? And so we start hiring, and bringing staff onto this product value stream because that's the only way we can get more capacity. And we had something interesting because we do take this locality and simplicity ideal of Gene's pretty seriously. For this new product, we moved to a new architecture and some new programming languages of Scala and TypeScript, in addition to all the Java that we've got. Myself and our VP products, Nicole Bryan, we were actually as the teams decided, the set of teams on this product value stream, decided on this architecture, we were quite concerned that we would have trouble finding Scala developers. And so of course, as soon as we saw this, we're like, "Okay, you guys all made a big mistake. We should not have gone with Scala." And so we basically were, I think at one point, hours away of just top-down saying, "That's it. Scala was a mistake. We're pulling out Scala." The team said, "Okay, calm down. Just give us two or three more sprints. We really do think people can ramp up. It's not as bad as you think." And we actually calmed down. And we saw the flow velocity go up as people really did get ramped up. It was not just the promise of ramp up, we saw the ramp up. And so again, they were able to very easily prove to us, to their leadership, that we were wrong and they were right. So again, this is the kind of thing that you can get when you've got a common set of metrics and a consistent way to measure. So the whole goal is, again, that we get away from these anecdotal ways of looking at delivery, and we actually start being able to track flow in this much more tangible and common way across our value streams and understand flow distribution, flow load, flow efficiency. And in the end, do what we need to do for our teams, which is remove bottlenecks and wait states and impediments for them. This is what will enable us to transition, again, from the business being waterfall, while we've got agile and DevOps principles kind of in the middle, into this end-to-end flow orientation with a common set of measuring and a common set of metrics. Again, the whole point being direct visibility on the product value streams rather than these layers of indirection. And really a new way of looking at budgeting, because once you've got this flow orientation, you start being able to invest incrementally. And you start being able to do interesting things like basically move-- You don't want to blow up your teams. You stop doing the crazy project management notion of assigning developers and other IT staff to multiple projects. Everyone works on a single product value stream, but the teams become a unit, the product value streams become a unit. And so for example, we will actually move teams between product value streams when, let's say, we need an API team to be closer to a delivery team. Over the past year since the book was published, I've absolutely found some interesting pitfalls that I want to really quickly take you through around this. So defining the entire product model up front is one of the key ones. Thinking that you can know exactly what your end-to-end product portfolio of products and sub-product is going to be without measuring. And it's amazing that, again, this is that project mentality. What you want to do is start small and then measure and adjust and refactor it every quarter. Again, bringing those programming principles in. Waiting till things are done, till the teams are agile or 100% agile or 70% agile or whatever those numbers are to measure. You can measure waterfall if you want. It actually gives you a business case to stop being waterfall because you want to reduce flow time. And then this is an interesting one, is basically over-focusing on just the external value streams. So just the business and just the customer-facing ones. Your internal value streams are absolutely critical. They're basically what drive the productivity of your entire organization, of every developer building a business application. So understanding that value stream architecture and noting that the technology giants and unicorns actually invest much more in the value streams lower down, including the tool chains themselves, that's what drives productivity in the value streams higher up. Whereas in enterprise IT organizations, that tends to be inverted. So basically, I think where we need to head right now is to look at how we bring our organizations through this turning point to get this period of wealth generation. I think measurement and the right kind of measurement is critical to that. And just to wrap up, you do that by moving from project and cost centers to these product value streams, from silos and proxy metrics to flow metrics and business results, and from this fragmentation to this integrated connected value stream network that allows your people to collaborate and to thrive. So with that, you can find the book on Amazon. All author proceeds of the book go to programs supporting women and minorities in technology. And thank you very much.