The Dark and Light Magic of APIs: The Consumption Side of API Programs feat. Lorinda Brandon, VP of Engineering at BetterCloud

Show Notes

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.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

Welcome back to API intersection here again today with our cohost Adam Devanter and a lovely and old friend guest, Lindy.

Brandon says your name is Lorenzo, but we call you Lindy, and that's okay, right.

That is totally great and nice that I didn't have somebody that had to ask how to say their name and a new their secret name, which is even better.

So, Linda, you have been a lot of different places with interesting and big names and others not so well known, but always in the API scene everywhere.

I know Adam and I have ever been.

We end up hanging out with Lindy and catching up, and it's been way too long, and our pandemic friend hasn't helped.

But Lindy today is a better club, and I guess maybe tell us a little bit about what you're doing there and kind of where you have fit in the API world over the years.

Yeah.

So I just joined BetterCloud.

I just passed my three month Mark.

So a whole quarter, I've been a BetterCloud.

I'm the VP of engineering there.

So I run all of the software development teams, and Better Cloud is for people who haven't heard of it.

We are a fast management platform.

So what that actually means is we're geared towards the It professionals.

So if you think about especially right now, we were talking earlier about all of the transitions going on, people leaving their jobs and joining new jobs and all of the companies that are moving to the cloud and embracing fast because they've got a remote workforce.

It's a lot easier to do it that way.

That means for it folks.

That's a lot of onboarding and offboarding and permissions and security issues with files that are shared and knowing which files are being used and which applications are being used in your organization.

And that's what BetterCloud does.

We're a staff management platform that we integrate with just about everybody.

We're deeply entrenched in third party APIs.

We are big API consumers.

We basically create an interface where it admins can come in and do things, set up workflows and do things with one click.

So I need to onboard a bunch of employees.

That's better cloud automates that for you.

So you just set up a workflow, hit a button and magic happens.

Magic that relies a lot on APS.

And yeah, we were discussing my background at Zapier and all of the unique problems you get to see when you are using more APIs than anyone else, anyone else.

So yeah, I'm excited to dig into some of that today.

Welcome.

Yeah.

I think it's a bit of shift of gears.

We've talked a lot about how to build APIs and microservices and externalizing.

This huge big picture.

I think today is like a fun reflection on the other side.

I personally reflect on this a lot that what got me started.

And being fascinating in APIs was using a couple of really crappy ones and feeling like I could do better than that.

And I'd learn about it.

So I don't think I've ever been in the better Clutter's appear position of consuming tons of things.

But everybody I've ever met that does that always has interesting insights.

And I think that's what we want to drill into with you today.

I don't know.

Where do we start? I feel like that's a big subject.

And you guys are both that's in your wheelhouse.

So where do we go with this? I could give Adam, definitely give me your perspective, because I think you've walked in a lot of the same shoes where moving from.

So I was a capital one for a number of years and helped build their API program platform.

All of that with a large number of very talented, brilliant people.

And in that space, we were creating APIs more than anything else.

And we were worrying about, how do we present ourselves as good providers? Right? How do we provide the right documentation and the right portal and the right experience when it comes to versioning and change control and all of those things? And then I went to Twilio, which is also an API provider.

So again, focused on all of that developer experience.

What does that relationship look like? What do you worry about when it comes to the kinds of things you expose? And how do you make money off of that? And then going over to Better Cloud, where we do have an external API, but our core skill, our core strength.

The core thing that we do is we consume APIs.

And so all three of us have gone on stage and told everybody, here's what you should do when you're providing an API.

And as a consumer now have so many APIs, you look around and you go, wow, we all heard the same words, and we all have the same checklist.

But how we actually accomplish that checklist is really different.

And how we interact with one API provider is not necessarily how we can interact with another API provider.

And so we have to adapt constantly all day long to different ways of consuming APIs consuming documentation.

Working with Devrel, all of those things are different company by company, and when your business depends on it, it's crucial that that work for you and that you can contact switch enough to get your work done.

I don't know, Adam, if you've had the same experience, but that's been the enlightening part of BetterCloud for Me.

Yeah, I'm curious for well, and first of all, I think if we look at the themes that we've heard on this podcast so far about consistency within API programs and how you don't always have control over what was the case before, and you're trying to make things better now.

But I think a lot of the same problems some of the listeners are dealing with internally, just the same as having to deal with these multiple approaches to APIs.

I guess the difference being that you have a lot less control over someone else's API.

But what are maybe those knobs that you do have to be able to even understand where the gotchas are.

Yeah.

And I feel like some of the things that I'm learning now being on the receiving end of APIs programs is when your business depends on somebody else's API being performant, being dependable, being understandable the need to have a direct line to people who can answer our questions quickly.

Right.

Because we're struggling with incidents that come up and we're trying to figure out, is that us or is that them? And where is that delay happening? And why are we not using their API correctly? Did they change something, or are they having their own performance problems? And every provider communicates with us a little differently and we have to communicate back to them a little differently.

And so I feel like some of the knobs you can turn.

I know we've said this in many different forms, but one of the biggest knobs you can turn is your developer relations, right.

We are the developers and we need a relationship, but we need a really robust one.

So in some cases, you're talking to Deborah, who can't answer your questions.

They are basically conduits to engineering teams, and that's not helpful to us.

Right.

We have engineers who just want to talk to people who really have in depth knowledge.

There's other Dev Row organizations that do have in depth knowledge and can be right there running proof of concepts with us.

Right.

They can duplicate things that we're seeing and say, oh, yeah.

I see what's going on.

Let me get this endpoint corrected.

They can actually help us get out of the situation that we're in.

So I think it's easy to say I'd love them all to be the exact same thing.

I also know that not everybody has the same budget, the same emphasis on their external API.

So I get that it can all be the same.

But that's what to me is the biggest pain point and is something that a provider can really help tune for people like us who are consuming so many APIs.

It's interesting.

You said we've got to build a relationship.

This developer relations function probably exists.

If there's some kind of significant API service, I will say one of the things I tell people all the time is don't have your, like, Devrell group reporting the marketing because it should do more than that, right? I mean, because it's like they're not just there to sell the API to people, in a sense.

So that's one bit.

But you did say they have this conduit to sort of the product development or engineering, which isn't enough.

And so I want to drill into that.

Are you seeing that kind of more dedicated, like API support function to answer questions and fill in the gaps there? Or is it more of, like, kind of an infrastructure relationship as far as direct connection into engineering or opt or something? Let me give you some examples.

I'm not naming any names, particularly, but let me give you some examples of things that really work well for us.

We have a couple of providers that we have a shared slack channel with, and we know that some of those people are product managers on that slide channel.

And some of those people are marketing who are worried about events and want to talk to us about events.

And then there are some people who are engineers.

We can go in with any one of our many questions, right.

Sometimes it's hey, we notice we're getting lag alerts from this particular function in our product.

We think it's related to your API.

Is there somebody who can look at that? Right.

So we want somebody who can look at logs and get back to us quickly because we have a deprecated function in our system, so our customers are suffering.

But on the other hand, sometimes we just want to say, you know what I wish you had.

I wish you had this in the payload, or I wish you had this endpoint.

Who do we talk to about getting that on your roadmap? In that case, we want the product managers, so there's never just one type of interaction we need.

It's like any other product.

This is also something we've said for a long time, right.

Your API is a product, so it's like any other product you need to talk to.

We're your customers.

We need to talk to you on multiple levels sometimes.

So having run lots of APIs and programs myself before been a big, heavily involved.

Some of what you're describing sounds horrifying sense of like all these people using the API can just ask random questions and everyone has to jump.

I guess it doesn't sound very scalable, but I also know that the flip side of, like, file a ticket, and we'll get back to you within 48 business hours when your thing is down, you're losing money.

Are there middle roads between the intense relationship of constantly hearing from everyone and waiting on a queue of tickets? Yeah, that's the exception.

What I just described is like the perfect scenario for us, but it is the exception to the rule.

We're perfectly happy creating support tickets for things that are not urgent and get back to us when you get back to us.

At least we know, you know, we're reporting an issue or we're asking for a feature or whatever it is.

But there are times when things are really urgent and we can't wait for that.

And for the most part, our big API providers, the ones that really drive the most business for us.

We have account managers, and we have a way to escalate to them and say, I need to get somebody engaged.

And sometimes that's a Dev row.

Sometimes that's like more of a Tam type of person, but they need to have access to create urgency on their side.

Right.

And not all of them do sometimes.

And I've worked in this.

I've managed to so I know how this works.

And so I'm deeply sympathetic to the situation that they're in, and I get it.

But also, like, our business is suffering because we are reliant and this is the world we live in now.

Right.

This is the old saying, be careful what you wish for, right.

This is what we all wish for.

When we were all running around in the early stages of APIs, and we were all going, Everybody should have an API.

And, oh, the magic that happens.

Well, the magic has this dark side to it of we rely on each other now, and we're still in many ways working in an old model that doesn't acknowledge the reliance we have on each other for our own businesses to be successful.

So I think that's part of the maturity that we now need to figure out how we adapt to.

So the dark magic of APIs is a great headline that I think you should absolutely use if no one has used it yet.

And I look forward to reading that article.

One thing that occurred to me, as you were saying that in those discussions that you have with the company, regardless of what the conduit is, this was something that was the case at Zapier.

You have a customer in common.

And in your case, that's probably a pretty big customer because they have enough of an onboarding issue that they need to automate all of that does that sort of framing things in terms of the business benefit help you in those conversations? Not that I've noticed.

So maybe I should do it more often and do it more loudly.

But here's the thing, right.

We do have big customers.

And so we are hitting those APIs like crazy.

We run into rate limits every few minutes because we literally are processing millions of transactions in a day.

And the amount of data transport that happens in our system is pretty amazing.

We are a big customer of these APIs.

We're paying for this access, and we actually make good use of it and have to increase our rate limits pretty frequently.

So I guess what I'm trying to encourage our organization to think of and to take the stance of is we're the big customer.

Right.

So, yes, we have big names, big logos, who are our customers.

But to those APIs, we're the big customer.

Yeah.

I think it's incredibly insightful.

I mean, I like that you've mentioned some of these corollary functions, like correlate to serving APIs that we wouldn't always think about as an operational need is kind of Devrell or evangelist types account management product.

People like stuff that if you go, what does it take to run an API? It wouldn't necessarily come to mind first.

But I think I always dreamed that gosh, if we had people that really knew the API super well and could answer those questions amazingly well and have access to all the right data and the right engineering people to just get it solved, wouldn't that be great? But I feel like it's a weird hiring place.

I was like, if someone knows it that well, they're going to be an engineer and just work on it.

But if they're an engineer working on it, they're shipping new value.

Who's left? Who's in the middle of all that? And to your point, who recognizes the business context like an account manager would to understand that.

Yeah, you're the big customer, Lindy.

We're going to treat you right.

It's a weird gap.

All right.

Well, I don't think as an industry, we sold it.

That's what I was saying earlier.

We've created this method of building products that relies on each other in an ecosystem that isn't built for that.

I think all of the Dev Rell things that we all talked about was so small scale compared to what the world really looks like right now.

And so I don't have the answer for what it should be.

I just know that it's frustrating to have to navigate all the various ways that people have interpreted the need.

It's funny to people who don't necessarily work in APIs and integrating big platforms, and they go like, well, APIs are kind of the thing that happens when you press the button on your phone to do something.

And if it's integrated with something else, it is a messy Grammy dirty business that you don't want to know about.

Look under these covers.

That might be our summary for today, which is great.

I think two listeners, if you know a pattern that works well for this, tell us about it.

We want to hear about it hit us on Twitter.

Well, one of the things in the sort of the business case not necessarily hitting the Mark kind of does go along with some of the things we've heard from other guests about it just connecting.

You have this super technical thing, which is APIs, and that needs to connect to the business, the business strategy and requirements.

But that's not always obvious to everyone who sees it just as this technical thing.

And I think that happens as you're building an API, and that happens clearly as you go to attempt to consume all these APIs.

Also, we talk all the time about that disconnect, right? Like, between the business focus and the API focus and how, like, do they even line up half the time? So I didn't interrupt you.

But it's well, I look at the way that we have attempted to solve some of these issues is with a great open format, open API which again, is focused exclusively on those sort of technical aspects.

I know you've been involved in that for a while.

Maybe talk about how it has so far helped solve some of the issues we've had.

And I don't know, is there some answer within that movement? Yeah.

So obviously this is a passion of mine.

I've been involved with Open APIs since it was founded because I was on the Swagger team.

I think it's a great 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.

We can use all of the tooling with our third party APIs.

Right.

We can go to a provider, which we do and say, hey, can you share your Open API definition with us? We can plug it into our tooling, and we can create mocks, and then we can do our testing and we can do all these things.

We don't need to bug you for a sandbox, right.

Because we can do it ourselves.

So there's lots of benefits to having that kind of standard.

And we are actually on our own journey at Better Cloud.

They had just started before I joined of embracing Open API for our own API.

So our internal APIs are starting to standardize around Open API, 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.

But I'll tell you the thing that has been the most valuable to us.

And I say this in all sincerity.

I think most people, if they know who I am, are going to say, oh, she's totally biased on this.

But I say this with all sincerity.

And I think the betterclouders would back me up.

When I joined BetterCloud.

We joined the Open API initiative.

So we became a member company, and that gives us access to all kinds of slack channels and people and meetings and initiatives and working groups and whatever.

And the amount of learning that happened was so rapid, right.

Because everybody's out doing their own before we joined the Better Clotters were out doing their own research, reading this blog, reading that blog, looking at this GitHub repository, trying to piece together all the stuff.

And then we joined Open API, and they had access to all these people and all these other companies who had already tackled some of this.

Right.

And they could go in and say, how did you do this and get all of this input? And they had access to everybody, the Async API people and the Open API people and GraphQL and all these experts in all these different areas.

And so that is I think one of the we talked about, like, now APIs are so pervasive that we all rely on each other.

That was the dark magic.

This is the real magic, right? 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, and sometimes the people that we are relying on those companies are in that group, too.

And so we can have conversations with them outside of just I need to escalate an issue to you.

But hey, let's learn this thing together or teach me how you came to this place, right? That is, as you guys know, like, to me, the community aspect of the API world has just been near and dear to my heart from the beginning.

And I think the Open API initiative has that in spades.

I think that's the real benefit, too, is not just the Open API spec being a common framework for all of us to use, but this OAI community being this group of people who are learning and shaping the API ecosystem is really valuable.

Yeah.

I signed on from the start when I was at PayPal when that all kicked off, ended up kind of jumping out of that, frankly, because living in Spain for a couple of years, everyone wanted to do stuff at lunch on Fridays, and I'm like, I'm not doing this thing on a Friday night, but now back at Stoplight, obviously, we're kind of in a way an Open API tooling provider and part of that community, too.

I think there's a lot of other interesting stuff out there and new ideas coming together and things taking hold.

But man, out of making sense of the rest API world, I think OpenAPI has really opened it up, and I wouldn't say it's where it's going, it's where it's at.

And that's not just because I have CTO at a company that certainly puts a lot of stock in it.

But even if I wasn't working here, I'd say it too.

You see, it going on and people that work in this space.

Cool.

Well, that was quite an awesome Open API pitch, a dark, depressing black hole of grimy messes between platforms.

But hey, I think it's an awesome counterpoint in some ways that we talk about these idealistic notions of building great API platforms and what it really takes.

And the end of the day, get somebody on the phone.

Exactly.

Sure would be nice when your API? Yes.

No, I love it.

I love the reality check, and that's where the conversation about providing goes, too, in the end, is being able to provide an API that answers the actual questions requires actually talking to people who are going to use it.

It's interesting that both ends of this kind of end up at that collaboration.

But maybe not that surprising to the three of us, and hopefully not to many of the listeners.

And if I can just provide, like a parting thought, right.

I was watching a landscape.

This is how exciting.

I am.

But I was watching a show about this landscaper documentary about this female landscaper at a time when there weren't female landscapers.

And she was really a landscape architect.

But she talked about desire paths and about watching a space before you start planning the public garden.

She was a public garden.

She designed a lot of big public gardens, watching the space to see where people walk before there are pathways, because then you find the desire paths, and then you put the walkways where the desire is.

And I think I see that also as sort of a guiding principle to API design, of thinking about what do people want to do with your API? Not what can they do, but what do they want to do? Where are they trying to walk? And are you creating a path for them? And I think as a consumer of so many APIs right now, it's become so visceral to me to be thinking about it that way.

Where do we want to go with your API? And how do you create that desire path for us? Wow.

This is why I love doing this podcast.

You talk to smart geeks like yourself.

Who big beep.

It's beautiful.

No, I think we've hit this a lot on the show.

That like, let's not forget the word design and API design, and that it's at the core of everything.

Like, you can't get around that problem.

And if you didn't do that homework up front, everything else is going to eat you up later and design work.

If you hang out with designers is a little soft and fluffy and metaphoric and asking fundamental questions and you can't get away from it.

You got to do it.

So I love it.

It's beautiful.

Wendy, thank you for sharing.

Adam.

Any parting thoughts on this one? I feel like this is in your world, in your camp.

that's a conch shell.

I clearly said the 01:00 hour was nonconsh hours.

I made that clear.

Maybe your village needs help.

Maybe that's okay.

No, I think the call to action being to open up those conversations and look for ways.

Maybe it's not this shared slack channel, if that's too high Fidelity, but finding ways to be able to have those conversations with others.

And.

Yeah, that was important, too.

Yeah, that's what I'm pulling away.

And yeah, thanks for being part of this episode.

Oh, thank you for having me.

It's great to talk about this stuff, and great to see you too.

Again.

Appreciate the invite.

I can't wait to hang out and have some drinks together in person.

Against him.

Yeah.

All right.

So let me hit the stop button.

Here.

There we go.