Twilio's Quinton Wall Emphasizes API as a Product

Quinton Wall, TwilioQuinton Wall, Twilio

In today’s business climate, the need for companies to be agile, innovative and able to scale is greater than ever. APIs are drivers for these needs but before an organization can reap the benefits of APIs, it must set up an API strategy.

Developing an API strategy can be broken down into four stages: establishing your strategy, aligning your organization and culture, building the technology needed to support the strategy and engaging with your ecosystem. This series of articles examines the fourth stage.

All successful API providers make it a priority to actively engage with their internal and external developer communities. Doing so helps build a vibrant ecosystem of developers and partners who can extend the reach of an API strategy. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article looks at Twilio, a communications Platform provider that enables voice, video, and messaging capabilities (many of which, like SMS, are underpinned by mobile telephony infrastructure) to be embedded into Web, desktop, and mobile apps. We spoke to Quinton Wall, Sr. Director, Platform & Developer Experience at Twilio.

Twilio has always believed in treating its developer community as first-class citizens. Nowhere is this approach better exemplified than in its Documentation where the first touch developer experience is prized above all else. Twilio has a number of quick starts for any of its products with the goal of guiding a developer from initial understanding through to actually using the product. This commitment to making sure developers have an excellent experience helps increase their engagement and is core to how Twilio treats its community. 

Wall also spoke about how Twilio makes a concerted effort to provide developers with as many hands-on learning experiences as possible to help them in their journey of discovery.To find out more about Twilio’s approach, read the transcript of the interview below.

Full Text Transcript of Interview with Twilio Sr. Director, Platform & Developer Experience Quinton Wall

ProgrammableWeb: My name is Wendell Santos, editor of ProgrammableWeb and today I’m speaking with Quinton Wall, Sr. Director, Platform & Developer Experience at Twilio. Thank you for taking some time out to speak with me today.

Quinton Wall: Yeah, it's great to connect. Quick background for me. I've been at Twilio for two years, so I focus on platform and developer experience, but my background for 10, 12 years or so is Developer Relations. I spent a long time at Salesforce and Heroku building up those developer communities there and building a bunch of the apps on the platforms. Now I’ve switched over to Twilio. I've been using Twilio for probably even longer than that. It was a great opportunity to join the team here. So I can certainly talk about any of the developer community and dev-rel aspects.

PW: That's great. Twilio's been known for a long time for having a really strong engagement with their developer community, built for developers by developers. That's kind of been your guy's DNA for the longest of times. So I'd love to hear at a high level, what is your approach to developer engagement? And what are the channels that you're going through? 

Wall: Sure. One thing to note, we are announcing at SIGNAL (SIGNAL is Twilio’s annual customer and developer conference), that we surpassed 10 million developer accounts on our platform all time. That's a huge number and it's pretty hard to comprehend these things. But what it really means is that Twilio is in the toolbox of 10 million developers around the world. And a lot of that is because we provide those APIs and SDKs. And one of the things that I was always fascinated at Twilio with being known [for] since day one [is] having great docs and great developer experience, and I was always fascinated that we treat docs here like a product. We have pull requests. We have releases. And we make sure that everything is continuously updated so it's kind of an erosion resistance approach to building on top of Twilio.

And I think one of the cool things, just if you want to think more about numbers, in the last year alone we did just over 180,000 production deployments. So in terms of what we're continuously providing to developers to innovate, I just see that there's no finish line when we look about what they're doing here. We're continuously launching. And I think probably the geekiest thing to come out of Signal this year is we actually are offering a developer mode in our keynote. So if you've got the Twilio CLI you can enable developer mode and see announcements of information push like your command line in your terminal. 

PW: That's fun. You mention great docs and it sounds like that is very core. I've been to your site and you have so many products and so many docs, keeping them updated sounds like a big lift. How do you manage to keep those up to date so that developers have that great experience?

Wall: The good thing is a lot of those processes like SDK and docs are automated but as a dev you can always create a pull request if something is wrong or something is different. We start with a JSON definition of the API, then use an internal tool to generate 100% of the API docs, helper libraries, and the CLI. But one thing we try to focus on a lot is that first touch developer experience. So one of our most common and most popular development tools is the quick starts. We always try to make sure that we provide a quick start for any new product that comes out. When you look at some of the blog posts, for instance, on Event Streams, there are complete instructions on how to use the Event Streams from the developer's perspective. So for us, those quick starts are really the thing that a developer needs to get from understanding and to learning to knowing and then doing. We want to make that process as seamless and easy as possible because for devs, that's what they want to do. They want to solve a problem. 

PW: Do you have any KPIs around that? For example, "Hey, this quick-start should be able to be completed in five minutes, 10 minutes," whatever that number may be? How does that work?

Wall: I don't think I have one on the quick start, but we do have instrumentation in the product that goes from when a developer signs up to when they become what we call active. When they've created a certain number of API calls within a month, we want to make that window as short as possible. The quicker that we can get them to being product active, the better the development experience.

PW: Let’s talk about languages for a minute. Twilio offers a lot of languages within the documentation. That's a big lift. So how do you choose which languages to actually support on the site?

Wall: I'll have to talk to the team on specifics on that, but there are some popular languages that we know, like obviously Python, iOS, Dot net, Java. Those are the big ones. But there are definitely ones that fill specific purposes like Go is becoming more popular. And I think when we launched Twilio Flex we decided to go on React.js because that's a very popular, open source standard for this. So we really try to look at what the dev trends and where they are going. And the good thing is JavaScript is pretty generic. So everyone knows that at some level. And that's where I think something like React, Node.js, those areas are certainly key and important.

But we have customers across all different spectrums of size these days. So that's why it is important for us to support all different platforms. The good thing is we have a great system to be able to generate a lot of these documentations. So we have a good experience. Because I know coming from a dev-rel background where we would hand roll some of these experiences and hope it would feel more like a Ruby dev versus an iOS dev. Twilio does an amazing job of making it feel native for that language. And I think that's really key because there's nothing worse than, for instance, writing Java code like a Ruby person or vice versa. It just doesn't work. And it doesn't give you a good experience. So the more native feel we can provide it, the better.

PW: Do you have an example of how you make it feel native for a particular language?

Wall: To give you an idea, the best I can do is say you’re an iOS developer, so you like closures versus blocks. And one of the early things we like to do is we host what we call first look hackathons, where we invite developers in our community to get hands-on with, say, one of the new products or APIs. Effectively they can kick the tires. And what we want to be able to do is get as much feedback from them in our community as possible. And I often think of developer relations as that voice of the developer back into the communities. So, if you think closures are way better than blocks or switch statements or something, I want the person that is familiar with the latest technologies inside that community space. And I want to take that voice and bring it back into Twilio to make sure that they're heard.

PW: Yeah, exactly. It's clear that your site is an important way for you to connect with developers. Do you use other channels outside of your site to engage with your developers? Are any of those proven to be pretty successful over time?

Wall: One of the things that we've done a lot is what we call customer hackathons. We will go to a customer site and do an onsite hackathon; obviously these days it's virtual. We do this because the biggest thing that we've found with Twilio is you have to build something to learn it. That's the best way to do it. And at Signal we provide something that we call Superclass. We've taken that on the road in the past and made it virtual, part of our world tour events that we call Engage as well. So it's important to us, even in the virtual world for developers to get hands on. 

I'm not sure if you've gotten the chance to play around with Twilio Quest, a gamified learning platform. It's a really cool, fun platform. And I don't have the statistics in front of me in terms of adoption, but we're launching a number of new features and a number of new modules at Signal this year, because now that we are all separate and socially distanced, this is a really good way to start to enable developers to experience using Twilio as a service and API and integrate them into their platform.

PW: So would you say that Quest has seen an uptick in adoption, especially since COVID hit?

Wall: Certainly. Yes. So what we find is that we try and enable it across the board. So our docs and our experience are really good, so you can tell that we're doing well. You can get some more personal learnings through something like superclass, if you're attending one of our events and we're, again, offering them virtually as well. But then also some really fun guided learning instructions with Twilio Quest. So it's kind of important to get a bit of everything.

PW: Can you talk a little bit about the makeup of your Dev Rel team, if that's even what you call it internally? What does it look like?

Wall: So the team we actually call Developer Network. And I think it has more than 60 people now. Within Developer Network there's a team that's responsible for docs, there's a team that's responsible for community and they're doing the hackathons and that kind of thing. And then there's generally the evangelists that focus on a particular technology. Often they’re the ones building crazy things on Twilio and writing blogs about exactly how they did it. And their goal is to inspire.

PW: That's awesome. This is a question, I like to ask because it unlocks some nuggets. Do you ever look at other providers and look at how they're engaging with developers and say, "Hey, they’re doing something that's worth looking at?" 

Wall: I think, especially being a developer myself, there's always a cool technology out there and something you need to learn. So we have a lot of Slack channels internally, for instance, with the developer experience and dev-rel teams, sharing sites and information that we know really well. Like I still think one of the most amazing tools that's out there at the moment, and I'm an iOS developer, something like Visual Studio Code blew me away in terms of how open an approach that Microsoft took to be able to create a really cool IDE. How they integrated things like GitHub as well. I think that's a good learning just to show that tooling and dev experience is really, really fundamental here. Coming from Salesforce and Heroku, Heroku did an amazing job with developer experience back in the day as well. I think we try to take a little bit of the DNA from everybody and continue to advocate for the developer experience being really, really key and really critical in what we do.

I’d like to thank Quinton Wall for taking the time to speak with me and give ProgrammableWeb’s readers a glimpse at how Twilio thinks about engaging with its developer community. This is part of a series of interviews with developer relations experts such as Nick Tran at Postman. Be sure to keep an eye out for future interviews coming soon.

Be sure to read the next Ecosystem Engagement article: Randall Degges Highlights Okta’s Scalable Approach to Engaging Developers