Host Intro (Gene Kim)

[00:00:00.635] Thank you very much. All right. That takes us to our last talk, which is Stephen Fishman and Matthew McLarty. They're gonna talk about their new upcoming book, Unbundling the Enterprise.

[00:00:11.565] So I got to read an early copy of this, and it just blew me away. It's a combination of some of my favorite books: Dr. Carliss Baldwin's amazing book on modularity called Design Rules, Eric Evans' book on Domain-Driven Design, and the strategic business insights that came from Good to Great or Reengineering the Corporation.

[00:00:29.045] And it has everything to do with what Dr. Kersten talked about. When situations are uncertain, we need to preserve or create optionality, unless we get locked into situations where we have huge or impossible costs of change.

[00:00:42.685] And what's so interesting to me is that this also applies to AI and LLMs in a way where coupling can show up in very unexpected ways. So I think there's gonna be such an important book, and I think they're gonna be a part of a Kuhnian moment where many books, including Wiring the Winning Organization, they're actually tying economic theory to how we run organizations. So with that, Matt, Stephen.

Stephen Fishman

[00:01:07.285] All right. So welcome, everyone. Thank you so much for having us today. Thank you so much to Gene and the IT Revolution staff. We're very excited to be here at the inaugural ETLS event. This is one of the first public opportunities we've had to share the work that we've been doing with the IT Revolution team.

[00:01:22.165] Like Gene said, we have a book coming out in September called Unbundling the Enterprise. The subtitle of our book is the subject of today's talk: APIs, Optionality, and the Science of Happy Accidents.

[00:01:32.765] Both Matt and me have been working for enterprises over the last several years as they have undertaken digital transformation from the dawn of the web through mobile and cloud explosions. We've seen the impacts of the pandemic and through the AI revolution of today.

[00:01:48.605] In that time, we've observed a number of different success patterns in the digital economy, both with the pioneers of the web and some pre-web companies that have been able to take advantage of the amazing amount of digital opportunity that's been out there. These patterns involve the elements that are in the title, using APIs to drive optionality that leads to unplanned successes or happy accidents.

[00:02:10.845] Our upcoming book articulates the science of happy accidents in detail, explains exactly why it works, and gives real-world examples not only from these digital-native and digital-pirate companies, but also from legacy enterprises all around the world. Today we won't have enough time to plumb all the depths of what we cover in the book, but we will be able to see the surface of it all. So let's set sail.

Matthew McLarty

[00:02:36.285] All right, we are setting sail. You'll notice a little theme as we go through this here. We're gonna be on the digital ocean.

[00:02:44.305] There's treasure out there. I think that when we look at the world of digital business, we're gonna look at it as a bit of a treasure hunt. If you think about it that way, there's lots of opportunity that we have out there. I think generative AI is on everybody's mind right now, obviously. But in every industry, in every region, there's new opportunities to grow with digital business, whether it's open banking and finance, telehealth and digital disruption going on in life sciences, composable commerce. Everywhere you look, we see these opportunities, and I think as organizations, we want to capitalize on these opportunities.

[00:03:27.855] But there's more than just those potential treasures. One thing that we've learned in the digital space is that sometimes the most valuable treasure is the one that you aren't looking for, the one that you stumble across. If we look at the history of innovation, we see lots of cases where something is discovered, and it's not even realized that it's treasure until it's been applied in different ways or combined with other technologies. So there's always new treasures to find, and there's always treasures that we find that we aren't even looking for in the first place.

[00:04:04.255] So how do you come up with a strategy to find treasure in the digital oceans? Well, pirates know how to find treasure, right? Let's think about this. This is a visual depiction of Blackbeard, very famous pirate. If we think about the Blackbeard approach to finding treasure, what would be the first thing we would need to have to find treasure as a pirate? A map, right?

[00:04:30.345] We would have a very highly articulated, detailed map, which would give explicit instructions, stateful instructions, that would lead us to a path: turn left at the palm tree on the beach, start digging where X would inevitably mark the spot. We would know that there'd be a single spot on the treasure map. That's where we're gonna find the treasure that we're looking for.

[00:04:54.685] Then once you had the map, you could go out and get everyone excited, hire a crew of highly skilled, perhaps cantankerous, grumpy pirates to help you go and dig your hole and find the treasure. We've all read stories about treasure hunts and excitement that goes on there, but what happens? Would they find the treasure? Well, sometimes they might, but a lot of times they might find an empty chest, or they might be digging 10 feet away from the actual treasure.

[00:05:27.885] The one thing we know is they're not gonna find treasure that they weren't looking for with this elaborate treasure hunt, which could take a long time, cost a lot of lives, and gold coins, pieces of eight, whatever. So it's not exactly the most efficient way to do it. And if you're gonna take this approach, you're gonna have to get used to disappointment. So all that time that they spent finding the map that would hopefully lead them to riches, only to be left empty-handed. But maybe there's another way to find treasure.

[00:06:05.405] Maybe there's a new brand of pirate who thinks a little bit differently, who instead of going the Blackbeard way might say something like, I don't need a map, and might even go further to say, I don't want a map. Inconceivable. So let's play it out. You have a mission: find treasure, and you sail the seas to an island.

[00:06:26.015] But what if when you got to the island, instead of having a crew and all digging in one place, what if you had a big enough crew that they could dig in every spot on the island at once? You'd still need to know how to get to the island, but at that point maybe you wouldn't need a map. And the more pirates you had at your disposal, the less specific you'd have to be about finding the area in which to dig.

[00:06:47.295] But what if your crew, instead of the pirate crew, was an actual set of 3D-printed drones that you could produce cheaply on demand? The more pirates you have digging, the more treasure you'll find without worrying about exactly which treasure you set out to find in the first place. So clearly, thousands of distributed drone shovels would find more treasure than an old-fashioned group following a map.

[00:07:08.335] And it turns out that this is actually an apt metaphor for how leading companies are thriving in the digital economy. Companies that try to predict the future from a distance, who draw up long-term strategies and try to follow a well-articulated plan, often find an empty chest when they get to the end of their treasure map. Nimble companies, on the other hand, who spread their bets and keep their options open through preparing early and deciding late are the ones who can course-correct when conditions change, who can find treasure where nothing marks the spot. But we get that this metaphor is a little bit high in the air. So what are these robots and what are their shovels? To answer that, let's continue our pirate story.

[00:07:48.925] All right, so here's a pirate. I'm not sure about the image rights here, but this is, of course, Jeff Bezos. In 2011, there was a blog post that was posted by an engineer named Steve Yegge, who at the time was working at Google. I don't know if anyone remembers this, the famous Yegge rant, where he was comparing the situation he was in at Google to the situation he'd left when he was at Amazon. It's worth a read just even for entertainment purposes. Yegge has since actually done a YouTube video where he gives a behind-the-scenes view.

[00:08:31.145] But a big piece that came out of this was he was describing how things worked at Amazon and how Amazon had become a very strong platform company. By platform, meaning breaking down everything that Amazon did into these digital capabilities that could be used in different ways and assembled in different ways to create new products, new services, and really optimize the organization.

[00:08:58.395] A very famous piece that came out of this was Yegge recalling a memo that Jeff Bezos had sent to all Amazon employees around 2002, 2003, according to this recollection. In it, Bezos essentially said: look, everything we're gonna build at Amazon is going to be behind, I believe it was called service interfaces, but we can now call them APIs. So essentially, we're going to create all the business capabilities. They're only gonna be accessible via APIs. We only want the teams who support these capabilities to talk to each other through these APIs. And, you know, if you don't do this, you're in trouble.

[00:09:42.155] So it was a very strong statement about how Amazon should be building things with a very clear intent. In the book, we're gonna go into super detail around the whole history of this, the history of Amazon and APIs, but it was a real moment that was profound for Amazon, as we'll see how it unfolded. But in the industry, when Yegge's rant landed, it became a rallying cry to a lot of companies who were trying to figure out how to navigate these digital seas.

[00:10:18.165] But the impact that it had was unbelievable, because if you think about where Amazon was in 2002, 2003, just coming off the center of the dot-com boom, it was really the point at which the explosive growth of the company continued and really grew into all these other areas. Amazon's initial vision was really around becoming the everything store, becoming a universal retail store. You can see a lot of the innovations that Amazon came up with within that scope were probably things that you might have drawn a treasure map for. You might have said, okay, well, to be a universal retailer, you're gonna want personalization capabilities, you're gonna want payments capabilities, and so on.

[00:11:09.695] But definitely what wasn't in the plan of Amazon at the outset was to become the big cloud provider. People didn't even know what cloud computing was. To a large extent, AWS invented infrastructure as a service branch of cloud computing. So this is just the perfect example of the power of this approach of breaking things down into digital business capabilities via APIs, but also an example of how sometimes the biggest treasure is the one that you aren't looking for in the first place.

[00:11:41.695] AWS is now one of the most profitable lines of business for Amazon and has been revolutionary in terms of powering the whole era of digital transformation once it launched in around 2006. So this is just an example. What we're doing in the book is really trying to study the success stories and then from there glean the patterns. The pattern that we see with Amazon is incredible growth fueled by this API-based approach, and also this huge treasure of AWS that was found when it wasn't even being looked for.

[00:12:22.845] If we use Amazon as the example here, and they were able to find many treasures in many different places all at once thanks to their many robots, those robots were options in the form of digital business capabilities, software functionality, and data. You can think of these APIs and those capabilities as the shovels. Only through that API enablement could those capabilities be easily combined and assembled to provide new business value and new business models. Like the earlier talk today where Mik Kersten spoke in depth about being able to minimize switching costs, APIs are a core capability that help you drive down switching costs for how you're going to use, package, and bring to market your own digital business capabilities.

[00:13:11.795] Amazon isn't the only example of success with this approach. They're not the only API story out there. Best Buy successfully transitioned from a brick-and-mortar retailer with paper flyers to a digital-first eCommerce giant, greatly aided by APIs. How did Best Buy do that when every other retailer was being decimated by Amazon? APIs are a big part of that story, and we go into depth about how they were used in the book. In spite of Yegge's rant, Google, for example, launched and scaled some of its own growth products, notably Maps, successfully through APIs. Capital One brought API-enabled agility to banking. Coca-Cola used APIs to introduce new technologies like image recognition for operational efficiency, and even backed its composable soda product, the Freestyle, through APIs. Cox Automotive disrupted many facets of the auto industry with the help of an API-first approach. We're gonna dive into several of these stories today, each of these and a bunch more covered in depth within the book. But first, let's break down the approach that each of these enterprises used to succeed, even if they weren't doing it consciously.

[00:14:16.695] So yeah, it's a short talk, so this is kind of like a trailer for the book. Anything that we're going fast on, you can get in depth in the book. But if we accept that the biggest treasure you can find is the one you're not looking for, essentially what we're proposing is that you want to create a science for having happy accidents occur. In other words, how do you create conditions so that these serendipitous treasures can be found? We've distilled down three methods, and we're gonna talk about four strategies for success, and we're gonna have to go fairly quickly through these, but we're gonna call these methods in line with happy accidents: OOPS.

[00:15:01.975] So if there's one thing to take away from our talk today, it's think about the three OOPS methods, which we'll cover here. First is creating optionality through unbundling using APIs. We've touched on that. There's a second around identifying opportunities through what we're gonna call value dynamics. We'll talk about that in a second. And also optimizing through feedback loops. So let's go into each of these.

Stephen Fishman

[00:15:33.455] So the first of the OOPS methods is about optionality. Optionality may be the easiest to understand outside the realm of technology. So as any of you approach your own life, do you make significant commitments as soon as possible or as late as possible? If you're seeking a new job, working with your children through the college application process, or even using an online dating app, do you commit to the first possible choice that comes your way? Or do you try to slow the decision down, like that slowification term that Gene uses in Wiring the Winning Organization, until more information becomes available?

[00:16:08.105] Slowing down the process of making commitments, preparing early, and deciding late conserves optionality. Having an API as the gateway to your enterprise capabilities allows your enterprise and its partners the ability to pursue multiple options at once without making any real sacrifice by pursuing any individual option.

[00:16:30.105] Take the case of Google Maps. It may be hard to believe today, but it is a surprising fact that Google never really intended to make their APIs a paid product. And those APIs are actually the highest-usage function on Google Maps. Because they chose not to lock themselves into a single context of use, the world opened up and scores of businesses around the world leveraged the digital interface to go and seek their own treasure. Rather than Google choosing to put a price tag on the API product, it was actually the users of that API who came to Google unsolicited and asked them for the privilege to pay for it, to ensure that they could depend upon it as they incorporated Maps into their business models.

[00:17:13.555] Choosing to make a decomposed architecture made up of discrete capabilities is not just a technical choice. It's actually a financial one, where you can give yourself the option to consume or export that capability in a near-infinite number of contexts.

Matthew McLarty

[00:17:31.295] So the second OOPS method, just to go quickly, there's no way we're gonna have time to talk in depth about value dynamics, but essentially, if you break down what business models are, we're gonna argue in the book that business models are essentially a combination of the value exchanges that your organization has with all of its stakeholder organizations: with customers, with suppliers, with partners, and so on.

[00:17:57.945] We actually come up with a visual method of showing how these value exchanges work and showing how this is extremely valuable when you're looking for opportunities or looking to divine opportunities from the digital ecosystem within which you work. So in the interest of time, there's no way to get deeper than that at this time. This is really about the mapping mechanism that we propose, which is very different from me.

Stephen Fishman

[00:18:28.285] Singular.

Matthew McLarty

[00:18:29.745] Singular, yeah. If you wanna find the island, not necessarily find the granular way of getting to a specific piece of treasure.

Stephen Fishman

[00:18:37.675] So the third OOPS is optimization. If you're a fan of Gene's work regarding the third way of DevOps, or an old-school student of the OODA loop, you're likely present to the criticality of paving the path to learned insight. Optimizing your experimentation ecosystem has never been more important than in the search for market advantage.

[00:18:54.245] Each of these three OOPS tactics works to lower the cost of running trials and experiments. High-cost, high-risk experiments are rabbit holes where team capacity is engaged for long periods of time, just like long-lived branches when you're actually doing coding, just like the pirate is placing his or her faith on the accuracy of the map.

[00:19:11.985] There are four main themes that emerge from how enterprises can ruthlessly lower the cost and time required for business teams to create and test bundled and unbundled packages of value and deliver consumer-facing experimentation at scale: feature flags, ramps, visualizations, statistical literacy, and tooling. Each of these helps to deliver this capability to make targeted changes with lower effort, faster timelines, and less likelihood of breaking things.

[00:19:38.905] We go into each of these four methods, not only in theory but also in specific examples for how each of these different enterprises use these four tools in order to optimize their feedback loops and accelerate the path to learning as they grow in their spaces for digital products.

Matthew McLarty

[00:19:57.525] All right, and Stephen, just looking at the clock, I'm just gonna run through the last few slides just to wrap us up. But a big message we have is: it's not like you just take the Amazon playbook and copy it for your organization. What we're doing is really diving deep and distilling the patterns out of here. We have a number of success strategies that we won't have time to cover where we give specific examples.

[00:20:21.675] Exchange optimization is about turning your value exchanges from physical or manual to digital. Cox Automotive is a great example here. Coca-Cola, we talk about distributed innovation, which is about how do you spread out the ability for more people in your organization or beyond your organization to drive your innovation. Coca-Cola does this, and we give examples of how they use the OOPS methods. Capability capitalization with Amazon is about taking things that were built for other purposes and applying them in new ways. Obviously AWS is a great example of that.

[00:20:57.775] And then finally, value aggregation is where you can take two seemingly disconnected business models and plug them together. Best Buy did this through their Geek Squad business and their retail business and their online business, and we show how that's done with the OOPS method.

[00:21:11.855] So, okay, we went pretty fast there. Not a few slides. Hope you're not seasick. But again, these OOPS methods are the heart of the book, and I think there's a lot to unlock in there. So thanks for the time. Wish we had more time, but thank you, Gene.

Stephen Fishman

[00:21:28.665] Yeah, thanks, Gene.

Host Close (Gene Kim)

[00:21:30.415] Fantastic. Thank you. I'm trying to adjust my mic. Thank you so much. I'm just really excited about what your book explores, and it would not surprise me if in 10 years a lot of us were going to be using this language to be able to make both technology decisions and business decisions. So congratulations. I can't wait to see where you take this. So thank you, Fishman. Thank you, Matt.