In our latest podcast episode, we spoke with Lorinda Brandon, VP of Engineering at BetterCloud. At BetterCloud, their core strength focuses on consuming APIs and interacting with various API providers. This requires an immense amount of adaptability and customization to the way her team works. Each API provider is unique in consuming APIs, processing documentation, and working alongside Developer Relations (DevRel).
We chatted with Lorinda about what it’s like to be on the receiving end of developers’ API programs and the benefits and drawbacks she often sees.
The Bad: APIs are Pervasive
“When your business depends on somebody else’s API performing properly, being dependable, being understandable, then the need to have a direct line to people who can answer our questions quickly is super important,” shares Lorinda.
The pervasiveness of APIs is equally good and bad for this reason. They spread so widely throughout an area and often have many people involved that it can be hard to get the answers you need when something goes wrong.
For Lorinda’s team, when API incidents arise, they can struggle to figure out if it’s on their end or on the API provider’s end; there can be a variety of issues to source. Whether it’s delays, performance problems, API utilization, or another kind of change, every API provider they work with communicates that differently. With so many cooks in the kitchen, sometimes communication barriers are present, and uncovering solutions can be difficult.
The Good: Creating Agency with OpenAPI
“OpenAPI is a passion of mine. Obviously, I’m a fan of it. I think having a standard that we adhere to so we can have easier conversations and easier ways to adopt each other’s APIs is crucial,” shares Lorinda.
As a group on the receiving end of the API provider, OpenAPI creates the agency needed to utilize all of the tooling with their third-party APIs, which helps Lorinda’s team increase efficiency. Going to a provider and asking them to share their OpenAPI definition with their engineering team allows them to plug it into their own internal tooling. From there, they can create, mock, and conduct testing without bothering the API Provider for their entire sandbox.
“There’s lots of benefit to having that kind of standard. We are actually on our own journey at BetterCloud of embracing OpenAPI for our own APIs. So our internal APIs are starting to standardize around OpenAPI, and we’re going to be looking at our external API to make sure we standardize that as well because it helps to have that kind of common language,” shares Lorinda.
However, the most valuable thing for Lorinda’s team has been joining the OpenAPI Initiative. BetterCloud became a member company, which gives them access to all kinds of Slack channels, resources, people, and workshops.
“APIs are so pervasive that we all rely on each other, and that really was the dark magic. But having a community of experts to work with is the real light magic. This is the sparkly magic of we’re all in this together. And if we can find each other and find these communities, there’s so much knowledge that we can share and so many of our experiences that we can share,” shares Lorinda.
For Lorinda, the community aspect of the API world has been near and dear to her heart from the beginning and is immediately amplified by things like the OpenAPI initiative. Not only having a common framework for all to use but being able to tap into that group of people who are learning and shaping the API ecosystem, is truly valuable.
The Greatest Impact You Have While Working with API Providers
“One of the biggest knobs you can turn to impact that relationship with your API provider is via developer relations. We are the developers, and we need a relationship, but we need a really robust one,” shares Lorinda.
When working with API providers at BetterCloud, there are a variety of DevRel setups that their team interacts with regularly. Sometimes, it’s a Devrel person who can eventually get an answer to your questions, but they are serving as conduits to engineering teams.
On the other hand, there are DevRel programs that have that in-depth knowledge at hand. These advocates can be present, running proof of concepts right alongside Lorinda’s team to solve an issue.
“That’s the kind of DevRel program that we work best with and that you want on your team. Those with that in-depth knowledge can duplicate things that we’re seeing and understand what’s going on. They can actually help us get out of the situation that we’re in,” shares Lorinda.
The other important thing to note when working with API Providers’ DevRel teams is that those Developer Advocates should not be reporting to marketing in an ideal world. Lorinda notes that your DevRel people are not just there to sell the API, and they should not just be there as a conduit to product development or engineering.
There needs to be an infrastructure relationship with a direct connection to the engineering or developer teams for a DevRel team to really be able to function at the most effective capacity. This is crucial for DevRel teams who will be interacting with users like Lorinda’s team, who are on the receiving end of their APIs.
In the end, being on the receiving end of an API provider has its ups and downs, but when built with a solid community foundation and mutual understanding, it’s easy to see the path to success. Check out our podcast for more API innovation stories, best practices, and tips for scaling your own program.
