With special guest Lorinda Brandon of Twilio.
In this episode of APIs Unplugged, Mike and Matt sat down with Twilio’s Director of Software Engineering, Lorinda Brandon. Brandon has extensive experience both as an engineer and a product manager — leading technical and product teams at Twilio, Capital One, SmartBear, EMC, Intuit, Interleaf, and the U.S. Air Force. We wanted to ask her about her current work with Twilio and SendGrid along with her work in product management throughout the evolution of software products from packaged disks to on-demand APIs. Finally, we wanted to get her take on the advice she offers organizations striking out on their own API journeys.
What follows below are just some of highlights of our wide-ranging and engaging conversation with one of the people who continues to help shape the API tech and product space, Lorinda Brandon.
Working at Twilio (00:50)
At the outset, Lorinda talked about what it is like to work at Twilio in general and with the SendGrid teams specifically.
Lorinda: “I work in the Denver office and I manage an engineering team that we call the customer lifecycle team. And we, basically, are the business platform for the email API… We’re just now building the connective tissue between the two companies; integrating our systems.”
API products, pricing, and distribution (05:37)
We then moved on to talking about the patterns of success in companies that offer APIs as products.
Lorinda: “We’ve been talking for years … about how important it is to view your API as a product holistically. And that’s everything from understanding what the customers want, to building on your requirements, to documenting them for an external audience as well as, you know, doing all the competitive analyses, all the things that you would do for a product … That is a very hard barrier to cross for people — to think about APIs as products instead of technology by itself. But when you’re in a company like Twilio, where it started with an API, and SendGrid started with an API, …we don’t have to convince them that an API is a product because that is the product.”
One of the interesting discussion points was the whole area of positioning and pricing of APIs when Lorinda spoke about her team’s work on the SendGrid billing platform.
Lorinda: “We spend a lot of time talking to the Twilio billing team as well. And we build differently, we think differently because these APIs have different purposes. And so you come at it differently. ‘How do I position my API, how do I price my API? What kind of offerings am I gonna put out there for the general public?’
“And so, if I can give a concrete example, Twilio Messaging started out as an SMS API, right? So, if you think about that, like, when do you use SMS? When does a company use SMS? It’s fairly transactional… If you think about when a company uses an email API, that’s mass emails, right? This past year, we processed 4.2 billion emails through our API on Black Friday alone, just on one day. And then we did it again on Cyber Monday with 4 billion emails. So if you think about the pricing strategies and the offerings, for those different use cases, they’re very different. So you’re gonna pay differently.”
This led into the notion of unique packaging and distribution strategies, too.
Lorinda: “If you think about a traditional product company, they may have two or three different products. They’re not all packaged or priced the same way. They don’t all have the same audience that you’re selling it to. And it’s true also of APIs. It just, sort of, proves out this thing that we’ve always been saying, which is, an API is a product and you can think about it exactly the same way you would any other product.”
Product management, engineering, release management (12:30)
Matt then asked about the relationship between product management and engineering at Twilio and SendGrid.
Lorinda: “Our product managers tend to be fairly technical because, of course, they are talking to and serving technical audiences. These are trained product managers who understand how to do this work. I would say we share a lot of thoughts and opinions, and we strategize together. We’re very tightly connected.”
Mike asked Lorinda to talk about her long-term view of the maturity of productizing software in general.
Lorinda; “I have worked on boxed software where there was no other option. We didn’t do APIs. But when we [finally] did, I remember in the early days we built a lot of APIs that were all one-off, no standards. … [W]e are far more nimble now. We understand the value.
“We’ve built libraries that people can use. We know how to serve up an API. And so, it’s much simpler now to do all of this than it used to be because all of those things exist. We didn’t have that in the beginning. And so, I think that’s really powerful and it makes it much simpler to not only start off with a fresh API, but also to manage and maintain your existing APIs.
Matt followed up with a question about patterns in release management for APIs.
Lorinda: “I think, first and foremost, a very good API strategy is ‘Don’t break’ the implementations out there. You can’t avoid it all the time — you should try but you can’t always predict the future. [M]aking sure that you’ve updated everything on your end to make it easy for them to update on their end, that is, by far the most important part of updating your APIs.”
Internal APIs (26:20)
The conversation then shifted to dealing with internal APIs.
Lorinda: “We build a lot of internal APIs. And, you know, we fall into all the same danger zones that everybody does, which is, ‘Oh, the internal API, I know I can explain it to people on the Slack channel.’ I think that philosophically, we all agree that [it] would be ideal if we did treat all our internal APIs the same way we treat our external APIs. And I will say big kudos to Capital One where I spent a number of years because that is how they treat their internal APIs. We have an aspiration inside the hallowed halls of Twilio to get to that point, but it’s a big investment.”
Advice to those starting out (29:00)
Finally, we asked Lorinda what kind of advice she would give to those starting out on the API journey for their organization.
Lorinda: “One of the key pieces of advice I would give people is don’t look to just one company. Look to various companies and figure out who’s doing the thing that is closest to what you wanna do. And then figure out, ‘How do I adopt the best practice from here and the best practice from there?’ It’s not one size fits all.
“And the other big piece is think hard about your business model and how people will be using your API, what it’s intended to do. Be flexible, be open. Think hard about your space and where you want your API to be positioned in the market. And then build your practices around that.”
Follow the podcast on SoundCloud or subscribe to our newsletter above to get summaries of the episodes.
