#196 - Unbundling the Enterprise: the Power of APIs, Optionality, and the Science of Happy Accidents - Stephen Fishman and Matt McLarty

[00:01:17] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me the authors of the latest book from IT Revolution. It’s titled Unbundling the Enterprise. So Stephen Fishman and Matt McLarty are here today to talk about the book. Really excited to talk about this, because I feel this is a very interesting topic, although a little bit, sometimes a little bit enterprisey, you know. But we also cover things from the startup world and also the big tech giants, right? So welcome to the show.

Matt McLarty: Thank you. It’s great to be here.

Stephen Fishman: Thank you so much. Great to be talking to you.

[00:01:51] Career Turning Points

Henry Suryawirawan: Right, Stephen and Matt, so I like to actually ask first for my guests to share any turning points in your career that you think we all can learn from. Maybe any one of you can start first?

Stephen Fishman: So I think what got me started on this journey to where we’re talking about the book and all that stuff today was more about a moment years and years ago, where, like, I saw something that excited me and I was willing to just keep on following and pulling the thread. So turning point for myself that we all can learn from is like, I found something early in my career. Like in the early 2000s, when I was working for a sapient consulting company, I was just at a place where I really was able to learn from others.

And I found like in the technology work that I was doing, I found stuff that really interested me on automation, on APIs, on how to create teams that could work independently of each other while being integrated with each other. And those things were really fun for me. And then later in life, I turned into, you know, really focusing on the humanities and other stuff and learning how to write. And I took the stuff that I was interested in that I was really excited about in the world of technology and I made something. And that was it. I found a lot of value in embracing both the technology side and the impact with people side. That’s been a really foundational thing for myself.

Matt McLarty: Yeah, for me, you know, I think that the theme of the book is a lot about happy accidents and serendipity. I can’t say that I had a grand plan of getting into technology. You know, I was a math major in university which was more a function of trying to optimize for minimum amount of homework than any career planning. I ended up working in technology companies more of a function of connections that I, you know, family connections that I had, summer jobs.

But you know, in my career, I started at, when I came out of university, first full time job was at a big bank here in Canada where I live. There, I was sort of using this, I guess, we would call it legacy technology. It was HP nonstop. Now you used to call them Tandem Computers, sort of this, uh, niche technology. But again, I just sort of happened into the integration and API space by virtue of a system that had been built in the team I was in. I think it was really that I had the great fortune of being, starting my career at the same time that the web was really taking hold. And all the possibilities of the web.

So I guess for me, a turning point was just getting into web technology, meeting the world of business. In my case, it was in banking, but that really opened things up. And being in that space where going into the unknown from a technology perspective, the web was such a massive shift, and opening up and changing, shifting paradigms, changing the way people were looking at systems and overall mainly connecting things. So I think it’s interesting now because with the big AI boom that’s going on, it’s kind of it feels a little bit like that where, you know, people aren’t quite sure exactly where this technology is going to lead. So it’s kind of an exciting point in time to be in here again.

Henry Suryawirawan: Right, thanks both of you for sharing your turning points, right, from your career. Really interesting to learn from Stephen that actually you also learn about the humanity aspect and now it also kind of like helps you in your career.

[00:05:21] “Unbundling the Enterprise” Book

Henry Suryawirawan: So let’s go to the book itself, right? Unbundling the Enterprise: APIs, Optionality, and the Science of Happy Accidents. So we heard about happy accidents. But first of all, what motivated you to actually write this book? Because, you know, digital transformation and API enablement kind of like already happened for many many years now. What are some of the interesting things that you want to cover from this book?

Stephen Fishman: I remember when Matt and I were in Canada doing our, uh, our writers’ retreat when we were putting this together. And, like Matt wrote on the whiteboard, The Science of Happy Accidents. And it was so great in so many ways. And I think one of the big reasons, that was not the book that we intended to write. It came to us through interviews that we were doing with executives and digital leaders. And it also, I think, at least for me, reminded me of how that worked out in both my professional and my personal life. And it was just such a beautiful articulation from Matt at the moment that totally represented the whole experience of writing the book.

Matt McLarty: Yeah, we, the book writing was a journey, for sure. I would say even going before that, like Stephen and I have worked with so many different companies and helping them. You know, we have our… Everyone has their biases. The lens that we were looking through was very much around APIs, adoption of how companies are using APIs, APIs as products. And we felt like there was a story to be told that hadn’t been told yet around how you can take advantage of APIs in a business context.

And I think a good decision we made early on that Stephen alluded to was not to, like we had an outline, we had a pretty good outline, right? We went to Gene and IT Revolution and sort of explained why this would be a nice companion to a lot of the work that’s organizational architecture work and team topologies and more of the view of methodology around, like now you see with flow engineering and, uh, project to product and so on. We felt like it was sort of the, the material of what people were building more of the architectural side of things. But we had an outline, but we deliberately said we’re going to discover the story. Rather than just have our narrative and force everyone into it, let the narrative emerge from the empirical, data that we would collect from all these interviews, which is why we were able to say, you know, APIs are a part of this, but maybe they’re just the tip of the iceberg. And so how do we look deeper?

So we were very grateful to IT Revolution for the team, they’re incredible at really helping us articulate that whole narrative and being patient with us as we sort of went through that discovery process. But I think it was very worthwhile. And it was probably the best decision we made was to say, let’s not force the narrative here. Let’s let the narrative emerge from the discussions that we had and all the people that we talked with, and it really helped us see, have our own epiphanies, even in a space where we’ve been working for so many years.

Stephen Fishman: Matt pointed out a, a number one piece of advice I give now to anybody who says they’re interested in writing a book. They say, what do you have to say? Get great editors. They help us so much.

Matt McLarty: Absolutely.

[00:08:39] Amazon API Revolution

Henry Suryawirawan: Right. So I think in your book, you started by giving us this kind of like story, which I think some of us might have heard, you know, about the revolution happening in Amazon. I think that’s kind of like good example, right? Or maybe also taking stories from like Google, Google Maps, and Facebook, right? So maybe if you can just share that story again, because I think that can be powerful, especially for those who have not listened to that story. What kind of revolution that actually happened, you know, in Amazon back then? And how do you actually want to use that as a good example for enterprise?

Matt McLarty: This, this is a fun one because, if I may, Stephen. uh, I think this is a fun one because so much has been written about Amazon, right? It’s, you almost feel like are we just saying stuff that everyone else knows? But we spent a good amount of time doing really forensic investigation. Like we were deep into the internet archive on some of the material that we used to. I remember reviewing like O’Reilly Developer Conference agendas on Internet Archive from 2003 and things like that. And it was really piecing a lot of stuff together. So there was a book that Brad Stone wrote, The Everything Store, which had some, I remember reading that book, you know, 12 years ago, and it had some bits on the origin story of Amazon, and the origin story of APIs at Amazon. We found some interviews with Andy Jassy and so on.

So it was a really piecing a lot of that stuff together. And I think for us, Stephen and I being in the API community so much, there is this legend of the Jeff Bezos mandate API, or the Jeff Bezos API mandate that I don’t know how far that spread. I know Gene is, Gene Kim has talked about that a lot on his podcast and so on. But it really…

Stephen Fishman: I do remember that day. Like I followed that stuff. And I was one of the few who was on Google Plus.

Matt McLarty: Oh yeah, well that yeah, so how that got revealed to the world was a developer at Google at that time, Steve Yegge, right, had put out this rant about how Google needed to learn how to build platforms the way Amazon did. And he didn’t mean to publish it to the world, but he did, and it went viral. What piecing it together, talking to people at Amazon, looking through all those other sources. Like I guess the question was, how much was it myth? How much was it truth that Bezos had put this mandate out there? And it really turned out to be quite true. And the way things that were built at Amazon was like, everything that you build, build it behind an API. Because if you do it that way, then it’s going to be easily reusable in whatever context makes sense. And I think…

Stephen Fishman: And it must be externalizable in design and execution. Not saying that they will make it available to external. Externalizable by design.

Matt McLarty: Exactly. And so the greatest story to tell there are the results of that, (which) is AWS, right? Because I think if you look at Amazon’s origin story, Bezos all didn’t have a big vision. It’s not like it was a little book retailer that happened to turn into this giant retail conglomerate. He had that vision. It was going to be this everything store. But I don’t think it’s, I don’t think the cloud services were ever part of the original vision. That was more a case of, you know, some ingenuity around the thinking, but also leveraging these building blocks that were API based that allowed AWS to be built from pretty rapidly brought to market. Even to this day, I think like S3, the original AWS services is like the gold standard for API products out there. And really looking into, you know, not every company can do that type of… It takes a certain type of corporate culture, I think, to have that type of mandate, but it’s a great proof point of, if you do go all that way, look at the results.

Stephen Fishman: Small bets, placed wide. Because it was things that Amazon was already doing, and it was just more of an instruction of how you’re going to go about doing them. Follow this rulebook. And unintentionally, like a new economy emerged from that approach. Not just for them, but for everybody.

Matt McLarty: And it, and it sort of, it brings the whole subtitle of the book together, right? APIs, optionality, science of happy accidents. What we’re getting at there is by API enabling all these digital capabilities in your organization, you’re driving a high degree of optionality in the environment, because you’ve got all these services that can be used in different ways. And the science of happy accidents is like do that, as Stephen said, place a number of cheap bets widely. And then, accidents will happen. And many of them in a good way.

Henry Suryawirawan: Right.

Stephen Fishman: It shows over and over and over. Like the Google one that we also mentioned, Google Maps. Everybody uses or a lot of people use, and people are familiar with that, hey, it really transformed, GPS has transformed a lot of people’s lives. Google, on the Maps product, was never intended to actually be an API service that would power everything else, all the other Maps things that you see somewhere on the internet, on mobile phones, in all the different places where they’re at. And people pay for those things. Because they went to Google after they had built it. And it’s like, hey, we’re using this, we’re betting our business on this. Please, will you give us the privilege to pay for it?

[00:14:10] What Drove Jeff Bezos’s Mandate

Henry Suryawirawan: Thanks for sharing these stories. I think they’re really cool, right? Especially the first time you read it, right? I’m always amazed, you know, how come Jeff Bezos can come up with such a mandate, right, company-wide. It’s like from the top down. I know that he has some engineering background, but back then we don’t have a lot of API examples in big tech companies. And also we don’t have, you know, all these microservices craze. So maybe in your part of your research, right? Would you be able to identify what actually led Jeff Bezos to actually come up with such a mandate organization wide?

Matt McLarty: Yeah. I I think, you have to give him credit. Like from everything that we can piece together from objective sources, he was very plugged in. I mentioned the O’Reilly Developer Conference, he attended that personally with some of his team. But there was a whole synthesis of, because they were experimenting with APIs. Tim O’Reilly deserves a lot of credit here as well. He was very early on recognizing the potential of APIs. And we quote a few blog posts from Tim where he’s outlining the why APIs are so important and like nailing a lot of what the what we’re talking about here, and this is in 2002. And talking about specific examples.

I mean, we talked about Google Maps and the success there. O’Reilly was calling out MapQuest, I think it was. And saying, like, I’ve been trying to talk to these people, telling them they should open up an API for MapQuest, they won’t listen to me. And they’re going to be in trouble, because I think he said at that time Microsoft could come and disrupt them with their mapping capability, but it turned out to be Google.

So O’Reilly was in Bezos’s ear, saying, you know, you should really do this API stuff, so Bezos was listening to him. And I think there was also, in the Jassy piece, he was talking about this retreat that they had with, it was, it was across the whole AWS leadership. And in the piece where, you know, we were looking into what Jassy was saying on a Harvard Business Review podcast, he’s talking about a retreat that the entire Amazon leadership team had, where they were going over their strategy. And at that point, I think they were looking at how they were essentially going to refactor the entire Amazon website. And that’s where they were thinking architecturally. So you had commercial opportunities to open APIs, this refactoring need in order to scale the company. So I think the recognition of the opportunity, certainly Bezos deserves a lot of credit. But he did have, he did have a lot of people in his ear and leadership support. Now the enforcement of it is another story because I think, I think there’s a pretty unique culture-there.

Stephen Fishman: I do think there’s something interesting to look at here, because, like, I do hear what you’re saying and I know, like, today that seems like really hard and impossible. And I do think that there is a special place that’s between the difference between being the CEO and being the CEO and founder, and the CEO and founder who has so much actual ownership. Like Gates was able to do similar things when Microsoft pivoted to the internet. He was able to do that. But like it’s that level of transformation is ridiculously hard for executives in general. Not necessarily founders.

Henry Suryawirawan: I think that’s a very interesting one as well, right? Because so many new executives try to come in and change, you know, the whole culture, the whole tech enablement and things like that. So definitely that’s a kind of like a one of good insights as well.

[00:17:36] Optionality Through API Unbundling

Henry Suryawirawan: So I think the different from the books, as you mentioned, right? I mean, like if I want to compare it with other API, digital transformation kind of book, is actually this concept of optionality and also the happy accidents. So maybe let’s go to there.

I know that you mentioned earlier, small, small bets place widely, right? So what are the some of the key points about optionality that you want to convey to us? Because I’m sure many companies now has an API, especially if they have some kind of a tech underlying their business. But this concept of optionality is probably something novel for some of us. So tell us a little bit more about optionality.

Stephen Fishman: Matt, I’ll start off and you want to pick up in the middle? We talk about this in the frame of, um, the OOOps methodology from the science of happy accidents. And OOOps is the three Os, so Optionality, Opportunism, Optimization. So Optionality through API unbundling is the first of the three OOOps methods. In that, you can, because what we refer, it’s a method called slowification or slowing down the process of actually making hard commitments. So smaller components in a system basically mean that they have less context, context applied to them. Like something that is built from end to end has a full context applied to it from the point of value generation to the point of consumption all the way on the out for the very, very end. But the smaller that you can make those commitments as far as what is the context that you’re putting in, you have more options for how that thing can be used.

Now this doesn’t like… there’s a lot more to come after this that’s just laying out what the concept is that if you make smaller commitments, you can actually create a space for other things to happen in that universe. The same way that Google built out Maps, the Maps application. Because they had built an API service that was divorceable from the front end experience and didn’t need the front end experience. Other people were able to build little things upon it. Not all smart people work for you. If you make something, other smart people will come and do something interesting with what you’re making.

Matt McLarty: Yeah, completely. I think what we, and we sort of have been talking about this for years, right, when it comes to APIs, and there’s different ways of characterizing it. One of the big things we found, I think, through the process of writing the book, again, hat tip to Gene, was the work of Dr. Carliss Baldwin. And I remember, I think it was a particular episode of the IdealCast talking about modularity. And yeah, he mentioned Carliss Baldwin and we started looking into this. Stephen and I were like minds blown because she is a professor at Harvard Business School who had been studying option value in the economics space. So how do you measure option value concretely? But then had gone to another context, right?

So she recontextualized the area of study and was looking at the idea of measuring optionality within technology. And this was work that had been done years ago. I think the first book Design Rules, volume one was published in 2000, where she’d been doing a study of more on, uh, hardware level and componentization of software pieces within a hardware construct. And coming up with some very interesting insights about how you measure optionality, how you measure dependencies, how you get the point of controlling the value at the point of integration, all these things. And we’re like, this is exactly. This, this is like an academic study of the dynamics that we’ve seen in the software space when it comes to APIs and optionality.

So that really drove. And then, and then I think Stephen, I’m sure he’ll talk about this more, the work of Nicholas Taleb on Black Swan, so on. And anti-fragility was this idea of which his, his work is, always colored with a little bit of disdain for the human expertise. He’s a real empiricist, right? But saying, look at what happens when you have all this option, optionality, how you can, especially convex optionality, you can drive a lot more value.

Stephen Fishman: So when we found both of these things, one from Baldwin, option value is high when consumer tastes are heterogeneous and unpredictable, which is kind of describes our universe. Different people like different things. People change the things that they like. And that’s been true in technology circles for a long time as well. So we know that this is a thing that describes how you can actually value these options. And on the other side, Taleb, in Anti Fragile, builds out this entire economic model for how financial traders actually stratify and understand risk and gain across different option models. And you can overlay those two things and directly see, here is a strategy for you inside of an enterprise to make a set of packaged capabilities that you can combine and recombine at will to create your ability to find the optimal market fit for those capabilities. Whether they’re the ones that you do now or the ones that are buried within your enterprise. Either way.

Henry Suryawirawan: Right. So when I read these chapters, I also find it really fascinating, right? So you talk not just in terms of technology side, but actually you brought up points, you know, from economics and also, you know, like Nassim Taleb, right? I think this concept of anti-fragility has been applied to so many different areas as well. So I think one key learnings, at least for me, when I read about the optionality is that companies these days build APIs. But simply, I think many of them do it for the sake of the external facing apps, be it a mobile app or websites, right? But actually, if you break down those things into more APIs, giving more options internally within the company, or even for the external facing consumers to actually use those APIs, you can kind of like end up with these so called happy accidents, right?

[00:23:59] Happy Accidents

Henry Suryawirawan: So maybe let’s go to these happy accidents as well, right? So how can actually these kinds of options end up into such happy accidents? So maybe, I don’t know, you can come up with some examples that you did from your research as well.

Stephen Fishman: So this is a lot of the second half of the book. So the first part is here’s how the science lays out and here’s how you can like see the possibility of some of these things and navigate to those possibilities. Second half of the book is all about, here are clear examples where this is happening, not just for external things, like you were mentioning a second ago, but also for internal things, and you can create this emergent world of awesome wins.

One of the first examples is in a strategy we refer to as exchange optimization. And there’s a full study in there about Cox Automotive. Cox Automotive is one of the largest private employers in the United States. That’s, uh, Auto Trader, Kelley Blue Book, a number of brands and billions in revenue. And we go through a fairly detailed explanation.

This actually, funny thing, this brings me back to my personal first happy accident. I used to do a leadership role in technology and development at Auto Trader and Cox Automotive. While there, I was in charge of APIs integration, front end, back end, a bunch of stuff. And I had been asking my team to develop the or design and develop the API platform, which was primarily, just like the way you said a minute ago, designed to serve a mobile application. And somebody from the BizDev team came to me just like, hey, I heard you have this service available. And I’ve got this customer out here who wants to do this weird thing. If you just, you know, open up that API for me to do a proof of concept for, I think we might, you know, be able to create some business together. And so in less than like 40 hours with work much less, we opened it up and in quarter revenue just happened on a thing that we had built for a completely other purpose.

And the Cox story is one of that, like of. Not just that moment, because actually that part is not actually in the book. It’s more a focus of here’s how this strategy played out large with both mergers and acquisitions, about creating cross company marketing opportunities, about actually creating fundamentally new business models for, of things like fleet management that exist because Cox paved a lot of those paths for how to do that in new economies of mobility. And how they actually both consume their own market in a number of different ways and transformed and re-evolved. And one of the more interesting things about that is they’re a strange hybrid of both online and real physical stuff. Because they run the biggest automotive auction platform in the world. And they, they do. They have so much in the physical space and evolving to become a digital platform business at large.

[00:26:59] Opportunism Through Value Dynamics

Matt McLarty: Yeah, I think a big part of the messaging around happy accidents as well is that it would be nice if you just didn’t have to let the accidents happen like accidents occur, right? So when we go back to those OOOps methods, right? We talked about optionality. I mean, optionality is great, but optionality is not enough on its own, probably. The, the second OOOps, which is, you know, opportunism through value dynamics, right? We sort of lay out this way of looking at the business landscape through value networks. This was, again, sort of heavily influenced by Clayton Christensen, who’s a, was a Harvard professor and wrote some extremely influential books like Innovator’s Dilemma. This idea that if you look across your whole ecosystem that you reside in, then that’s the best way to look at the business.

And we, again, influenced by a couple of Dutch professors, uh, Roel Wieringa and Jaap Gordijn, who did work on this. They didn’t call it value dynamics, but they have a whole model around how you exchange value between entities in a value network. And if you look at things that way, combined with an optionality, you know, approach that’s high on optionality, it does give you more of an insight into where the best, the happiest accidents may happen. And I think, you know, what was fun as well, going through the examples, like Stephen just talked about the Cox example. Did they look at the world through the lens of value dynamics? Probably not, in the, you know, in the pure sense. But if they had, they probably would have come to the same, a lot of the same conclusions and strategic. Strategic moves. And that’s probably the same for all the stories. So it’s not like they applied this value dynamics lens, but in retrospect, if you use it, you can really see where the opportunities would happen.

There’s other great stories. You know, we talk about Coca Cola’s. I think Coca Cola had a really interesting way of being intentional about introducing new technologies, which is probably very insightful as companies are trying to figure out how they can apply Gen AI in a useful way. Their tech team would take on new technology like augmented reality or image recognition. And rather than try and come up with the ultimate use cases to apply it, be more like, build the capability in a way that’s minimum friction so that it can be shared out across the lines of business to see what they might do with it. And I think, you know, in there, in the case of image recognition, ’ they were thinking, okay, we may, we might use this to optimize our warehouse operations by doing counting and so on.

But when they actually released it in the wild to the business, they ended up having it be utilized by partner distributors who could go into stores and take pictures and do inventory management and even do competitive analysis to see, you know, what bottles were next to the Coke bottles and so on. So I think that was a really interesting way of driving, you know, coming up with the right options. And then that pattern is more about distributed innovation. So how do you lower the barrier of entry so that people across your whole organization can take advantage easily of the options that you’re providing to them?

Stephen Fishman: So one of the my favorite parts about the Coca Cola story that just explains so well in the book and it also actually speaks to the Amazon story from before as well, is this thing called serial optionality. Like AWS didn’t become what it is today, you know this, at a light switch. That was a thing that was built over 20 years by small bets early, understanding what’s winning, what has an opportunity in the market, and then building upon that in a very sequential way, one after the other after the other. And that these composable things, small, recomposed, recomposed, recomposed, leading you to other new opportunities created, like these things that, like a snowball rolling downhill.

[00:30:55] Value Dynamics

Henry Suryawirawan: So thanks for mentioning about this second part of the OOOps, right? So the opportunism through value dynamics. So maybe for some people who are not familiar with value dynamics–I wasn’t, right? So when we read about this value dynamics, so what should we actually think about it? You mentioned about aligning with business goals, you know, all this optionality that can create values, right, internally, or both internally and externally. So what actually is value dynamics?

Matt McLarty: Sure. I, I think this actually came about, you know, we were looking at how do we define business models in the world of APIs. So there’s, there was some great work done about 11, 12 years ago by John Musser, who was with Programmable Web, where he came up with a list of these different patterns of business models that API companies use that could be oriented towards developers. Or they could be, you know, you could have different pricing models, pay as you go, all these, he kind of had a taxonomy of these business models. When we were taking a look again, thinking, you know, is there another way to kind of look at business models? Like can we pick those patterns apart a bit?

We, again, Stephen and I tend to go down the rabbit hole. So this one led, and it was, there’s a book, The Build Trap, I think an O’Reilly book talking about product management. This idea of what the value exchange is between two parties when it comes to a product. You know, you get, you pay the money, you get the goods and services and so on. I started thinking about that more broadly about how, what types of value do exchange when it comes to APIs? Because it’s not all monetary. You know, there’s these different aspects. There’s like sometimes you don’t charge for an API, because you just want to have your API spread wide and far and be used by everyone. It could be a non profit model or something like that. Driving reach may drive the core of your business. But essentially ended up with this idea of what if we were to map the value network, which could be companies, APIs, consumers, and so on, and show what type of value is being exchanged. You know, you’re going to give me something, I’m going to give you something in exchange. I thought this actually worked really well.

Stephen Fishman: And that something can be digital as well as physical.

Matt McLarty: Exactly. And I think increasingly is just, is digital or, indirect, non concrete, like more of these abstract things. And I think data in that sense itself becomes a very interesting currency of exchange. Because there’s a whole section we do on the economics of data, we’ll save that. But doing all this thinking, this is so smart. You know, we’ve come up with this great idea. Then went to find out that it had kind of been done before. So I mentioned Wieringa and Gordijn, like they’d been doing all this work on e-commerce business models since like turn of the millennium. And made, and made contact with them. And we did some really interesting work together, mapping out some of these different ecosystems. So big credit to them.

But, you know, I just think it’s a way we want to think about, when companies are trying to think about how they price their products and package their products, a lot of times they think about, they put themselves at the center of the picture. And then they think about who their direct consumers are. And I think that framing of putting yourself at the center works about as well as it does in life, right? You know, you’re part of a bigger whole. And so thinking about who are your customers, who are your partners, who are your competitors, like all these different players in the ecosystem. If you start mapping things out by what values exchange, it can be very, very powerful.

And you can… It makes things more intuitive about, okay, this is why it makes sense to do things this way. Or okay, this is why this idea is not going to work, right? I mean, even though it might seem like on a myopic view, it might seem like it makes sense, in the bigger picture, it’s not going to make sense, because we’re just, everyone’s going to go to a different option, or it’s going to be cut out. So I think it’s more broadly applicable than just within the context of what we’re talking around, around the APIs and optionality. But it’s definitely very good companion for optionality.

Stephen Fishman: There’s a fairly large community that actually uses like that stuff right now, but not necessarily in the context where we’re talking about. Like there’s a big service design community that focuses on like service design language. And that was, Matt and I came to the value dynamic stuff from these two different places, cause I live in the design community for a long time and earlier in my career.

And like when we were brainstorming about certain like memes and concepts in the book, and like I brought out this thing from my service design land called Orchestrating Experiences by Patrick Quattlebaum and Chris Risdon, and it had all these service journeys, because it’s not meant to be, specifically to be applied in the technology specific space.

It’s more about how organizations and people work together to accomplish some type of end, which is similar to what we’re doing, but we’re talking specifically in a digital context. That whole community operates on those types of diagrams and how that, how exchange models work.

Henry Suryawirawan: Right. Thanks for explaining this concept. I think this is really powerful, right? Because you can’t just unbundle the API, you know. Break your APIs into multiple, I don’t know, maybe microservices or something like that. But actually you need to look at the perspective of value exchange, right? So from value dynamics perspective. And that’s how maybe the happy accidents could happen, right? Because otherwise it could be just an accident and a lot of chaos, something that maybe you shouldn’t even build in the first place, right? So I think…

Stephen Fishman: There’s two really, I think, important points right here in this point in the conversation. I don’t think Matt and I are saying microservices everywhere for everything. That approach had had problems in the past. Value dynamics is a, a specific approach to help you focus down on which capabilities are valuable, which ones are potentially worthy. What level of investment do we want to do? We do actually still believe in decompose by default. That’s true. But there also needs to be a business model or the justification needs to move to… Alright, this stuff, nah, maybe not.

Matt McLarty: Yeah, I think in the… We use the Facebook example early on because, I don’t know, I am of a certain vintage. And I remember in 2008-2009 when Facebook was getting such great adoption rates, people were like this thing’s never going to make money. There’s no business model behind it. It’s gonna fold. But if you look at it from a value dynamics perspective, they may not have been collecting money from their users. They were collecting data from the users. And if you look at just the incredible value potential of data, right? They really, that was the key to the whole business model. It was only a few months before the revenue started rolling in.

So, you know, I think, it’s a great point that the reason you go to a modular architectures and you drive optionality and APIs and so on is not just because it’s the architecturally pure thing to do. And I’ve worked with many architecture groups where they get on that horse and they just want to ride, right? It’s like you need the sanity check. And it definitely works as a really good sanity check, a good lens to evaluate your architectural decisions.

[00:38:03] Optimization Through Feedback Loops

Henry Suryawirawan: Thanks for the plug. I really find it really, really interesting and very insightful, right? I mean, we have covered two parts of the happy accidents, the science of happy accidents, right? We’ve covered Optionality, we have covered Opportunism. So the third O, which is actually Optimization through feedback loop. I mean, Optionality itself not enough, Opportunism probably not enough as well. So tell us about this new lens about Optimization through feedback loops.

Stephen Fishman: We have a lot of almost hero stories in the book about like various digital heroes who did, you know, awesome things in the enterprise they create. This one is one of my favorites, because it’s actually not a digital hero at all. It’s a guy, Marvin Pipkin who… We all know who invented the lightbulb, Thomas Edison, but there’s like this enormous gap between the time when Edison invented the lightbulb and when it actually became viable for people to actually have electric lights in the house and scaled usage for industry. Like that didn’t happen for a very long time. And Marvin Pipkin is this guy who was just obsessed for like 20 years. He was working on trying to figure out a way to make light bulbs not shatter when you just brushed up against them. And accidentally, he had this process and this thing. And one night, he left it in a weird way. Next morning, he came in and, oh, he knocked it in another accident. He knocked it on the ground and it didn’t break. And he was like, how did that happen? And how it happened was he kept on working and cataloging the negative results for this does not work, this does not work, this does not work.

That’s a thing that is inside Taleb’s view of anti fragile that I think a lot of people overlook. In order to make that model work, you actually have to have a lot of iteration and have to catalog the negative results. We do a lot of explanation into modern frames, like how organizations like Etsy and John Allspaw built these statistical modeling tools to make it really easy to bring the cost of experimentation down. The way to do that, like we all know, you know, agile helps you generally make smaller decisions on the front end of your process. Integration and, and the stuff that we’re, and APIs we’re talking about are on the middle end of that process. But if you can’t operate really freely and bring the cost of experiments down, it just keeps backing up and you end up with piles of technical debt and all these other things. But if you really focus on actually the science of experimentation inside your organization through ramps, feature flags, being able to visualize things, and having a team that’s capable of statistical literacy and tooling – which might be different now given the world of AI, but maybe not given the world of hallucination that, you can, if you choose an enterprise.

And this also goes back to Bezos and Jassy, that like, if you look way back in more of the Internet Archive, we uncovered this YouTube thing that was taken off the internet for some time. And it’s Robert Fredrickson, if I remember the name right, and Bezos, at, like, doing a lecture at… I forget exactly the university that they were there for, and the whole thing was videoed, and it’s them talking. It’s Bezos talking about, hey, when the cost to experiment is high, people are going to do, there’s going to be only a couple. That’s just the way it is. And if you figure out, here’s how to actually lower the cost of experimentation through automating your feedback loops, and making decision making easy and making information come to people, you can actually do a lot of experiments wide.

The only way optionality works is if you can actually run a lot of experiments. And this is the core theme of the book that brought us to that whole pirate story that’s at the beginning of the two pirates. One pirate has a map, digs in one place on the island. The other pirate has a thousand shovels that he can dig everywhere at once. The reason that Google, the Google Maps thing worked, because it was right close to the surface, and they didn’t have to put any effort into doing it. By actually building these capabilities in this way, they will be close to the surface, and it won’t take a balloon payment to figure out how to actually make it valuable outside your enterprise or inside your enterprise.

Matt McLarty: And I think one, just one thing to add on the topic of feedback, which I always find I think pretty practical, we always look at APIs as sources of data for, you know, they’re service providers. People go and they invoke APIs, they get what they’re looking for. But that actual interaction of an API is instrumentation, right? You now have a way of observing more the full flow of what’s going on. And so APIs themselves can drive the feedback loops and lower the experimentation and having a more API-enabled approach not only brings more optionality, but it brings more observability.

Henry Suryawirawan: Wow. I think that’s, uh, very good.

Stephen Fishman: And Google, like the Google Maps example, Google didn’t just use that for their maps to open up their app. They did that for all the third parties. And that made the whole location based advertising market come to them. Another serial thing that happened because of this unintentional thing from, you know, five to ten years in the past.

Henry Suryawirawan: So if I may summarize from the Optimization through feedback loops, I think the most important thing is to lower down the cost of experimentation, right? So such that you can shorten the feedback loop. Also, make it such that you can run lots of these small experiments, right? It’s not just like you just run a few, right? But having the ability to actually run this as many as possible. And the third one is actually being able to bring time to value. You mentioned it in the book, right? Try to bring value, coming back to the value dynamics thing, right? Bring to the value to the business, maybe to the external users, such that you can have all these iteration and, you know, things that happen at the same time, maybe you’ll end up with happy accidents as well.

Stephen Fishman: This brings up, I think, one of the most impactful things when we were in the process of research was, I remember when both Matt and I were reading Project to Product by Mik Kersten. And there was this thing that just he does so well, which he explains that transformation done in a technology goal context is doomed to fail from the start. And that you have to frame and ground what you’re doing in the context and language goals of your business partners. And if you’re not doing that, even no matter what you accomplish, it just won’t necessarily be sustainable, because they won’t see the value from the approach.

Henry Suryawirawan: Yeah. So all these APIs and all that definitely is, I mean in some companies, right, mostly driven from technology point of view, modernization and things like that. So I think thanks for reminding us to actually also look at from the business lens, right, from organization, from economics point of view. So make the business and tech working together rather than driving this purely from the tech.

[00:45:24] Embracing AI

Henry Suryawirawan: So you mentioned something about generative AI and you know, all these possibilities now. I think in your last chapters of the book, you also cover this about embracing uncertainties. We have gone through different eras, you know, like the first one is like enablement of web, then you have the APIs, you have the mobile apps. You also have cloud technologies. All these are kind of like accumulation of different, different technologies that enables you to do a lot of this value exchange, right? And now is the era of AI, right? So after having the web, cloud, API, and all that. So what is your take about this AI? Will this bring us to something that is even more surprising, more happy accidents? Maybe some take on this.

Matt McLarty: Well, I think, first of all, where we are now, I think one of the lessons the book should teach in this era of AI is focus less on trying to predict exactly what’s going to happen and do what you can to prepare for the fact that anything might happen, right? And that’s, I mean, the lesson there is that’s, that’s why you have an optionality approach.

So I’ve been working with a lot of companies now on their AI strategies. And one of the things I’ll tell them is if we learn anything from history, we know that as exciting and dramatic and mind bending as some of this technology is that we’re seeing right now, it’s going to look quaint in three years. We’re going to look back and say, oh, I remember ChatGPT. You know 4o, that was, that was nice. Remember how it wrote that poem about my cat, you know. Like stuff like that, I’m not disparaging it. It is, it is amazing stuff.

But the rate of innovation happening around the technology means it’s just going to keep changing. Where are you going to get the biggest bang for your buck right now on getting into the AI game? Well, we know that at least when it comes to large language models, if they are going to be used for practical business purposes, they require grounding. They require the usage of your own data, your own unique context to drive the outcomes you’re looking for. So that means you’re going to need to get, be able to easily access your data sources, data resources. And not only that, be able to manipulate them in a way that’s going to shape the right context.

Similarly, as we start getting into this age of agentic AI, which is where we’re headed pretty rapidly, it’s another form of modular architecture, right? Like the idea of, okay, maybe calling the LLM and over and over again is not the approach. If we have agents that are more task focused and we can sort of create the right components, then we can come up with more useful solutions to solve more complex problems. Complexity, you know, the complex systems very much about defining components and interactions and so on.

So if agents are going to be the thing, then they’re going to have certain things that they want to do, how are you going to get those agents to actually execute things? Well, we already can see it in the, if you go out to agent frameworks like LangChain or you go into the different hyperscaler agent platforms, it’s all about these tools they provide. And lo and behold, what are they using to execute functions? APIs, right? So I think that the whole approach that we’re advocating here around driving optionality is probably like a really good investment when it comes to AI, because the AI is only going to be as good as the data that goes into it and it’s only going to be as good as the actions it can execute. And both of those things are really enabled by this highly optional API-based approach.

Henry Suryawirawan: Stephen, you have something to add?

Stephen Fishman: I think about this space quite a lot. And I think one of the things that I find that people talk a lot about AI is how it’s going to eliminate jobs, is I think amongst one of the most common themes. And I said this to, like at a conference the other day, like, you know, people said that about animation, didn’t happen that way. People said that at like, there was like 15 different points in history where people keep saying that. And yet, there’s this other economic thing called Jevons paradox that takes over which is, when it gets easier to actually derive value from a thing, that demand for the thing goes up, not down. And that’s why, like, when they raise fuel efficiency for cars, you actually get more emissions, not less. Even when they reduce emissions as well. You get more at the global scale, because people drive more.

And then so when people talk about in our space about engineering is going away, I’m not so sure. Didn’t happen before. Like I do, I think Steve Yegge’s got a point when.. Funny thing Steve Yegge who took, you know, helped Steve see the world the bit of the Bezos mandate is you know been talking about the death of the junior developer. And I think Steve’s got a point. And what he’s saying, you look, they said the same thing about DevOps. I remember I was in a corporation that had a physical data center and a whole bunch of people. And they were talking about the cloud, they were talking about DevOps, and they were like, they’re coming for our jobs, and I’m like, I think the world is changing, the job is changing, that there’s going to be demand for what you’re doing, just in a different way, you know, on a different control plane for operating things that you’re doing.

And I do believe that AI is becoming great for black ink. Humans are good at red ink. And that, I think that we’re going to see a balancing of, of that. Or at least I hope so.

Henry Suryawirawan: Well, thanks for reminding us again, right? So it’s not about the fear of being eliminated in terms of your job roles and things like that, right? But also it’s a good thing to remind ourselves like I think I find that you can also apply this optionality, opportunism to yourself, right? Like maybe you should also have different options for yourself, new skill sets, learn new kind of like a paradigms. You know, AI is going to open up a lot of opportunities, even for you individuals, right? You can now have kind of like an assistant to actually operate beside you. And I think that’s just going to create a lot more value that you can produce, right? And hopefully one…

Stephen Fishman: Who doesn’t get a second opinion and go into the doctor?

Henry Suryawirawan: Yeah. So I think at the end of the day, maybe you could even end up with your happy accidents, right, by learning all these different optionalities. So I find this book is really, really good for people who, you know, want to learn something new in terms of digital transformation, API enablement, right? I think there’s a lot of science also behind it. So thanks for writing the book.

[00:52:02] 4 Tech Lead Wisdom

Henry Suryawirawan: We come to the end of our conversation. But before I let you go, I normally have this one question, what I call the three technical leadership wisdom. You can think of it like advice for the listeners. Maybe if you can combine both of you, just give us some advice from maybe from your experience or maybe from the book.

Stephen Fishman: My first piece of advice to younger people who are coming up in this industry and doing stuff. Remember, all the work you do is on top of a surface area of relationships and trust. Careers and accomplishments are built on what you do with other people and your teams. And if you don’t know how to keep that in the forefront of your mind, you’re not going to be able to accomplish a lot.

Two, just two, two quick nuggets from the book for two and three. Another great aphorism by Carliss Baldwin. Controlling the interface to value beats controlling the generation of value. That is a big reason why API economies work and why the message of the book really works.

And number three, preparation beats prediction. You can’t predict the future. You can prepare for many futures.

Matt McLarty: There’s great, great points. I would just, maybe it’s an extension of the latter one. But as an individual, curiosity, open-mindedness, and always trying to think about what frame you’re in and trying to step outside a little bit more. I think for technologists, you know, if I look back at my career, probably a lot of the moves I made, whether they’re up, sideways, whatever, were just that, okay, I figured out how to solve this set of problems, but there’s a bigger set of problems to solve. There’s always a bigger set of problems to solve. So trying to keep that open-mindedness and curiosity will take you a long way. And the more you get myopically focused on, like Stephen said, some prediction, whatever it’s going to take, you’re going to be digging so hard under that X, you might miss the gleaming gold off to your left, right?

Henry Suryawirawan: Wow! Really beautiful. So I really like the wisdom, right? So thanks again for sharing it. So maybe for people who would like to check out the book or maybe find more resources from both of you, are there a place where they can find you online, maybe?

Stephen Fishman: I’m mostly socially active on LinkedIn more than other platforms. Social media kind of scares me a little bit. Also Stephen Fishman or Stephen dot Fishman at Boomi. You could get, always get me there. And I love the work that we do. And if you, if you’re interested in the stuff we’re talking about, yeah, please feel free to reach out.

Matt McLarty: And same with me, LinkedIn, Matt dot McLarty at Boomi.com. And we love the engagement on LinkedIn and hearing from people. So yes.

Stephen Fishman: I am offering, for still limited amount of time, offering up free Audible copies on LinkedIn. If you find me and, you find my, you’ll see recent posts. For anybody who’s starting a book club, I’m offering some.

Henry Suryawirawan: Right. Thanks for, you know, all these resources. So again, really a pleasure to have a chance to talk to both of you, Stephen and Matt. I really enjoyed the conversation and I hope the listeners enjoy it as well.

Matt McLarty: Great! Thanks for having us.

Stephen Fishman: Thank you so much.

– End –