API Evangelist Conversation with Claire Barrett, Digital Strategist at APIsFirst

Hello again, Kin Lane here, API Evangelist, for another one of my API Evangelist conversations where I bring folks by who are doing interesting things in the API space, and we just have a conversation. So let’s not waste any time, let’s see who we got here today. Hello, who are you?

Hi Kin, I’m Claire Barrett, I’m joining from the UK. Lovely to be here today with you.

Yeah, pleasure to have you. We’ve known each other for a while, swirling around the API Days event and the wider API community. Give a little background on what you focus on in the space and what brings you to the world of APIs for folks.

Yeah, so I would call myself, I’m a consultant first and foremost. I run a consulting business, APIs First, based out of here in the UK, and I also co-founded the API Collective with Marjukka, another of your peer group in the API think space. I am a connector, so I help people who are trying to execute API-enabled change understand and connect with the strategies that are often going on in kind of the wider environment, but I also help those strategists actually understand what’s involved and how they can connect with the people who are doing the work on the ground. And the third thing I do is, I’m involved in community building, and particularly I lead the Women in APIs community, which now has representation in 45 countries.

Oh, nice, that’s definitely grown and expanded over the years, that’s good to hear you’re doing that important work. I wouldn’t say just the business bridge, what we need in the API space that we struggle with, I think it’s that building a wide bridge that’s global that many people can walk across and work across and do this work, that I think is one of the lacking nutrients in the space. So I’m always thankful for what you bring to the table. So I want to dive in, because as I said you’re kind of bridging to the business side of things. I’ve been doing this 15 years now, and rah rah rah, champion API, API first, it’s an important thing, we spend a lot of money, time, energy focusing on it. And I think as we move out of the wild west, the childhood years of APIs, there’s a lot more requests as far as where is the return on this investment, what’s the business impact, how do we actually make it address the bottom line. You pointed me to a white paper that Treblle and you have been working on. So can you give me a little background on this? It’s getting results from API investment, and it echoes I think what I’m seeing in the space and hearing in the space as far as this, how do we justify it?

Yeah, so what we were hearing were a lot of consistent questions and conversations coming back from particularly large and larger organizations, which tends to be the space that I’ve either been working at, consulted to, or consult at, in incumbent industries, and people were saying we’ve actually been investing in and around the API space, in tooling and capabilities and frameworks and management systems, and we’re not seeing or feeling that we’re getting the return and the promise of the big bold participation in the API economy, the revenue returns from monetized APIs, etc, or even efficiencies in the speeding up of IT-enabled change which you would expect from your kind of composable architecture view. So what I prepared was my take on this, and probably two things that are kind of important to bear in mind in this, how do we get value from this API investment. The first is to understand the difference between what could be directly attributed to having API-enabled capabilities, and it’s not often actually directly on the bottom line, that’s one of the problems, that people have promised too much of what should be the commercial case, the technology case, etc. So I talk about the difference between direct and indirect benefits that you can attribute to having these kinds of platforms enabling capabilities that are typically enterprise wide, or that will support business and tech strategies. So business strategies to move into new territories, to make a process more efficient, and then you might have technology strategies around simpler architectures, faster flow of change, quicker adoption of new things, etc. So that’s the first thing, direct and indirect benefits. And the second is some common ingredients that you need to have right, I call them like five key themes, that organizations need to get behind in order to deliver on this bigger promise of the API agenda, if you like, and so I go into each of those.

Yeah, and it’s written in terms I think that are going to make sense to business leadership, but it has all the technical parts and pieces that make it relevant. So I raise my hand and say I’m guilty of overselling, and, well, I wouldn’t say overselling, but the monetization narrative was direct value, meaning you build it they’ll come, you will sell access to the API, and I think that piece of the pie was much smaller than us technologists hoped, wanted. But there’s a lot of APIs, we’re doing APIs and there’s a lot of indirect value, and there’s a lot of connecting of the business dots that I think is required to do that. And I recognize that I haven’t invested heavily enough, I spent too much time selling the kind of build-it-they-come kind of business direct value. So how would you summarize your paper, your thesis? Is it more on my responsibility, tech and the service providers, is it that business hasn’t caught up and aligned with it fast enough, where would you put it?

So I don’t attribute it to any one group of people or any one particular discipline more than the others. I think of it more as some mindset shifts that you need to collectively have as an organization, or as a participant in, call it, the API economy, that if you kind of get it at that level. And there I suggested five things. So the first is understanding engineers as customers. For an incumbent industry that is used to thinking of customers, even if it’s another business, and ultimately it’s you or I, if it’s not B2C it’s a B2B to B2B to eventually a consumer person somewhere, and the commercial models for those organizations are built on, might have once been physical products. It can now be screened data or it can be distributed, but it’s physical products rather than what the software tech industry thinks of as a digital product. So for people trying to justify investment in these more incumbent industries, if you’re suggesting that your API product is something that people are going to want to buy, those people need to be able to engage as engineers or people who influence engineers coming to use your API, and that is very different than if your customer base is the customer base of your traditional. So when you’re trying to look at the business case for investing in it, you’re not necessarily comparing like with like. Am I making sense?

Yeah.

So engineers as customers. Second is designing APIs as product, and this is obviously something that you’re very attuned to, and those of us that are in the space, understanding that APIs are not just a better way to integrate, they’re not just, again for incumbent organizations, if they don’t have the right funding model, if they don’t have the right incentives, motivations for people to design APIs for many people to consume internally or externally, and they’re really thinking about who that customer might be and applying some design thinking early, then they’re not taking advantage of the API opportunities.

Yeah, so let’s step back on the API products, because I see this touted, wielded in a lot of different ways, but I see the concept of an API product as this bridge between technology and product to get to this destination where, that I think we share in our head, engineers need to think in terms of, hey, how are we making money with this, there’s customers we need to have a feedback loop, support mechanism, there’s a whole bunch that goes with this, and then the other side is we’re bringing it to terms that make sense to business and trying to get them involved in the conversation and speaking in terms of APIs. But what does it mean to you, what’s the barebones definition of what API product means, what is it?

So I think of, but I should actually say, sorry, by the way, the third one of the other themes that we’ve got is that we think of API design as a team sport. So exactly what you’re talking about, this is technologists needing to be thinking about the opportunities of data that they can unlock from existing systems, or new ways of being able to present and to be able to think about how somebody might consume those, in collaboration with their maybe potentially more commercially minded, or more delivery minded, or more customer tuned, or partner tuned colleagues who are representing, call it, the business. I mean you could argue everybody’s part of the business if you’re thinking APIs as products become digital products that are part of your catalog. So I, to be honest, don’t try and get too hung up on being too precise about the definition, because one can end up in a sort of big tit of taxonomy. It’s more to me a philosophy of thinking about, and certainly the organizations that I tend to work with, they don’t get the value that they’re hoping for from their API programs or their API investments when they still think of APIs as an interface, just a different type of interface. So that’s why we talk about thinking about an API as being consumed by, I always use Mike Amundsen, consumed, you’re thinking of something to be consumed by a customer you’ve never met to be used in a way you could never have imagined. That is a very different headspace for people to be thinking out than I have a business requirement that comes from a customer that says I need these particular features on a physical product, or an existing known product, a non-API product.

Yeah, and I feel like, I’m trying to come at it from the engineer perspective and bridge to it, so I guess my problem is I’m always looking for the precise definition and where the lines are with things, and I’m finding, as I widen that audience, that I need to let go of some of those technical details and find meaningful abstract ways to talk about things. And I think API products is an important one, supply chain speak, talk in terms that people currently understand and that impact them. And that’s part of this growing out of our infancy phase, as far as trying, you know, from the wild west of APIs and REST, and I think learn from a lot of our mistakes. But you’re really trying to, I would say you break it down in this white paper into terms that leadership is going to understand, and product. And then, I know you’re involved with Marjukka and API Ops, how are you guys, what’s your number one or two ways that you speak to leadership to open these doors and get these conversations going? Is it just revenue, cost saving, what are the top things from your paper that are meant to catch the eye of leadership?

So firstly, there aren’t one or two things that are generic across industries. If you want to catch the eye and the attention of people, it’s about where are they at at that point in time, what are the strategic priorities for them from a business perspective and potentially from a technology perspective in balance. Are they on an efficiency drive, a cost productivity focus, are they on more of a growth kind of focus, are they looking to build different distribution channels through different business partners, what are they really trying to achieve that’s the priority at the moment. So what we’re often talking about is building API capability that lasts beyond the next planning cycles, but making sure that what you’re doing and focused on for that quarter or that next short horizon is well connected to what the organization’s priorities are at that point in time. And there isn’t a black or white on that, because what’s more important is that you have a way of finding it and applying your next API priority to solving that problem.

Yeah, that’s important, I think that alignment to the enterprise is where everything I’ve ever prescribed and done didn’t succeed or come or happen as planned, because I didn’t have a good enough understanding of the enterprise or organization, the people. And do you feel like maybe in the tech sector wider, we’re trying to find one-size-fits-all solutions where we probably should be more tailoring this to the actual people, the actual industry, the actual what’s happening on the ground?

Yeah, I mean I think this is kind of the reality of living, if you’re working in a large organization which partners and works with many other large organizations and large numbers of people, there is naturally going to be lots of different people’s views on even things like the common terms and so on. So I don’t think there is one size fits all. What I think is there’s the right size for that point in time for that particular group and community. I think frameworks and simple structures and common terms are really really helpful, as long as everybody is using them the same way. I have never worked on a project in almost any industry where people use the same words all consistently the same way. So it doesn’t matter what kind of project I’m on, I always will start with a taxonomy, because, at least for the context of what we’re going to be doing for the next few weeks or months, let’s all agree that this is how we’re going to use it. And often people actually really value the fact that you’ve written down, and it’s the most used terms that you actually need to spend the most time on. So is it today a product, or is it a platform, or is it a stream, or a service. All of them could be so widely used, it’s like, well, at least for this context let’s use it this way. So I find that’s kind of a 101 consulting thing, but I don’t get too tied up when this is what’s right for us, because you’ll find every organization has their own nuanced use of things, you just say, okay, right, now I see you’re using it that way, all right, let’s make sure that you realize that if you were going to other industries, or if you were talking to or employing new people from a different background who’ve also worked in this space, they might not see that term that way, because they follow people like Kin and the API Evangelist who would tend to have a much clearer definition of how to use some of these terms.

Yeah, I think life cycle, API life cycle, is one of these words that I come in and go, oh, of course it’s define, design, develop, test, distribute, and then, where I’ve learned in the last five years, I walk in and go, hey, what is the life cycle here, how do you start at the beginning here, how did we get to the end? But a lot of people see me coming in with those preconceived notions, or may have, they may have from reading mine, and they don’t actually share what they do, they share what they think I want to do. And so that vocabulary is such an important grounding piece. That’s wisdom right there, I would always start with the vocabulary, the glossary, the terms, so we can get on the same page.

Well, we broke my rule, we’re at 20 minutes. I normally go 15, but this is good, this is what it’s for. But can I have you back after the holidays, after API Days in Paris? Will you come back and have another conversation with me next year?

Would love to, Kin, of course, would be a pleasure. Some other things I want to pack there, but thanks for coming by today, Claire.

Thank you, Kin, and thank you for everything you do for the community.

Thank you. All right, definitely a reflection of where we’re headed. I left Postman, went to Bloomberg to focus on this intersection of products and API governance, and I’m finding the business and the product side is actually stronger and more important than the governance piece. Governance is there but it’s underneath things, and really the business alignment stuff that Claire’s talking about is super critical. So look forward to continuing these conversations, but thanks for coming by.