APIs Unplugged is an API podcast series hosted by Matt McLarty and Mike Amundsen, where they deep dive into business strategy, integration architecture, and predictions for the API economy. In each podcast, you'll hear from Matt and Mike as they share their perspective on the latest technology and API trends and topics and gain additional insights from their special guests.
In Season 3, Episode 2 of APIs Unplugged, we're joined by global API community leader and writer Matthew Reinbold as he shares his experience using APIs to deal with complexities, his perspective on systems thinking, and the qualities of a high-performing API organization.
Note: In the write-up below, all questions will be in header format and asked by either Matt or Mike, and all paragraphs are responses from Matthew.
Tell us about your journey into the world of APIs
My journey is closely linked with the rise of mobile — mobile computing, mobile devices, and the like. Even before the iPhone, around 2007, we had these miniature computers that we started carrying around, and we needed to get data to them in various forms. At the time, you could be a full-stack developer and say that with a straight face.
I was a full-stack developer doing web development and web design. I started having clients asking, “How do we get stuff to the device?” or “How do we make more compelling experiences for people on the go?” and that's what got me in.
I cut my teeth with SOAP and XML, and over time started looking at REST. As a developer in the trenches, I was defining what these things are. I stumbled into more of an architectural role by defining the appropriate placement for the business rules, logic, etc. Eventually, before you knew it, I was helping design API governance solutions for multiple Fortune 500 enterprise companies.
The leap between managing a single API and managing an ecosystem of APIs and ecosystem health was certainly formative for me as far as learning the power of APIs and the role that they play in delivering business value for companies.
You have a great purview of various API complexities. Is it fair to say that you deal with each complexity from a step above?
In 2014, I was with some incredibly talented, bright, capable individuals, and like many companies, we would be the AWS for our field. We saw the power of providing APIs for building new experiences and new services. Although I thought I was working with geniuses, we couldn't ship the product.
This is an example of what you're talking about. I knew the technology was good, but it required me to look one step higher to discover why we weren't producing if our talent was awesome and our technology was sound. We still weren't delivering like I was expecting us to. There was a missing piece that needed to be discovered. It's that kind of greater awareness and questioning that has defined my time in the API space – going one level higher.
What are some things you learned from your Capital One experience?
I worked at Capital One for almost six years. I had a front-row seat to experience and participate in a transformational effort as it launched and when it needed to account for that new hot ticket item. There are so many lessons from Capital One, but the biggest lesson for me was how to make power moves within large enterprises.
Coming from technology and being a technologist, I would dismiss it as politics. If I just focused on tech and had the right tech, the solution would be obvious, and people would naturally be attracted to my most rational, compelling, and longest list of pros arguments.
My time at Capital One showed me that was not the way things work when it comes to buzzwords and new initiatives. These are ways that power moves through the organization, how new people and new organizations can acquire power and then redistribute it along the lines that are the best fit for various groups. So, suppose you have a data transformation initiative. In that case, some people want to create a change within an organization that will create winners and losers.
If the change is designed where everyone's a winner, that's a plus. Often that's not how things work when budget, headcount, title, and public awareness are involved. Enterprise organizations are this Petri dish of competing ideas, and they're all trying to survive and make it to the next evolution.
I soon realized that not participating in or recognizing the power of these moves was at my peril. I had a team, and it was incumbent on us to understand the organization and the dynamics so we could participate. That doesn't mean we had to sign ourselves up for every hair-brained scheme.
Still, suppose you will be successful in your career working in an organization. In that case, you must understand the organization, understand what motivates and drives people, and understand what has currency and what doesn't while being prepared to deal with and engage with that.
As you study the performance of API teams and organizations, what does a good API organization look like?
There's many rabbit holes that individuals can go down when it comes to metrics and trying to measure health and quality. I've written about some of my dead-end observations in the past, like using net promoter score (NPS), which seemed like an adequate summation of capturing customer satisfaction with a particular API. It was something the business understood because it was used often, but it was incredibly flawed and problematic for our internal APIs.
Similarly, metrics-based strategies, like king pen in a fishbowl, where you take your accountable business leaders, and create a dashboard showing people are doing well and some not so well with the idea of generating friendly competition, can create very antagonistic relationships with key stakeholders.
Ultimately, when people ask how to measure health and high-performing API teams, I point back to the book Accelerate. This book is primarily about DevOps and what you measure in a DevOps environment to show healthy production, but those same approaches apply to an API environment.
When we're talking about their measurements around lead time, how long does it take to go from a team responsible for creating an API to that thing being in an environment that the consumer can hit? How often can the team change those things? How much time does it take to recover, and how often do those production changes need to be rolled back because of a problem?
The concept of changing those things frequently is at odds with my point. Still, when I worked with Postman and inserted these sorts of questions into their 2021 State of the API survey, we found an extraordinarily high correlation between teams that could change frequently and the teams that we're having success in the marketplace.
This tells us that the teams that can frequently change most likely have processes in place that have conceits in place where they're doing frequent, incremental releases. So maybe they're not publishing the entirety of an API all at once. Still, they're getting that initial get into an environment where then, subsequently, clients can then figure out their keys and provisioning, do that first call, and provide feedback while the team is still incrementally adding to the API and getting it out the door.
They're engaged in design practices like evolutionary design, where they're not releasing multiple versions, but instead, they're designing their roadmap to evolve these things safely. Perhaps even using HyperMed to evolve things eliminates the need for big bang releases.
Having the capacity to change how you measure that capacity to change is more powerful for designing healthy environments, healthy teams, and responsive teams than alternative metrics like reuse, which can lead teams down the what-if rabbit hole, like what if the teams want this? We need to design for every single use case in the entire world, and it needs to be right before we produce anything, and that's an unfortunate dead end.
Your experience with systems thinking and design is quite a collection you don't see too often. Is your book centered around this?
It is, but I'm very hesitant to come out and say, this is the systems thinking manual for API providers– because that's gonna scare people away. Systems thinking can be hard for many folks to relate to their immediate day-to-day existence. While I hope to include many systems thinking and higher-order thinking, every chapter, story, and example must lean into the ‘so what' and answer the question of how this applies to my everyday life.
With software, on one hand, we've dealt with complexity through various reductionist techniques. For example, Agile is about reducing the time it takes to get meaningful work into people's hands. Similarly, service architectures focus on reducing the size of the thing we're trying to deliver.
Even DevOps, with the idea of continuous integration and continuous development, it's all about reducing the size and time that it takes to integrate and put things into an environment. Through these reductionist techniques, we have seen substantial gains in the complexity, type, and variety of software that we're able to produce. Simply the developers can now grow what they're doing because what they're doing is smaller and more focused.
In the course of doing that, we've introduced another problem. When you read about teams that previously had monoliths and went to microservices, the result was a mess, and they reverted to monoliths. The issue is that we're losing a coordinating function. We're losing something to maintain the cohesion of the larger system. When people only have access to these small, independent bits, they end up without any other forcing factor. They end up maximizing the local optimization of that thing, and though it may be great, you're losing the essence of the larger thing.
When I talk about API complexity, the current situation of software, and really the focus of the book that I'm writing is how do we get back to a place where we still have the benefits of the reductionist approach? Where we can take a problem and break it down into pieces and not overwhelm our development with the complexity of the entire system, but at the same time, still can coordinate and think about the relationships between the pieces to deliver something cohesive.
Your book isn't just about systems thinking, but maximum leverages at the interface, right?
When I say it's about systems thinking without talking about systems thinking, those interaction points are the interactions between individuals. We have these stereotyped ideas about what a developer is, and I want people to understand how retrograde that type of thinking is. Programming is a diverse field, and there are tons of people who are not related to that stereotype at all. We need to stop treating developers as people incapable of dealing with other people or intersections.
These intersections are more than just when an API calls another API. It also involves the development teams that have to talk to each other and coordinate. We've gotten into this spot where we will spend days looking through the minutiae of a new cloud service and bang our heads against the wall with all kinds of permutations for consuming and providing that.
When it comes to the interaction between people, we throw up our hands and say, ‘they're developers' and deem empathetic listening, running effective meetings, and coordinating tasks as skills that are beyond them. We're not trying to upskill them in that sense. When talking about systems thinking, we talk about models and the intersections, but what I'm attempting to focus on and elevate is the idea that we can relate to our fellow people.
This is not a space where we can hide behind outdated notions about what a developer is and what they're capable of learning. They can learn these skills too, and they can be participants in this larger system on equal footing. We need to reframe what is possible here.
When it comes to the developer landscape, what are the areas that people spend too much time on, and what are those that people miss out on?
A lot of these things are echoes of comments from Fred Brooks and Mel Conway from about 50+ years ago. We're still seeing way too many places assume things can be done faster if they add more people without accounting for things like coordination costs. We're also still seeing an avoidance in thinking about the organizational structure.
When big change initiatives are introduced, the hierarchy and the people involved are still the same. If we're actually trying to implement change where we aim to facilitate faster provisioning for clients, for example, if internal communications haven't changed, there's likely to be a cognitive mismatch.
I get very frustrated with silver-bullet solutions. People assume that new technology and new tools can just be dropped into an existing cultural environment, unchanged, and that will magically solve all their problems. If you're proposing a significant change to the behavior of day-to-day developers, you have to address the behavior change and not just the process.
What is the process for finding new material for your newsletter?
I have so many thoughts as far as the ongoing process of sensemaking. How do we take information and turn it into knowledge? The Net API Notes Newsletter has always been an outgrowth of my sensemaking. There's a tremendous amount of movement within technology, and I wanted to take all of that movement and make it logical. For me, that's what writing does.
That's part of the reason why I have that journal about my previous experiences in companies. That's why I'm currently working on a book that's really for me and not so much for other people. Doing the newsletter and having a regular schedule as a forcing function allows me to take disjointed information and put it into a narrative that makes sense to me.
When that started, that was largely what I was seeing in my RSS feeds as I followed people that I trusted and soaked in what they were talking about. I noticed when there were multiple data points of people that I followed all talking about the same thing, that was a strong signal for me to highlight that area.
Over time, the RSS feed has faded, but it's still there. Sometimes I find some interesting things that come up, but lately, I've pulled lots from Twitter. It's not surprising how the results of the last week or so have me somewhat concerned. Twitter has become a very valuable way that I do my sense-making.
I try to restrict the number of people I follow, and I continuously sift through and shuffle that list to make sure that I'm not getting tunnel vision or focused on the same people repeatedly. That continual mix of ‘who am I following?', ‘what are they interested in?', and ‘what are they retweeting?' helps me find commonalities between their ideas and other ideas. Following that thread and then trying to put that into a narrative in the newsletter is important to me and, thus far, rewarding.
In light of the latest news around Twitter, I think it's important for me also to expand the aperture and start looking for other discussion points. You've got things like Reddit, Discourse, Slack Forums, and more. Conversations are happening everywhere, and in retrospect, I've probably over-indexed Twitter.
The recent news is probably a good reason to look for other things. Do I expect Twitter to turn into a “dumpster fire” tomorrow? No, probably not, and I will still get some value out of it for the newsletter, but there are many other forums out there that I would be remiss to only focus on one.
Want even more?
We hope you learned as much as we did from this episode of APIs Unplugged! If you want to hear more APIs Unplugged episodes, check us out on Soundcloud, Spotify, and Apple Podcasts.
