Kevin Montalbo

Welcome to episode 57 of the Coding Over Cocktails podcast. My name is Kevin Montalbo, and joining me from Sydney,  Australia is Toro Cloud CEO and founder, David Brown. Good morning, David!

David Brown

Hi, Kevin!

Kevin Montalbo

All right. Our guest for today is a platform thinker, digital transformer, API design architect, people manager, conference speaker, developer advocate, and writer. Since his first web projects at IBM in ‘99, he has built and maintained software governance teams at multiple Fortune 500 companies. His passion for building successful software developer cultures result in the continuous delivery of business value, even at scale.

He’s currently the Director for API Platform Ecosystems and Digital Transformation at Postman. Joining us for a second round of cocktails is Matthew Reinbold. Hey Matthew, great to have you again!

Matthew Reinbold

Hello! Glad to be here. After we get done, Kevin, I'm gonna have to ask you if I can hire you to like, announce when I enter a room because that was fantastic.

Kevin Montalbo

Well, you'll have to ask David for that.

David Brown

It does! It does sound good, an intro. Think, “Wow, I did all that!” So listen, Matthew, welcome back to the program. It's always great to have a guest come back and join us again. And, since the last time we spoke, you've now joined Postman. What prompted the move to join Postman?

Matthew Reinbold

It was an incredible opportunity. I've spent a number of years working with large enterprise organisations, trying to get them moving on large, enterprise-scale initiatives. And that was really rewarding, really fulfilling, but I felt so often that we were developing new techniques or new processes or new ways of approaching API development that really could have benefited the entire industry. And so when this opportunity came up with Postman, to help set the agenda for what digital ecosystems were gonna be and how I could possibly pollinate that in the larger environment, working with a number of companies, it was a wonderful opportunity. I jumped at the chance.

David Brown

And what exactly does a Director for API Platform Ecosystems and Digital Transformation do? It's the long title?

Matthew Reinbold

Yeah, it's a long title and  it's completely made up. But really, at its heart, it's helping companies make that leap from a handful of APIs to an ecosystem of APIs. Right? When I say ecosystem, it's more than just the dozen or a hundred or a thousand APIs that some companies have rattling around, enabling their day-to-day operations. It's also the tools and the scripts and the processes and the expectations and the cultural norms. That's a jungle. And if you only focus on the individual APIs, even if you're executing at a very high level for those individual pieces, if you ignore the jungle and the unique set of skills it takes to manage that, you're gonna return suboptimal results. So, helping companies make that change, helping them see their forest instead of just individual trees is really what my job is all about.

David Brown

Yeah. It's interesting. I mean, how do companies end up with this jungle of APIs? I'm guessing, because this is all still relatively new, APIs are being developed on an ad hoc basis and they just get added to the ecosystem. So, is that how APIs are maturing in an organisation? And then what do you do about it to clear the forest for the trades?

Matthew Reinbold

Right. Yeah. It's  really a product of how useful APIs are within a modern company. Nobody starts out thinking about governance or thinking about management or monitoring. Like, they're trying to solve very specific problems and they have a little bit of success. And so they do that more and more and more. And then pretty soon, they're not achieving the same kind of impact that those first original APIs were doing. Right? And it's a set of skills. It's a different mentality that organisations have to work through as they begin to scale, as they begin to grow. 
So, you know, what does that look like? Well, thankfully, I've spent a bit of time now at Postman, talking with customers, validating models that I had put together beforehand, dating models based on new information and really, we're starting to get an idea of what high-performing API companies look like and the behaviours that lead to high performance. And I gotta tell you, it's not just technology. It's a lot of “people” stuff.

David Brown

That's interesting. So you obviously had a lot of theory and development in your writing and now you're going into these organisations and evaluating their existing processes and documentation of their APIs. Are you noticing some high-performing companies, which are obviously, clearly doing something well or doing something different? So, tell us about that. What is the difference between those high-performing companies and those which have more to achieve?

Matthew Reinbold

Right. So, working with Postman, I was able to help influence the latest 2021 State of APIs report. And I didn't want to just go in with yet another set of survey questions. You know, “What are the tools you use? How many hours per week do you spend?” I really wanted to test some hypotheses that I had around this specific area. 
So, what is a high-performing API company? Well, this may sound obvious, but we needed to test it out. API high-performing companies are companies that ship sooner, ship more often, have fewer mistakes or rollbacks when they do ship. So, it's not just throwing more spaghetti at the wall, trying to get something to stick. What they're putting out there is good and they're not having to take it back. And then finally, when things do fail, those companies are able to recover faster. Okay? So, like all of that should sound kind of obvious. That's what high-performance looks like.

But then we had to go one level deeper, like, “Okay, so we're able to ship, but what leads to those kinds of behaviors?” Because obviously, any company would want that. If some CEO could just sign a check and have that happen, they'd do it yesterday. And when we got into the numbers and started looking at correlation between high-performing teams and subsequently, the behaviors that we saw there were really three major themes around that.

First is an articulate vision for what the APIs are doing for the organisation. Your C-suite may not know the difference between a three-layer architecture and a seven-layer salad. That's fine, but they should be able to articulate how technology modularity helps them strategically. So, you know, back in the days when we went into offices and we might get on an elevator and have a 32nd conversation with an executive, like, they should be able to say in that time, how APIs relate to the business strategy. More so in five years, they should be able to say, “This is where we will be,” because if now, if business executives can't do that, if APIs are only seen as that tech thing, the thing that the geeks are doing over in the corner, there will be that disconnect. You will see some of the benefits from API production, but you won't see the kind of performance long term that we see with these high-performing API teams.

David Brown

Recently, we have been talking a lot about where the digital transformation initiatives come from. Does it come from the CEO level, down the board level, down C-suite? So you are finding the C-suite in those high-performing companies are very much aware of the impact that APIs are making, that “modularity” as you call it. And so, and your expectation is, over the five years, they're able to articulate the real differences that APIs are making in their company.

Matthew Reinbold

Right. So, just to back up on what you're saying there, I wanna make it clear to the audience. That's not saying that digital transformation, that vision-setting can only come from leadership. What we've seen is digital transformation starts anywhere. But it needs to connect to the leadership. They need to be able to articulate how it relates to strategy, how it helps the company win.

David Brown

I was gonna say, I'm guessing you actually wanted to come from anywhere. I mean, you want to draw that decision-making process down. So, that's interesting, that you're finding that that's where real change is sometimes occurring. But I guess I was talking more about the vision, in terms of driving the initiative, being driven from the top down so that it's clearly articulated from the C-suite down and perhaps even the board level, these days, are getting involved in these kinds of decisions, not necessarily APIs. And I mean, you're talking about APIs at that board level, but perhaps the digital transformation process, right? 
But you're finding that APIs are becoming a real part of the vocabulary of that C-suite, is that right? So it's something that they're actually bringing up in your conversations with them.

Matthew Reinbold

Right. And to be clear, we're talking about digital transformation, not just digitisation. And I draw a very distinct line between those two things. So, there's lots of opportunity for software to be applied in companies to make what they all already do more efficient, faster, better, possibly cheaper. I call that digitisation. Right? What is absolutely essential during the pandemic and the subsequent supply change crunches has been digital transformation, that is applying software to create new products and services, not just doing what companies already did, but doing things in a new way that allows for a more modularity, more resiliency in more complex, disrupted worlds.

David Brown

Yeah. In fact, I think you mentioned that in our last talk. Transformation has created these new digital products and services, or finding new ways to improve customer experience. That's the real transformative process, as opposed to just using technology, which we've been doing for decades to, you know, create a more efficient process or to expose data or whatever it may be. I'm glad you brought up the State of the API report because we wanted to ask you a few questions about that. One of them was you asked about how companies responded to the pandemic and how APIs related to that. What were your findings in regards to the pandemic and how people responded?

Matthew Reinbold

Right. Probably the most obvious thing, suddenly a large percentage of digital workers were remote and that couldn't have happened without APIs. That's kind of obvious. Let's set that to the side and talk about the second level, like, whether you were attending a church service over a video conferencing call, taking telemedicine for the first time, meeting with your doctor on your phone, doing simple things like curbside pickup. Like, there was no other worldwide event, at least in our lifetimes, that changed consumer behavior like the pandemic.

So, all at once, people were trying to achieve common, normal, everyday tasks in a way that was safe. And that was a worldwide phenomenon. That wasn't just one country that was a little disrupted, it was a worldwide phenomena that had people seeking out different experiences, different ways of delivering value. Companies that had already invested in their API portfolios were uniquely suited toward that change.

So, if you had already taken your ordering and your inventory system and put it in an API, you could more easily spend a little bit of developer time and create that curbside pickup experience. Whereas if you had a traditional point of sale mainframe, you are months behind. And as we look forward to the future, these things aren't going to go away. I love my curbside pickup. It's incredibly convenient.

Despite appearances, I sometimes don't like to talk to people and therefore, being able to roll up, get my stuff and leave is incredibly attractive. So likewise, things like being able to get a doctor on an application is incredibly convenient. And now that people have tried that, they've seen what that can do for them out of necessity. Now there's the expectation that other products, other experiences have that same level of convenience. So, even if you were able to weather the pandemic and you're looking at things well, there's going to  be a subset of the population that's going to still expect that level of convenience, that level of intimacy, that level of on-demand response that they got during the pandemic.

David Brown

Yeah. And another finding was, which is not really that surprising, is that developers are spending more time working with APIs. It was the amount of time which really surprised me, with most respondents saying they're spending more than ten hours per week on API development. Although it was an API questionnaire from Postman so perhaps there was some skew there in the respondents. When you break down this API development effort, what tasks are they spending their most time on? And were you able to identify any areas for improvement where they perhaps could be spending their time more efficiently?

Matthew Reinbold

Yeah. So, we saw that approximately two-thirds of the time was spent on activities other than programming or developing the APIs. So, these things like monitoring, debugging, designing, documenting all of the halo of activities to actually successfully fulfill an API's expectations vastly outweighed the actual time to create the API itself. 
As far as where we could get better, I think as an industry, we're still struggling with dependency management. There's a quote in the report itself from an individual that unfortunately, is not unique. They talked about how a significant amount of their time was just looking over their shoulder at their dependencies, making sure that they weren't changing, having to make sure that like, “Oh my gosh, am I gonna get a call at 2:00 AM because of PagerDuty because somebody pushed something to production and that's going to be a problem for me.”

So, from an API producer side, we need to get much better about articulating what constitutes a breaking change and subsequently, how to communicate those out and, and achieve logical, sensical rollouts of those things. And from a consumer standpoint, we need to have better automation and monitoring, for knowing when the sand starts to shift so that we can proactively jump in and not have it be a production issue. You know, whether that's lower to your environments, being able to test our third parties and make sure that they, the lower tier environments, are remaining stable before they get into production or just having regular monitoring set up so that we have canaries in the coal mine, I think is gonna be incredibly important going forward.

David Brown

Yeah. Good advice. We've often talked about API-first on this podcast. Two thirds of the respondents said they're already embracing API-first, but only 8% regarded their API-first approaches being excellent. What do you regard as nine or 10 out of 10? Why do you think the vast majority are not rating their approach to API-first very highly?

Matthew Reinbold

I go back to the fact that it's so much more than just implementing a particular architectural style. API-first at its simplest form is making sure that there's an API for any associated functionality that's produced simple, straightforward. However, making sure that that API functionality is valuable long-term, that it meets the needs of the consumers, that it is backed by solid ownership, all of these things require, in a lot of organisations, a change to how they produce software. It's a change of mindset from individual projects that meet a feature list, or a Jira ticket signoff and then subsequently, are sent out into the world. Change from that project mindset to a product mindset. And that's a big change that includes changing cultural norms. It means changing approaches to how this technology is managed.

I previously mentioned the three big behaviors that we saw were really a part of successful API companies. And we talked about the vision aspect. The second is making sure that these companies have and sustain a virtuous flywheel of communication so that the developers that are creating the APIs are getting the feedback, incorporating the feedback like anybody can put out a suggestion box, but it's whether you're actually taking those suggestions and incorporating them in and continuing a virtuous cycle of getting better and improving.

And then the final bit is making sure that proper things are incentivised and things like job titles. I'm sure there's a lot of members of your audience that are probably going through year-end performance review. And everybody talks about how they love better API quality. They love to have APIs, that API first, that ever is the sustainable value. But if I ask you, “Where in your job descriptions are you rewarded for API quality?” I'll get some puzzled looks because the job description is about shipping code. And the API quality is like a nice thing to have whenever people have time.

David Brown

Right. API-first fundamentally requires collaboration with stakeholders. Developers are not necessarily known as being social, collaborative people. They like coding, right? They like working in front of their computer and getting stuff done. As you say, they're incentivised for that as well. So, you know, taking them out of their comfort zone and starting to collaborate and talk to people and stakeholders and finding out what they need and what they want and [whether] I am  delivering something that is useful for you is kind of, in some respects, taking some developers a little bit out of their comfort zone. And I wonder if that also impacts why maybe they're putting it on the back burner? So yeah, they're doing a bit of it, but not necessarily doing an excellent job of it

Matthew Reinbold

Possibly. I would gently push back. We have this kind of stereotypical idea of a programmer being that person in somebody's basement. And all they do is you  throw pizza and  sugary drinks down the stairs and code comes out, you know?

David Brown

Yeah, like that.

Matthew Reinbold

I strongly believe that it's all about making sure that we understand what we're trying to achieve. If things like quality, if things like stakeholder engagement are treated as these aspirational, nice-to-have things, then they'll continue to be the things that are deprioritised or left on the floor when time crunch happens. If we speak to the identity of being good at your craft, if we speak to the identity of being a good, professional API designer as incorporating these things, I think they will happen like the stereotypical in image person that we have in our heads. They talk to people, they talk to people a lot about certain topics that are really interesting to them. I've seen Hacker News. It happens. It does, but we need to connect these two things where it's not external to them. It's not a nice-to-have, but it's actually core to what it is to be a good API creator

David Brown

And part of being a good API creator also involves documentation. And one of the results of the survey was that only 3% of the respondents found that the APIs that they would consume were very well-documented. Where are we falling down in the documentation? Are we talking about human-readable documentation? Is it the OpenAPI specs, the Postman collections, all of the code snippets, all of the above?

Matthew Reinbold

I  think it's all of the above because for all too many IT shops, documentation is still that step that comes at the end. It becomes like the lipstick on the pig. Like we're gonna toss it over the wall to our tech writers because we gotta get busy with this other stuff. And therefore, like the people with the most intimate knowledge of how that thing works have just left to go somewhere else. And that's a huge, huge problem.

So, one of the other questions said, “Well, what do you wish you had more time to do?” And testing was one of the big ones. And documentation was also one of the other items. What we need to do a better job of is showing how those short term wins shipping code actually incur a long term cost. 
One of the big light bulb moments that I had leading a group through the same conversation was when I pointed out how much more time equivalent groups spent maintaining supporting other teams in meetings. Like, we can go ahead and publish this API as is, but I guarantee you're gonna spend 10 more hours per month describing again and again, for every single integration, how this particular aspect works, or you can spend a sprint cycle documenting it once. And then you can be done and lo and behold, most people don't like meetings.

And so having that quantifiable information, being able to share that and demonstrate it, that was enough to get that effort prioritised for the developers, have them care about the effort and push that through. So, we need to connect those dots for folks like it's documentation is not something you throw over the wall. It's gotta be part of the definition of done.

David Brown

Well, the other interesting thing I found out, I discovered in the survey was the adoption of REST. So we find that GraphQL for example, gets a lot of buzz in the industry, and then there's new formats like AsyncAPI and the like. But the overwhelming majority were still using REST. What's driving the adoption of REST versus these other API topographies?

Matthew Reinbold

There's two big things. One, I think, is the ubiquity of REST. Everything speaks to the web, like every framework, every language. Everything speaks to  the web and therefore it is the easiest thing to get started with. It's native to almost everything at this, but the second thing is it's just good enough, right? For those of us of a certain age, we might recall the Semantic Web and it's coming up on 20 years now, but it was this idea that we were gonna take this sloppy web and we were gonna make it like perfect. We were gonna make it rigid. Like, everything was going to mean something. And it was gonna have all of this built in semantics to it and subsequently, it fell apart because that level of effort  just didn't justify itself. And in the same way I look at REST and yes, we complain about how it's kind of descriptive, it's not prescriptive.

And so, therefore, you can have a lot of little wonky bits in there. And I think we need to stop thinking about that as a downside and start thinking about it as  a positive, like the fact that it is so malleable, that it is so flexible is actually one of its strengths. So, there will always be a place for API patterns that do one thing. And I anticipate we're gonna see a lot of those in the next half decade, but there will always be a certain level that just does REST because it's simple and it's straightforward. And there's a level of flexibility there that you just don't get everywhere else.

David Brown

And as a consumer of an API,  having something which is descriptive, knowing exactly what response you're gonna get, if you give it the payload that it's asking for, there's nothing wrong with that. It makes your life easier, consuming that API, sometimes, if it's giving you the kind of payload and resources that you're after. 
The JSON schema dominated the specification of choice, which I thought was interesting, because OpenAPI V.3 actually uses an extended subset of JSON schema-described data formats with it. But JSON schema, OpenAPI Swagger, they were given alternative choices in the question of which is their specification of choice. What's driving then, the adoption of JSON schema? Why did that outrun other formats, particularly Open API, which would seem to be the biggest industry body driving API specifications for REST?

Matthew Reinbold

Right? It's a great observation. And it is something that we certainly wanna look into more because it is a bit of a head-scratcher. If  I had to make a theory, it kind of goes back to what I just said about REST. Like, we need just enough definition. Like, just JSON by itself is great as a syntax, but we need just a little bit more information to have meaningful validation across systems or to provide a little bit extra information. And so, JSON schema is performing that little bit of extra definition without having to go to some kind of heavy-handed, SOAP-centric,  Salt style sheet or something like that. It's just enough to get us the semantic meaning in our message payloads that is really useful without being too cumbersome.

David Brown

Fair enough. It was an interesting result that I’ve found. Look, we've been talking recently about the podcast and we touched on this earlier about who's driving digital transformation. So APIs are obviously a large component of digital transformation within organisations. But as you say, it's just really a mechanism to facilitate change and we're talking about cultural change and the like. So, in your experience [with] these digital transformation initiatives, who should be driving it?

So, we talked about before that, yes, we'd like to see change occurring lower down the food chain, people closest to the customers and understand the customer experience that they're getting and what change they can drive and what value they can drive. But where should the vision be coming from? Is it the CEO? Is the board of directors? Is it a director of digital transformation?  Someone with digital transformation in their title, right? What's your experience for that?

Matthew Reinbold

Yeah. So, going back to my previous point, the leadership needs to be able to articulate the change and its importance. But I strongly believe the people driving  can come from any level. What's changed in that aspect is that if you are a leader and you do have a change that you'd like to perform, you are operating with a high degree of hierarchical power. If you're on the front line, you still can drive change. But the nature of the power that you wield is very different.

So, there's some great resources out there. There's a fantastic TED Talk called “New Power vs. Old Power.” And I'm not crazy about that definition just because it sounds like one is obviously better than the other. I think it's really a combination of both, but if you're one of those frontline workers, you have a tremendous amount of what they call “new power,” which is about using influence about organising, about taking the domain expertise that you've accrued and being able to demonstrate useful attributes to your leadership and how you can drive that change in your existing organisation.This is really important to me because as I talk about things like API governance and API ecosystems, you will see those frontline people that want better quality, that want better security, that want more time for documentation and testing and mocking, but they feel that they don't have any agency. Like, that must be somebody with headcount, somebody with budget, that must be their responsibility. And I just have to suffer through. And if I wanna leave you with a message it's that, no, no, no, no, no. Anybody can drive change within the organisation. It's just about finding the skills, finding the ways to operate, which can help introduce that change and make your organisations more amenable to those very important concepts.

David Brown

Great advice. Matthew Reinbold, thank you for joining us again today on the podcast! People can find you best on LinkedIn. “Matthew Reinbold” is the handle, is that right?

Matthew Reinbold

Either there or my website. And so, it's very imaginatively named “Matthewreinbold.com.”

David Brown

Your parents registered that when you were born, didn’t they?

Matthew Reinbold

No, I've just been on the web that long.

David Brown

Okay. And the State of the API Report, where can our listeners find that?

Matthew Reinbold

So they can go to Postman.com/state-of-the-API.

David Brown

Great, thank you very much for joining us today!