Twilio's Jeff Lawson: Building an API Empire
As CEO and co-founder of Twilio, Jeff Lawson has helped propel the idea of communications platform as a service (or, as he likes to call it, "cloud communications platform") into the enterprise consciousness. For his pioneer's insight on API-based communications, Lawson is regularly featured on technology sites and showcased by major business publications and investor forums. And, just recently, he was tapped as a keynote speaker at Enterprise Connect 2017.
Twilio went public in June, not long after its eighth anniversary, and saw revenues double in 2015, to $166.9 million (read related post, "The Biggest Event of 2016"). The company recently reported its third-quarter results, citing total revenue of $71.5 million, up 62% from the same period in 2015 and 11% from last quarter. Twilio today has about 650 employees, well over half of whom are in technical fields. Technical or not, all employees -- "Twilions," as they're known internally -- are expected to build an application using Twilio services.
Jeff, who grew up in Michigan outside Detroit and obtained degrees in computer science and film from the University of Michigan, has a strong entrepreneurial drive. In addition to Twilio, he founded Versity (education) and NineStar (sporting goods), and served as first CTO at StubHub (ticket marketplace). He even held an entrepreneurial role at Amazon, serving as one of the first product managers at Amazon Web Services (AWS).
Jeff founded Twilio with co-founders Evan Cooke and John Wolthuis while living in the Seattle area. In 2009, he moved Twilio to San Francisco, where he lives now with his wife and two children.
I've been watching Twilio from the beginning, and openly admit to not getting it at first. I was not alone; in the company's early days, more investors turned away Twilio than Jeff cares to count. This isn't a problem any longer. Twilio's API model is well understood now, and the CPaaS space is getting crowded. Twilio does enjoy significant first-mover advantages, including a portfolio that includes 16 product lines.
I had the opportunity to meet with Jeff to discuss Twilio and the industry, and our conversation went something like this:
I've heard you refer to Twilio as a "third wave" company. Can you clarify?
We refer to this third era of computing as the "age of the platform." The first era was selling on-prem apps to the CIO -- long timeframes, big price tags, high-stakes software. And it was all back-office -- your big ERP systems, etc. The second era was SaaS -- apps sold to LOB owners. Salesforce, Workday, etc., helping LOB owners run their part of the business, but still using off-the-shelf, behind-the-scenes software.
The third era is about building software, not just buying it -- because how companies differentiate today is digitally. Those companies that build will win. The third-era software companies are those providing the building blocks -- AWS, Twilio, Stripe, New Relic, Google Maps, etc. These are the raw ingredients in every app you use every day.
This is the age where developers and businesses are free to rapidly experiment and innovate with scalable, flexible, cloud-based building blocks that empower them to build the future of customer interaction. For example, AWS opened the door for developers to start new companies, products, and services at a fraction of the capital they would have needed 10 years prior -- all through the power of the platform.
Tell me about how Twilio communicates internally...
Twilio has 11 global offices and over 650 employees, yet we don't have a PBX or phones on our desks. But we do have apps that we've built on Twilio to help employees get their job done. For example, every employee has their own Twilio conference line. As we build more products, the roadmaps are often guided by our internal use. For example, we now power website chat with our Programmable Chat product, and two-factor auth of the Twilio account portal is powered by Authy.
We use our own products and, in fact, many of Twilio's products actually started as internal tools we used in R&D. For example, we built our recently released Voice Insights as an internal tool, and then realized it would be great for customers [see related post, "London Calling and It's Probably Using Twilio"]. Same thing for Twilio Sync; we used it to power Programmable Chat initially, and then rolled it out to customers as its own building block.
I understand AWS is generally a cost-effective way to build out services with unknown or bursty demand, but at your size doesn't it make more sense to operate your own data centers?
By relying on AWS for our back end, Twilio is focused on constantly iterating and improving our APIs and serving our customers. Infrastructure is not a differentiating part of our business and we'd rather not focus there. Sure you can save money, but it's a huge opportunity cost to have valuable engineers focus on table-stakes issues, like how to spin disks or power racks. I'd rather our resources focus on customers and their needs -- the things that differentiate our products.
Twilio is one of the first telecommunications companies to target developers instead of IT. That was pretty radical, as developers often don't have budgets or decision-making authority. Yet it appears to have been the right move. Why do you think this worked so well?
We want Twilio to be in every developer's tool belt so when a time comes when communications can be the answer to a problem they are trying to solve, they use Twilio. Historically, developers were not considered to have any buying power. So few businesses were building tools targeted directly at the developer audience; instead, they were going at those who they perceived as writing the checks -- the line-of-business owners and the C-suite. Well, this is changing.
Today, every company is becoming a technology company and software is what allows one company to differentiate from its competitors. In this transition, developers are becoming a lot more important because they build the experiments and the prototypes -- and those turn into production apps and scale globally. That concept is fueling the growth of AWS, of Twilio, of Stripe, etc.
Developers will continue to be Twilio's first priority, regardless of our size. At our heart, Twilio is a company built by developers, for developers.
I've been watching Twilio almost from the beginning, and I wasn't the only one confused in the early days. Twilio grew from a source of confusion to a source of inspiration and has attracted many competitors. What changed, and when?
I'm not sure there was one point, and I imagine there are still quite a few people who don't quite get what Twilio does. What is more understood today is the number of businesses creating really amazing customer experiences with Twilio. [Airbnb, Netflix, and Uber, for example, are among Twilio customers.] Apps built on Twilio have reached over a billion global devices, and reached over 95% of American adults. So now that people are having daily experiences with communications powered by Twilio, they can start to connect the dots.
What concerns you most as a competitive threat?
Our biggest competition is the legacy way of doing communications -- copper wires, stacks of boxes in the closet, drawn-out contracts and negotiations. Traditionally, when a company wanted to integrate communications into their user experience, they had to buy a pre-built solution then force fit that solution into the solution they really needed. This way of deploying solutions is expensive, time-consuming, and the opposite of Agile [development] -- solutions deployed this way take years to build and cost millions. And often, the problem changes between when you start this long process and when you finally finish it -- it's waterfall [methodology]. Smart companies realize that long time frames and expensive, up-front costs are the enemies of progress because they prevent experimentation.
But that's changing rapidly as companies look to provide customer experiences that differentiate. In fact, we're now seeing an almost Darwinian evolution in how companies communicate with their customers. Those who are adapting to meet customer expectations will survive. Those that can't adapt quickly, will not. It's our job to educate companies on how Twilio can help them be one of the companies in the former category.
Look at ING bank -- they just decided to discard 17 legacy call center solutions, from all the usual players, with one solution their developers are building using the Twilio APIs. And they're deploying it iteratively, one sprint at a time.
Twilio recently launched Programmable Wireless, which gives developers access to wireless services over T-Mobile's 3G/4G network in the U.S. But numerous wireless data solutions are already available. Why did you feel this Internet of Things-focused service was necessary?
The goal here is to enable developers to deliver on the promise of IoT and BYOD. Wi-Fi and other short-range connectivity has been a barrier to building IoT solutions. Giving developers access to programmatic wireless lets developers and enterprises create their own customized carrier solution with the ability to program every call, text, and data packet that interacts with a mobile device. This has the potential to open doors to use cases that we've really not even considered because of the lack of ubiquitous coverage.
We're also excited about what developers will build in the BYOD context with Twilio Programmable Wireless. Many companies and industries have special requirements for their communications, and now with Programmable Wireless, developers can program the core of a mobile network and build solutions to meet those requirements. Whether it's recording every call and text message and storing them for compliance, routing mobile data through company firewalls, or assigning hundreds of local phone numbers to one mobile device for a sales person -- these are all possible. It really boggles the mind when you think about what this opens up for developers.
I first learned the term "hackathon" from watching Twilio in the early days. I know there have been some spectacular success stories, but are hackathons really productive?
Hackathons are a means for developers to express themselves creatively -- and we fully support that creative 'doer' spirit. It's a misconception that developers are trying to start new businesses in a weekend; they're just trying to exercise the creative itch and, periodically, something truly interesting actually comes out of it -- like GroupMe came out of the TechCrunch Disrupt Hackathon. But that's not the goal, it's just an outlier.
How do you build a reputation around reliability when most of your services are delivered "over the top" and best effort?
It's a misnomer to say most of our services are over the top. Our PSTN products are interconnected with carriers of the world -- it's our 'super network' -- and due to the intelligence of our software and the global set of interconnects, it can actually outperform, for price and quality, more stagnant legacy networks.
We offer a 99.95% SLA on our APIs, and in the last 12 months have delivered over 99.999% as a matter of operational practice. And in the history of our company, we've never had a single scheduled maintenance. So reliability is what you deliver, and I'm proud of our operational excellence.
Also, the easiest way to achieve resiliency is by never making changes. That's how traditional networks work. At Twilio, we shipped production updates to our systems over 6,600 [times] in the past year. That's 25 times per business day on average. We ship a customer-facing new feature or product line every 4.5 business days. So we're achieving agility and resiliency -- that's something legacy companies don't do in communications.
In the cloud, trust is the biggest thing you're selling. And this is such a part of our DNA that I devoted a major part of the keynote at Signal (our developer conference) this year to the concept of agility with resiliency. In a world of software, agility with resiliency is what every company will strive to achieve. I think we've got a big advantage here.
Twilio has been offering video APIs since 2015. Why did you feel it was necessary to acquire Kurento?
Kurento's and Twilio's visions were very well aligned. Not only had the Kurento team built the wildly popular WebRTC media server, but their idea of how to build a developer platform was very well aligned with Twilio's vision and products. WebRTC, and media services generally, are comprised of two major architectural components: the client-side SDKs and the media processing abilities of the cloud. The Kurento team is leading the expansion of our WebRTC Media Cloud.
By bringing the Kurento team in Madrid on board, we are also opening our fifth office in Europe, and extending Twilio's footprint to another thriving developer community. ¡Bienvenido a Madrid!
Twilio wants to make sure the Kurento open source project is a stable foundation for media processing applications into the future. It will (of course) remain open source, with Naevatec (Kurento's parent company) and Universidad Rey Juan Carlos (one of its main contributors) continuing to maintaining the Kurento project.
For more of Dave's executive Q&As, see:
- 8x8 CEO Has a Tiger by the Tail
- Cisco's Rowan Trollope Makes 'Spark' Fly
- Real-Time with Avaya CEO Kevin Kennedy
Dave Michels is a contributing editor and analyst at TalkingPointz.