Mike Amundsen

All right, here I am, another episode of Breaking Changes. I brought on another friend of mine, kind of going through my Rolodex and finding interesting folks in the API space: Mike Amundsen, who has been a prolific traveler and storyteller in the space. I’ve spent lots of time talking about the API lifecycle, API design, API testing, and a variety of topics with him, but he has spent way more time in front of enterprise audiences trying to understand what their challenges are. So thanks, Mike, for joining us.

It’s great to join you. Like you were saying, we spent a lot of time at various places and locations around the world on various stages over the last decade or so, and I really appreciated the time. I learned a lot. A lot of my successes, a lot of my explorations, really were born out of talks we’ve had together, so I appreciate it very much, and it’s great to join you today.

Well, thank you. I’m building this show on the backs of friends like you who I think we’ve all scratched each other’s backs over the years, so I appreciate your time. In you doing this and working this out over the last decade or so that you’ve been doing this, what is it that enterprises find useful that keeps bringing you back? What grabs their attention as you’ve traveled the world working with them, different enterprise groups?

Well, I’m not always sure, and it’s different depending on different organizations, but I think one of the things that I’ve tried to do throughout all the time that I’ve been in the space, and it goes back a ways, is try to find connections, try to remind people that something has happened before, that there’s someone else working on a similar problem or has a similar idea. So a lot of times what people invite me in for is just to give them a sense: are they on the right path, are they headed in the right direction? For everyone this is a journey, whether you’re a startup or an enterprise. This is another footstep, another footstep, another footstep. So a lot of times the role that I play is literally to say, yeah, yeah, you’re headed in the right direction, and here’s a flashlight, here’s how you can see a little bit further ahead.

On the bigger picture, I try to think a lot about what’s it going to be like 10 years from now, 20 years from now, possibly now even 30 years from now. I’ve been starting to do that. So a lot of times people are asking me questions thinking like, okay, I think I have a handle on today, but what do I need to pay attention to in the years ahead? And again, that’s the same thing: what are other people doing, what are the connections? So I think it has a lot to do with being able to bring other perspectives or other points of view into the enterprise itself, and then give them a handle on what to do, or where to go, or what choices to make next.

Yeah, I think that’s super important. A lot of folks think this is just purely technical, and in reality it’s more human-based, story-based. And as I’ve known you as a storyteller in the space, I think we both spent a lot of time crafting stories, sharing stories, and evolving those, and over the years we’ve both done a lot of traveling to get the word out and do what we do. But what’s the makeup of what you’re doing nowadays between traveling, writing, speaking, and all of that?

Yeah, so certainly the last 18 months, the quarantine era, has changed that quite a bit. I haven’t actually visited a customer location since February or March of 2020 when the lockdown started. So I’ve actually spent a lot more time here in what I call research central, which is my basement in Kentucky, and I’m spending a lot more time writing than I used to. In fact, I’m kind of cutting back a bit. I divide my time between some online writing, some book projects, some experiments that I’ve always promised myself that I would do, and spending time with a handful of customers doing a little bit of training, a little bit of advising. There’s a handful of startups that I spend time with. So it’s really now less in person and more remote, and I’m feeling that in the truest sense of the world, I’m feeling remote.

There have been some recent things that came up, and somebody asked me my opinion on something, and as you just said, so much of this is social and cultural, and I felt a little bit at a loss because it’s been a year and a half since I’ve actually been in an enterprise, been in a culture, been in a group. So there’s been some distance in the last year and a half, and I’m hoping they kind of improve that, but it’s mostly now writing and a little bit of training and some advising.

So when you’re diving in in your research laboratory, when you’re writing books and writing topics, how do you prioritize what you’re focusing on? What helps, what floats to the top as being something important for Mike’s time?

Yeah, I’m distressingly boring about this. There are certain days of the week that I’m working on a book project, certain days a week I’m working on a blog project, certain days a week when I’m working on a coding project, and then they bleed across. So I might do a little bit of coding every day, but this is the day when I’m really focusing on a coding project, or this is the day I’m really focusing on a blog article. And what flows to the top to me are two things. I have long lists. The list of blog topics just goes on forever, like I could just sort of pick. So there’s always something in there.

When I write books, I’ve joked more than once, when I write books there are a lot of things that don’t make it into the book. They end up in a file, a folder called gutter. It’s like they’re in the gutter, like the cutting room floor in a movie. I have whole books that are just from the gutter material. So sometimes when I’m thinking about writing longer form pieces, I actually go to the gutter, I go to the things that got cut out of a book, and that’s a long form article, a medium or a longer piece, several thousand words. So a lot of times that’s what bubbles to the top.

In terms of code right now, I usually end up just picking a passionate project, something I’m really passionate about. And right now I’m very passionate about this idea of command line interfaces for the web and for hypermedia. I’ve had this thing in my tickle file for more than five years, maybe seven, and I’ve finally, I’ve been hinting at it and talking about how it could be done and what happens is nobody’s interested. So I kind of go, well, all right, I guess I’m going to have to do this. So right now I’m working on this idea of a kind of a hypermedia REPL, a kind of a stateful engine that lets me interact with APIs in a command line interface, and it’s scriptable. So every week I’m spending at least one day working on that, and that actually bleeds into other projects too. It’s actually affecting my writing as well. Once I realize, oh, that’s what it takes to do that, now I have something to write about. Like if you’re writing a client app, this is what you’re going to need from the service, or something like that. So they kind of bounce off each other.

Yeah, I have always valued your deep thinking on subjects, and I find your writing tends to go into areas that I don’t think always are going to get paid and be funded by the enterprise organizations that I work with sometimes. But in the long haul of things, there’s some serious value to be extracted in mind there from the work you’re doing, whether it’s specification based, or whether it’s how you approach design, or testing, or other things, and then thinking outside the box at the command line level. I think it’s super relevant right now, whether your direct hypermedia project is the thing or how do we use the command line in a more meaningful way. So I’m always happy to see what you’re bouncing on, and I would say I’m a kindred spirit in the same way, finding interesting things that keep our brain going, so I’m thankful for that.

But you’re known for API design, and I want a lot of deep thinking in that area, and I want to dive in there. But first I like to look at the personal side of who you are and set the stage. So this might be a little weird, but are you related to the famous explorer Roald Amundsen? Are you a family member?

Okay, so the cagey answer is, we suspect yes. Here’s the thing. I remember as a small child when I was spending time with my grandparents who at the time were living in Yellowstone. My grandfather was a park ranger for Yellowstone National Park in the 50s and 60s. I remember spending time with them. There were pictures of Roald Amundsen, there were dog traces and snowshoes, and I was told, I remember being told, that they were artifacts, items that they had kept from Amundsen’s experience. Now whether I’ve sort of manufactured that, you know how I was, like a kid, six, seven, eight, something like that, whether I really manufactured that or not, I can’t really tell you.

I have actually spent a bunch of time learning about Roald’s life, and I know that officially he was never married, so if I’m related in any way it’s going to be indirectly. He had two brothers and I think two sisters, so there’s probably some connection there. I act as if I’m a Roald Amundsen descendant. In other words, he had these kick traits about him. He was always thinking ahead, he was always ready to adapt, he was always trying to learn something from everybody around him. He was also a bit of a pain in the ass, which people would probably tell me is probably right. So I’ve adopted a lot of that persona, but whether or not there’s actually any real corpuscles in here, we don’t really know.

Well, what I like about that is the storytelling aspect and how we kind of fabricate these things in our heads and believe them, and how they get introduced to us, and whether they’re true or not, but then they become true. I think that’s, for me, like how API knowledge is passed down as part of the API lifecycle within enterprise organizations. There’s a lot to extract from that. So another vein I’m always trying to touch on, because I always want to try to get other folks into our industry and make what we do accessible: how did you get into APIs and computer stuff? Are you classically trained in computer science? How did you find your way?

Yeah, no, I’m definitely not. I have no degrees in computers or mathematics or science. I do have a couple of degrees, but they’re in music composition and theory. I was an arts major as a matter of fact in high school. When I had to go to college it was a real toss-up between theater arts and music, so that’s where some of this sort of story and demonstrative ideas come from. I think it’s kind of always been in me. So I stumbled upon computers because I’d been spending a lot of time as a musician writing, back in the day you wrote local jingles for stores and stuff like this, and I was writing a lot of music. My younger brother-in-law, I think he was like 13 or 14 at the time, got a TI-99 computer for Christmas and didn’t care about it at all, one whit, wasn’t interested, and I was like, huh. And the first thing I did, of course, because me being me, is I figured out how to program it to play music. I actually had some MIDI interfaces, so I got it to actually play sounds. Then I got hooked. So I started using it more and more.

Then I was working in an arts organization, and I helped a bunch of artists collect up their information. It was actually a visual arts group, so all of their items that they had been on show and where they had been. And then I got involved in the Ohio arts organization on their mini computer system, helping them design an information system. I just kept building from there. So it was just by happenstance, it was that bridge from the music world into the computing world, and since then I’ve always sort of brought that creative artistic muse to the way I think about computers and the role that computers play in our lives, and that affects a lot of the things that I get interested in in the API world.

So for me, APIs are a way to establish a framework where other people can collaborate together, and that’s a lot like the way I would play music. We would all have the same basic chart, which you can think of as like the OpenAPI document, the thing that explains how everything relates, and then we all play, which you can think of as different client applications, sort of in concert together. So in very much a sense, APIs are really interesting to me because they’re a collaborative space, a space where lots of people can get involved. I use the phrase, I think you’ve heard me say this often, when you create an API as a producer, you’re helping people you’ve never met solve problems you’ve never thought of. You’re creating this sort of solution as problem space, this domain where people can be creative, and that relates to a lot of that music background that I had that goes back so far.

Yeah, I think that’s such a valuable background, and setting the stage for where you’re at. And the other aspect that I know you for, the storytelling piece, I get a lot of pushback on this one, being a storyteller and really pushing the value of it. Now this show is targeting business leadership, engineering leadership, and in a lot of those circles I’ll get pushback that storytelling doesn’t matter, it’s not something that’s going to generate revenue, it doesn’t have that direct value sometimes. Where I are you many, you know, very differently. How would you convince leadership that your brand of storytelling matters on the ground?

Yeah, I’ve definitely had similar conversations. I think probably the most direct way that I can relate to this is, I spent a good deal of time in Scandinavia because I have Scandinavian roots, I have connections to companies in Sweden and Norway and Denmark, and I’ve worked at several of them over the past decades. And there’s a habit, a pattern in the Scandinavian countries of always keeping the company’s history. There’s a person or a group in charge of keeping the company’s history, and that’s what they call the saga in the language, the saga of the company, like where we started, where we’ve been, where we’re going. And that is storytelling. So a big part of cultural organizations in the Scandinavian world, and I think it’s probably in other places too, but it’s the one that I learned from, is that every company has a story, and continuing that story and relating that story is how you teach culture, and culture is how we do things here. Whatever your culture is, that’s how we do things here.

And how do you tell people how you do things here? Most often it’s not because you handed them a book, it’s because you told them a story. Well, we do it this way because when Mike was first here, he had read this book and he thought this was the greatest way to do APIs, so now all our APIs are that way. That’s not a technical thing, that’s a story. And I think stories become super important for customers. That’s why we have advertising, right? There’s stories, they’re little mini stories. So while there are lots of technical elements, it’s not the technical parts. Everyone has the same technical parts, you have the same access to the same technology that I have for the most part. But what makes us different, what would make my company different from your company, is the stories, the stories we tell each other and the stories where we come from and where we’re going, and that becomes the advantage element.

And then finally, stories are how we remember. You and I talked about this a long time ago, like more than a decade ago. I think I was super frustrated that I was giving very accurate technical talks and boring everybody I was talking to. It wasn’t making a connection, and you started telling me about this notion of being a storyteller, and typical for me, I just go nuts on it and I say, okay, great, we’re going to tell stories. So I started to incorporate stories in what I do as a way to help people find a hook, find something they remember. A joke is a story, an anecdote is a story. Jeff Bezos has dozens and dozens of stories that we connect to. Marc Andreessen has stories. Elon Musk has stories. So it’s how we communicate, and so I try to remind folks, stories are inescapable, we might as well use them to our advantage as much as we possibly can, and that’s what I try to help people do.

I couldn’t have said it better, I can’t add to that at all. That’s exactly my argument and why storytelling matters. So let’s dive in to the not quite the technical, but you’re really known for your knowledge in the area of API design. You’ve spent a lot of time thinking, you’ve written books, you’ve done lots of talks on the subject. Why does API design matter to business?

Yeah, so you’re right, I’ve spent a lot of time on this, and I’ve spent a lot of time on it because of this idea of connections. Remember I talked earlier, connections are sort of what drive my work. How do we get connected? And the API is the connection. You can think of the API as the packaging for your product. From a business standpoint, it’s what people see. If you’re in this virtual world where you’re delivering virtual goods, the API becomes not only the package but then it also becomes the transport, it becomes the persona that I know your company by. A company that does a great job of using this notion of know us by our API and connect with us by our API, the one that I often use, is Twilio. They built a great brand out of the notion that we understand your developers and what they need.

So what I think is really key in all of this is, if you can master the notion of design all the way to product design. We’ve been designing products for centuries, we can design products in the virtual space just as much as we would design products in the physical space. So if you can master that notion, or at least adopt that kind of idea, then you’ve got a real opportunity, because that means you’re trying to solve a customer problem in a business viable kind of way. So it’s not just that you understand the customers, but that you can deliver for customers, and interfaces are the way you do that. And the I in API is interface, application programming interface. We know this from UIs: you put the button in the wrong spot, people can’t find it. If you put this button too close to that button, they do the wrong thing and they blame you. So the same thing happens for APIs.

As a matter of fact, I just recently have been revisiting the notion of information architecture from Morville, his book Information Architecture, the polar bear book from O’Reilly, and using things like tree testing, where when they were designing websites they would literally say, okay, you’re at the home page, tell me how you would find the contact information to send an email. And then there’s this test pattern where you literally pull down what is available from this home page. Oh, it says About Us, let me try that, and then it tells you what’s available from About Us, and it says Contact Us. Oh, you click Contact Us, and then it says, well, you can do email or phone. So designing APIs like that, how do you get to checking out your shopping cart if you start from this spot? Make some assumptions. A well-designed API, your developer is going to be able to make those kinds of steps, and more often than not they’ll be correct, and they’ll think your API is great, and that’s because you’ve done some design work for your audience.

And by the way, the audience of a bunch of C++ developers that have advanced degrees is very different from the audience that works in JavaScript in a startup, or in the spreadsheet in an HR department. So designing that solution for those different audiences means you’re paying attention to each of them, and that’s what I love about the API space. I can package the product differently. It’s in powder form here, it’s pill form here, it’s liquid form here. Whoever needs whatever is convenient, I can reach that audience, and to me that’s why design is so magical and so powerful. I can help people design what their customers need, and those customers might be the team across the hall, might be the subsidiary in another continent, and it might be a customer in somebody’s house.

Yeah, the API, depending on trying to reach your audience, what you’re trying to deliver with your product or services. Why did the current incarnation of web API or REST API, whatever we choose to call it, why do you feel that it’s so dominant in how we approach and do APIs right now?

Ah, I have to say I think it’s absolutely pragmatic. It’s one of the easiest ways to solve the problem, one of the easiest ways to distribute a product, one of the easiest ways to get a website up, to get a service up and running, to get connected to somebody else. Because we had other things before this. We had The Source and we had CompuServe, and Microsoft had a thing for a while, I can’t remember what that used to be called. There were these sort of closed systems, and we had AOL and all these other things, but they ended up eventually giving way to this sort of World Wide Web, this sort of anarchic space where anybody could post anything anywhere without asking permission from anyone. I could just put a server up, I didn’t have to subscribe to AOL or Microsoft or any of that.

So I think it’s just pragmatic. What happens is people are creative, and necessity is the mother of invention. Okay, so we got HTTP, I can set up a server without bothering anybody, what can I do with this? And then figuring out how to turn this HTTP protocol into something that makes sense for enterprises, for businesses, for organizations. The whole adopting of the create, read, update, delete pattern, what we call the CRUD of API, the resource, the technical resource aspect, that’s just an invention that’s slapped onto HTTP that has nothing to do with the specification or what it was designed for, but it works. The people who built those initial specifications for HTTP really made great choices, and the people who directly follow them make great choices. So this is a super flexible space. I think it’s just, this is the easiest way to do this, let’s get going, let’s get started, and I like that.

Yeah, I think a lot of people felt it was accessible. A lot of programmers were like, oh, this is something I can relate to, I can understand. The cognitive load of getting up and going isn’t too heavy. But I think a lot of folks still see API design as very coupled with the domain or the path and HTTP. Is that API design, or is there a much bigger world that people should be thinking about?

Well, it’s yes to both. That certainly is API design, but we can design APIs for MQTT, we can design topics and messages and events, we can design queries in GraphQL, we can design function pieces with gRPC or Thrift or whatever. The implementation is just part of that cycle of design. The way I talk about design in my training with organizations is I always want to put off the implementation to the last responsible moment. That’s a Mary Poppendieck phrase, put off that decision until putting it off any longer would be irresponsible. I want to write code last, I want to try to avoid it, I want to make sure I’ve got the audience right, I’ve got their needs right, I’ve got the accessibility that you talk about correct, and then we’ll pick the format, we’ll pick the protocol, we’ll decide if it’s going to be gRPC or GraphQL or whatever it’s going to be later in the story.

And in fact, try to make a design that allows us to change our mind later. We might build an HTTP resource-based implementation of that design and then suddenly realize what we really need is an event-driven architecture, but we can use the same design, we just implement it differently. So I think there is a wider picture, and I try to remind people, we’ve had HTTP for about 25, 30 years, and at some point there’s going to be something else, and that may be five years from now, maybe 10 years now, maybe 20 years from now, and I want to be ready for that something else too. I want to have my design chops and my skills and my ability to apply a solution flexible enough that when it comes time to do it in another space it’ll still work out. So I think design is everything we’ve learned from products in the physical world applies to the virtual world as well, and HTTP is one of those spaces.

Yeah, I like how you put it, because it reflects how I see design. It’s thinking long term, it’s planning, it’s having a strategy, it’s being thoughtful about where we’re at, where we’re going. But design is still very, there’s plenty of folks who think that it’s not always necessary. And I would say in the last five to seven, eight years it’s got more traction, and a lot of people, there’s concepts like API design first, where people are thinking about it before they ever write code. But I would say that the dominant paradigm, if you talk to the average enterprise organization that listens to maybe Gartner, is that API management is what you do. So shifting from design, what is API management, would you say? What does it consist of? Because I think there’s a lot of different definitions of that.

Yeah, there are a lot. So I and a few colleagues have worked on a book called Continuous API Management, we’re actually finishing up the second edition now, and one of the themes in the reviewers and the people we shared the first edition with, and now that we’re sharing early editions of the second, is what is the real definition, what are you really trying to tell us? There’s still some kind of confusion, and typical for I and some of my colleagues, we don’t really want to come down and like just one definitive thing because we want this to last. Definitions change. One of the things that’s come out over time, we really have come to the conclusion in this project that API management is about making good decisions at the right time, and that’s really what management is. If you think about management in the sense of any kind of organizational management, you want to get resources in the right place at the right time, you want people to be skilled up in the right way at the right time, you want to be able to respond to a problem if it comes up, you want to be able to plan ahead, have a horizon, give people time to experiment, you want to be able to connect with your consumers, whatever that is, and you want to nurture your overall culture.

Those are all things that we want to do in any organization, and that applies to the API space as well. You want to plan ahead enough, like we were saying where technology might change. There’s a line that I’ve used frequently: while the technology changes, lucky for us the problems are still the same. So we’re working with the same problems we were working with 30 years ago, it’s just that we have different tools. Sometimes that makes it easier, but you have to do all those things. I need to be ready to respond, that means I need to design a system where I have some observability so I can tell if something’s going on. I need to be able to upskill people, it means we need to have some processes and ways to help people design the systems they need in order to solve the problems they have. So I think API management is just like any other kind of management, it’s just applied to this virtual space, and I think we learn so much from all the other aspects of management, whether it’s physical manufacturing or things like team topologies. They all apply to the same thing in APIs. To me it’s just one area that seems kind of interesting, and that’s the one that I focused on.

Yeah, that’s what I like about the book Continuous API Management, is the continuous part. A lot of companies that I work with are like, well, we’ve got to do API management, have we done API management yet? We bought Apigee, MuleSoft, or whatever, check, we’re done, right? Yep, we’re done with management, that’s been taken care of. And it’s like, no, this is a journey, this is ongoing, this is continuous, and this is more about the human aspect, the organizational aspect.

Is API management something that business users should care about, or is it just developers?

Business users should care about it the same way they care about product management, the same way they care about market management, all the other things, because they affect the business. APIs, in the way that I talk about it to customers, APIs are the vector for your business. The APIs don’t exist because they exist, they exist because you have a business and there’s a business solution to solve. So that business grows, that business evolves, the market changes, there are these arcs of maturity, and the APIs play into that as well. You want to invest in the APIs that are going to make a material difference to your bottom line, you don’t want to spend time on APIs that don’t make a difference, you don’t want to spend time on APIs that actually hurt your bottom line, you don’t want to release a product that cannibalizes some other major product that you have without thinking about the implications first.

So in that sense, just like product management, whether you know what material you’re working with, whether it’s metals or paper or liquids or chemistry, you’re going to need experts, you’re going to need engineers, you’re going to need people who understand the technical details, and those folks need to spend the same amount of time on the business aspects too. So if I’m running a business, I need to understand what’s going on in that API management space. That doesn’t mean I need to be in charge of it, I may need to get an expert, but it’ll affect my bottom line, then I need to be paying attention.

Yeah, and one of the areas, as I work with different enterprise orgs at Postman, one of the areas, because Postman is known as a testing solution amongst other things, when I talk to leadership and they wake up to the potential of Postman, they’re thinking about quality because they realize it’s a journey, they realize they’re needing APIs, they’re producing a lot of APIs across many teams, and the quality isn’t always the same across all of them. So when it comes to the quality of APIs, and thinking, this show’s for business leadership, what should folks be thinking about when it comes to helping ensure quality and consistency across teams?

Yeah, one of the things I talk a lot about when I talk to companies is process is pattern. When you think about Andy Grove, he needed to drive quality into creating microchips. They were very expensive, you would create hundreds of chips on the disk, and if you screwed that disk up, all those chips were no good. It was very, very important. So that whole total quality management culture in the 70s grew up out of that space. So what you need is a process and a pattern and consistency. There are times when you need to be creative and there’s times when you need to be automated. Creative is when you’re designing that chip, when you’re designing that API, when you’re designing that interface for users to develop. When you’re coding it and building it and releasing it, you need to be automated, mechanical, and predictable every single time, and the way you improve quality is by driving out variability in the system that you’re using to manufacture whatever that is.

So once you have that design document, once you have that OpenAPI spec or that RDF ontology, whatever the thing that’s driving that first piece, now it’s time to start getting your process in place. So quality is about driving consistency, is about driving out variability, and once you drive out variability in your process model, now you can start focusing on the tiny things, on the smaller things. So this whole idea of site reliability engineering and chaos engineering is a way to start poking at your existing process and your existing output, and that’s stress testing. We know in physical products we will stress test an item, we’ll put enough pressure on it until it breaks to figure out where it breaks, did it actually meet our quality specifications. That’s what SRE and chaos engineering are doing, they’re stress testing until things break. Netflix has a great history of helping people understand how to start building these kinds of systems.

So the way you drive quality in is driving variability out, and I think a key way to do that is to separate that creative activity from that engineering repeatable activity. And much of DevOps is all about creating that consistency and driving variability out of that whole process of check-in and test and build and mount and release and all that. So when I talk to companies, I say if you want to be able to increase quality, drive out variability, add consistency, and then start to manage that process. And really, when you look back all the way to Toyota, Deming, and Shewhart and all these other people who are helping redesign manufacturing in the late 40s and 50s and 60s, they were doing the same kind of thing. That’s what observability is all about, really, to me, if that makes kind of sense.

Yeah, observability is being able to observe based upon the existing output, so having a management process, having an awareness of your overall system, is pretty key to that. And so how does design fit into that? How does design fit into laying the groundwork for what you just described?

Right, design can really benefit from the same kind of process engineering as well. A design process that includes interviews: have you done the interview, have you talked to the stakeholders? Do you have a story, write an API story, do you have a short story that explains what this API is for, what it manipulates and what it does? Now have you produced a diagram that actually shows what the workflow processes are for that? Have you produced a vocabulary document and matched that vocabulary document against the company’s vocabulary documents, so you know that when you release this API it’s going to be able to speak to other parts of the system relatively easily? Do you have a definition document, like an AsyncAPI or an OpenAPI document, that’s going to be the blueprint that people can use? So there are all these assets that you have to produce. There’s a build, there’s a DevOps pipeline, there’s a build pipeline for the design process as well: sketches and prototypes and assets like diagrams and documents and definitions and stories and interviews and wireframes, they’re all part of that process.

If you try to bring a design, like a blueprint, to my creative developer team and you haven’t done all these other things ahead of time, I’m going to stop you. You need to finish the process. That’s how you get drive variability out and quality in. And none of what I talked about had to do with color schemes or sizes of fonts or whether or not the URL has a question mark. Those are implementation details that are going to be decided by the technology and the style that’s required. But the process of all those other things, that’s how design can become consistent and manageable too, because now I have a dashboard. I’ve got five design teams working on 10 APIs, and I know they’re on the vocabulary phase here, they’re on the description phase here, they’re on the interview phase here, and that’s another observability dashboard that helps me with my continuous management.

And so all of this, this is something now in 2021 every company is dealing with, this isn’t just a tech company problem.

Oh yeah, healthcare, insurance, banks are dealing with this.

And one way to describe this that’s been thrown out, and we have a lot of phrases we use in the space, but digital transformation is one that has stuck with us and seems to be continuing and having traction over a long period. Is it meaningful in the organizations you talk to? Does it actually translate into real things happening, or is it just marketing and hype?

Oh, it definitely can translate into something meaningful, and I use the phrase, I tell people you can get a hold of transformation. What I tell people is, things are transforming around you while you stand here. The market is transforming, the customers are transforming, the playing field is transforming, so you can have transformation happen to you, or you can actually start to take a hold of that transformation and try to get ahead of it and make it work for you. So I definitely think transformation is important. The buggy whip industry got transformed right out of business, but if you transformed yourself from a buggy whip company into a transportation encouragement company, there’s lots of other possibilities, suddenly now you’re selling motor fuel and things like this. So you always have this opportunity.

So I think digital transformation is important. Now the digital side of it, I was just talking with some customers about it this week, what is digital, what’s digital about all this? I think it is this notion of having access to this virtual world. We can collect so many things, we call them KPIs and OKRs, using some of the same background from Andy Grove which we were talking about earlier, objectives and key results and key performance indicators. We have so many more metrics at our disposal than we did before, and it’s free, it’s cheap, it’s easy, there are syslogs everywhere. So you can use that kind of information to monitor and manage and transform things. I can pay attention to things at a scale I didn’t in the past. So I think transformation is really easier than ever. You can still ignore it. There’s a quote, I can’t remember what it was, in business transformation is an option, but in life it’s inevitable. So you have to kind of decide where you are on that. So yeah, I think transformation’s super important.

Well, and I think it’s one of the most effective carrots, well, I would say sticks also.

Yeah, folks don’t want to become irrelevant.

You don’t want to be that buggy whip manufacturer that’s like, I’ve been doing this my whole life, my father did it, I’m going to keep doing it. You’ve got to be able to be flexible, you’ve got to be able to adjust, and in a digital realm the velocity is significantly quicker as far as that change is concerned.

Yeah, yeah. So I feel like distilling things down into meaningful phrases so folks can get on board, specifically business as well as technological, so from a technical side digital transformation may seem like it’s not as meaningful, but if we can come up with a kind of a circus tent that we can all work under and come up with phrases that are meaningful, digital transformation is one, because it encompasses a lot of the things you talked about, across design, across management, across quality, that I think developers can get on board with as well as business folks. And then I think it enables the type of storytelling that you talked about earlier, it allows meaningful business stories to be shared and told: why we’re doing this, why it matters, and helps us get there.

So when it comes to doing this on the ground, where do organizations need to start? This is a silly question, I feel like, because folks are already on their journey. Everybody I talk to, I get this question, well, where do we start with digital transformation, what should we be doing? Well, you’re already doing APIs, I can guarantee that, you’re just probably not doing them with a strategy. So what are your recommendations when someone asks you that question, where do I begin?

Well, I’m pretty sure this is Adrian Cockcroft’s line. Adrian worked at Netflix, he was their cloud CTO, I think he might be at Amazon now, I’ve kind of lost track of where Adrian is. But the quote that I like from Adrian is, when he was trying to do this transformational work at Netflix, because they were completely a business that mailed DVDs and suddenly they had to transform into a streaming business, that’s a big leap, and he said, we would look for the smallest thing that we could change and learn the most. What’s the smallest thing we can change and learn from? Let’s go do that. And then they would do that, and then they would say, well, what’s the next smallest thing, now we’ve learned that, what’s the next smallest thing we can do? And they kept building upon building. I like that story because it really is based on the notion of taking a step. The old journey begins with the first step kind of thing, that’s a story that resonates.

Often I tell organizations, whether they know it or not, they’re already in it. You can’t be outside the system, you are the system, this is the system. You can alter the system if you think it needs to be altered in some way. Go find some space. I typically would tell organizations find some non-critical, non-trivial thing to start with. In other words, you’ve probably got something that’s internal reporting or internal process modeling that isn’t going to directly affect your production line, it’s not going to knock all your products off the shelves, and you want to start there. And then you need to find some willing co-conspirators, find some people in the organization that are willing to take a risk, willing to take a chance to try something new, to learn something new, and then set them up for success. Say, okay, you’re going to work on this thing that we haven’t worked on for several years, we don’t really know what it’s going to be like yet, but here’s the tools, what tools do you think you need, here’s the mission, this is what you need to do. And then time box everything. We know from personal experience that time boxing works, whether you’re working with a little timer, or where they’re in a large organization, time box for 30, 60, 90 days, and give people a chance, use the lean method.

So I usually tell people start to change something somewhere, and then the big thing is you have to realize when you change that it’s going to pop out over here. It’s a system. So when you start making changes, it’s going to affect somebody else, they may or may not like that. Why is Mike’s team coming in at all hours working in some garage somewhere on some project that we know nothing about instead of coming into my team? Why is it suddenly they get to use DevOps tools and I don’t get to use DevOps? You’re always going to have other aspects of all this because you’re in a system. So poking at the system means things are going to happen somewhere else. But if you take it a step at a time and don’t do what I call big bets, it’s not Texas Hold’em, it’s not all in, we’re going to be a totally transformed company by the end of the year. Don’t do that. Step by step by step. And then, which is something that you started this conversation with, then you realize that you’re always taking the next step forever. We’re not done with change management, we’re not done with transformation, we’re not done with APIs, we just keep constantly taking another step. That’s our job, that’s what we do, and to me that’s the fun part.

You’re perpetually learning the system, you’re perpetually understanding the dependencies within the system, you’re identifying, hey, look, we can measure this output and understand, and you’re evolving observability by poking, and soon it just becomes natural, this is how we do things, this is how we work. And that’s the important part of digital transformation, it’s not like, okay, everything’s converted to digital, now we’re transformed. I joke up on Twitter about that a lot, where it’s like, I feel like I’m done with my digital transformation. What I’m trying to get at is this is a journey where it’s nonstop, but at some point you’re going to feel more comfortable in your skin with change and you’re going to be able to do this.

And I think in this era right now, especially with COVID and coming out of the pandemic, I’ve got some guests lined up for future episodes where we’re going to talk about remote first as a theory, you know, to build on API first, remote first, and talk about how APIs evolve or impact how we run our businesses, and whether everything’s got to be done in person or everything can be done remotely. So it’s shifted our behavior. Kind of looking forward, how has the pandemic impacted you? You mentioned a little bit about your travel and whatnot. As far as your advice and the stories you’re going to be telling and the advice you’re going to be giving when you’re consulting, how has it shifted?

Well, it’s definitely shifted away from me being there in person. Two years ago, if I was going to teach with you, I would travel, I’d travel there a day ahead, if it involved an ocean maybe two days ahead, I would spend several days with you to make sure that it was worth the effort, and then I would spend another day or two getting back home. So just visiting with one company would really be a week’s worth of activity. Now, locally here in the States where I am, I could probably leave on one day, do a day, and leave on the next day, but that was a big investment, so that limited my reach in a lot of ways. There were a lot of organizations that could not afford that. But now I can talk to someone for an hour or two, and there’s still prepping, but that prep is no longer in days, it’s in hours. So now I can reach organizations that I was not able to reach before and interact in ways that I was not able to interact before, and that includes not just teaching or lecturing, but it also means listening. So people can bring ideas to me, challenges to me, things they’ve been working on that it would have been very expensive for them to do before. So it’s really changed the way I think about what I can contribute and what I can learn from people. I think it’s a lot easier now than it was two years ago.

At the same time, I know from all of the training that I’m doing that I’m missing a piece when I’m face to face. I was just reading some studies on how different parts of the brain activate when you’re in person versus when you’re looking on screen, and those parts of the brain that are activated are super important. So I have to figure out how to balance this better. I used to be balanced way on the side of being in person, I spent the last 18 months being balanced way on the side of being remote, and I’m going to have to figure out how to mix that. I’m not sure yet, it’s going to be a bit of a challenge for me. So I think that’s a thing that’s changed a lot.

I think one of the things we talk about, the great resignation and the way people are looking at things differently, is I think a lot of organizations, a lot of enterprises I’ve talked to, have realized there are definitely things that we don’t need to do in person. Some of them are saying there are definitely things we don’t need to do, right? They’ve suddenly realized, I did it because we were here, we were physically here, it was fine, it wasn’t a big cost, but now it’s a big cost to do. So I think organizations up and down are given the opportunity now to rethink, just like we thought about before, what the management style is, what’s creative and what’s automated, what’s process that we want to drive variability out of. A lot of times those processes that we want to be repeatable and non-variable, they can be done remotely, they can be done through builds, they can be done through scripts, they can be done through tooling, or they can be done through a kind of face-to-face activity that doesn’t require a lot of interpersonal creativity. But designing a product, meeting with a customer, understanding your audience, making a real connection with investors or with some of your key customers, that still means physical approach. So I think we’re going to have another chance to redefine that space, and I’m going through that as an individual, and I see enterprises going through that as well. How do we start to adjust, what did we learn, and what’s that going to mean for us improving the experience for everyone involved, whether it’s customers or members of the organization?

Wow, yeah, it feels like an opportunity for me to reassess all of this and try to think through these processes, and it’s going to benefit our digital transformation overall to be able to pick things apart, rethink things, understand where our priorities are, reassess and understand where the value is. It’s not just about saving money, but as you said, we could double down in some areas that reinforce, all right, we’re losing this face-to-face as part of this, but here’s how we can compensate for that. And hey, in these processes we have to have the face to face, and here’s why, we’ve identified it’s super important.

Yep, and I think the same thing we were talking about earlier about this idea of observability as part of management. I’ve seen enterprises really take this by the handle and say, well, let’s set some OKRs, KPIs, let’s set some metrics on what we think a good process is, or a quality experience is, or good self-care for employees when they’re remote, all these things, let’s pay attention to this, and let’s make sure we don’t over rotate, let’s not miss the important elements, let’s not just throw darts without paying attention. So I’m also very encouraged that the last several years here in our tech sphere of being able to observe, being able to quantify and add that as part of our decision making, is going to also let us quantify this remote and in-person experience. What’s it like for me to sit here with the lights on at my screen for a certain amount of time every day, and start to rethink some of that as well, so that we really do take the positive step forward and not a negative step backward in terms of missing the bone and finding out that we’ve lost the handle on connecting with our colleagues, with our employees, with the people that matter the most to the success of our products. So it’s a combination of all those things, and this is not going to be without pain. There are things that I lose out on, there are things that I don’t get to do because I’m not there, and that could be troublesome. There are jobs that maybe some people in the organization, that I used to be dependent upon to do, but now that’s been automated. All of this is going to play out, and we need to make sure we’re very clear-eyed about how we’re going forward, and I think it’s a great opportunity, and with great opportunities come great responsibility.

Wow, I think that’s probably a good note to end or ramp down on here. I think that’s great advice as we exit, or hopefully we’re emerging out of the pandemic here, and into a new world. It’s not going to be like it was before. But rather than just ending on a business note, I like to take it back into the personal realm. I’ve done a lot of traveling with you, I’ve hung out with you on a couple continents. What country do you miss the most traveling?

Man, that’s a terrible question to ask, I’m going to upset someone. Every time I do this I think, oh, I really liked it there, I really liked it there. Here’s what I miss, this is going to sound goofy, but here’s what I miss. I miss Scandinavia in the winter, and I miss the Mediterranean in the summer. Those are the two things that really strike me. I have such great experiences, and they relate to this sort of seasonal nature. Now what strikes me when I say this is I name two Northern Hemisphere places. I’ve spent a lot of time in Australia as well, and a little bit in New Zealand, and honestly I miss that just about any time. I can conjure up a wonderful place in the Southern Hemisphere for almost any time of the year, same for Brazil and Argentina, Uruguay, Colombia. There’s all these amazing places I’ve been so lucky to be able to travel to, to even have this kind of thought, this kind of idea. I miss some aspect of just about every place I’ve been, and that’s kind of, I like that I can recall things and say, yeah, that was very cool when I was there. Really kind of a cop-out maybe, but yeah.

No, no, I think you took it in a good direction. So one more personal question to really get at the core of Mike, I would say, and back to your roots as a musician. What song impacted you and who you are the most as you were growing up?

That’s tough. So I grew up as a young kid in grade school in Illinois, in the Chicago area, and my father was a tenor saxophone player in a dance band, sort of a jazz band. So I grew up listening to jazz music, jazz musicians, Miles Davis, Charlie Parker, all these other people, when I was a kid. When I moved in high school, I moved to Michigan, now I get to listen to Motown, Berry Gordy, I listen to the Sound of Philadelphia, Gamble and Huff, Quincy Jones, there’s my connection to jazz. All through my school life, if I go back into that, and I’m getting chills just thinking about it right now, there was all this kind of music that ranged from popular music, and it was really categorical, like the Motown sound, or the Sound of Philadelphia which was highly produced, or jazz sounds. I watched a lot of movies and television because I was going to be in musical theater, I sang musicals all the time, so all these dorky 1940s, 1930s musicals. One of my favorite musicals was The Music Man, which is a goofy musical about a guy, a shyster that comes to town to sell everybody instruments he has no idea how to play, which is sort of a scary metaphor for what I do when I come to an enterprise. But all these things just play in my head. So I guess I would say when I was in high school, it was totally because of where I was, in Michigan, it was Berry Gordy, but also Gamble and Huff, the Spinners, the Stylistics, all those kinds of groups, those really made a difference.

Nice, nice, I love that. Well, thank you for your time today. I’m really stoked to have this conversation with you. I always love talking to you.

I always love it, yeah.

We have API Storytelling, which is another kind of series we do on Fridays, I’ll give a little plug there. What’s, when’s Continuous API Management going to be coming out again?

So it’s slated for the fall. We’re in final edits now, we got lots of reviewer comments back, and as usual we’ve got some fantastic suggestions that are going to be painful to do, so we’ve got a couple of months of editing to do, but it’ll probably go to production sometime in August, and then it usually takes several months to go through the production process, so this fall is when we’ll get the Continuous API Management book out. I’ve already started working on a new book project, I’m just going to take advantage of you here, for early to mid 2022, and that’s going to be another very detailed project, it’s going to be a recipe book or cookbook on distributed application building on the web. So I’m just starting to get started on that. So in the fall we’ll get the second edition of Continuous APIs, and then hopefully within six months or so there’ll be another book on web. I’m sure it’ll have the word RESTful in it if I have a shot at it, so it’ll probably be something about microservices and REST and something something, but I’m excited about that, I’m having a lot of fun building it already.

Nice. Well, looking forward to it, and thanks for joining me, sir.

Always a pleasure.

Good to see you, take care of yourself, stay safe, and I’m looking forward to seeing you next time.

All right, thank you.