Twilio: The Inside Story with Jeff Lawson, CEO/Co-Founder

Recorded July 10, 2017, this is a conversation between Jason M. Lemkin and Jeff Lawson (Twilio CEO) about Twilio's developer-first strategy, how developers act as an entry vector into larger enterprises, the evolving role of sales and enterprise plans, product expansion (voice, SMS, chat, video, wireless), and engineering practices to achieve "agility with resiliency" (18,000 annual production deployments; OMM/Ironman).
Chapters
Let's give it up for Jeff Lawson. Very exciting. Thanks for coming.
Thank you, Jason.
Yeah, this is great.
Thank you, everybody.
So I learned a little lesson yesterday. Let me make sure show of hands for people that do not have not heard of Twilio. Are there any here? Zero. So I don't have to ask Jeff to explain. You want to give 30 seconds for the two people on the top row?
Yeah, I saw one. Absolutely. All right. Tilio is a cloud communications platform that allows software developers to embed communications into the apps that they're building. So if you want text messaging, voice calls, video calls, authentication, even now, wireless capabilities inside of apps. Twilio is an easy set of APIs that developers use to embed communications into their apps. And so you use it all the time. You don't even know it. If you take an Uber and you call the driver from inside the app, you're actually using Twilio to make that call.
Yeah. So good. So for you up there, that's the answer of Twilio. We'll learn more over the next little bit of time. Before we do, I want to share one tiny, tiny, tiny story. So I'm a founder. I founded two companies selling the enterprise, and somehow we stumbled into this putting on some small events. And you learn a lot about putting on events. And what happens a lot of times is some speakers can't make it. It does happen. Sometimes you get, like, a random text. Sometimes you get someone's ea. Last year, we had a unicorn CEO whose EA said, unfortunately, a speaker was sick, but it was three months before the event, so she must have been prescient. Or prescient, I will say. Last year, Jeff was gonna speak, and I got a message that he wouldn't be able to. And this was right around the press was saying Twilio might IPO. And I'm 95% certain the reason was this quiet period when you. When you have to go quiet to file an ipo. But he's the only CEO that ever called, and he said, I feel so bad. I will find you a better speaker than me by tomorrow. I've never heard that. So I think that's the kind of CEO that we all want to work for. Yeah, a little bit of it's pretty cool.
I had nothing. I was like, I hope he doesn't take me up on that. No, but it was.
But no idea. I believe you would have made it happen fortunately. Yeah, fortunately.
Pretty sure Aaron Levy will do it.
What's that? Yeah, we had him. He's the ringer yeah, he's the ringer. We've had him both years. So fortunately Jay from Atlassian right before the IPO had said he'd love to speak. So we had an extra slot. But that was the first time I've heard it. So that's a pretty special thing.
I felt really bad because you plan way ahead way.
Yeah, I kind of really good at that.
And I was like fighting with our lawyers about.
Come on.
I knew.
I knew. When I got a message that said nothing. I knew exactly this. Go to lawyers and some folks. The first year we did it, Aaron Levy came one week after the IPO in the middle of. I didn't think they'd let him come.
Yeah, that's kg.
I think he just told him that he was. That would be my bet. So first congrats on the quarter.
Thank you.
So it's pretty cool. How long have we been public?
This was our third quarter reporting.
Third quarter reporting. Okay, one last quick question then I want to get into the. What's better, a crunchy or coming to the Saster annual. What would you say is a better award?
Well, they gave me a trophy.
They gave you a trophy?
You know, I got a sock from you.
You got socks and Taco Bell.
Yeah, and Taco Bell backstage.
It's true.
Although I don't think Taco Bell was open at this hour. So I'm kind of curious.
I'm not sure how it happened. So I want to talk about a couple things we talked about before. But let's kind of one high level thing. I wonder. Maybe you can. So Twilio's clearly the flagship of next generation developer centric companies, right? First one to go IPO of this generation. I know your marketing materials. Evren we talk about how the whole world's more developer centric. But as someone who has built and shipped software but doesn't really code at this point, I'm still kind of shocked. The markets are so big. So Voice is huge, right? Voice is one of the largest markets out there, which is part of. Part of Twilio's secret sauce of growing so quickly. But why for real, why is the developer market bigger today?
Well, I don't think. You know, or maybe I don't think of developers as the market per se. I think of developers as the strategy to get into the market for whatever you're doing.
The entry point.
The entry point. Right. It's a different entry point than you're used to. And at the end of the day, Twilio still sells communications aws still sells servers, but the way we're selling it is different than how it was done in yesteryear. Because yesteryear, if you had a communications product, you would go into a relatively top down IT type sale. You'd have an enterprise salesforce, a song and dance and maybe some steak. And that's how you got a deal done. Whereas with the developer first approach, what you're really doing is putting a new tool in the toolkit of the world's developers. And so that when one day they're at work and they realize there's some problem that needs solving, whether it's communicating better with customers or adding two factor authentication to their app or whatever it is, and they encounter a problem, they're now able to say, aha, I know how to do that. It's Twilio. And they pull out Twilio and they can usually build a prototype in an afternoon. And that's faster, way faster than you can often get an enterprise sales rep on the phone.
Way faster.
Right. And so you actually ship the product before you could even start that enterprise sales process in the sort of traditional sense. And so I think that developers aren't a market as much as they are a vector to get into customers. That is just a much more efficient model than relying on what inside at Twilio we like to call the hero sale. The salesperson is going to come in with the great presentation and the amazing, you know, skills to work the room and therefore get the sale. Right. This is just a very different model.
So today you last recorder, I think it was 75 million in GAAP revenue, Something like that. Is that right? I should remember something like that. So let's call that $300 million run rate. Whatever it is, it's probably higher than that right after the math. So today at 300 versus day, how much of your customers is the insertion point still the developer is day one, is it all of it is that. Are you seeing more CIO level pull or what's changed there over time as you've gotten to scale?
You know, it's interesting, right? As we are working with bigger customers, you know, traditional enterprises, et cetera, you do find that you've got more levels of the organization who are interested in care and are working on the, you know, interested in that sale. Right.
Or stakeholders.
But what we're still finding, and this is fantastic, is that developers are the ones leading us into those scenarios. Yeah, Developers are the ones who bring you in first, build that prototype, then it starts to snowball within the company. The Momentum, because people see this thing and they say, oh, we wanna ship that. Hey, what's preventing us from shipping it? Well, it's security or it's it or it's procurement or whatever. Great, so let's bring those people together. And that's where our salesforce comes in, works the process through. And ultimately we're just trying to get something that typically the developer started through to production, through to production, through to production. Right. And so you know, if it's a startup adopting Twilio, like the developer doesn't ship, they're done. Right. You don't need sales. But if it's a complex enterprise, great. That's where we shepherd. Oftentimes we're actually kind of teaching the developer almost how to get through their own organization. But it's still led by the developer. And so you have this really nice tailwind as you're going through the process because again, it's not a hero sale. You're not like, hey, let's just do an RFP with five of our competitors. It's a, hey, the thing's already built. The executives may have even touched it and said, oh this is awesome, let's get it shipped.
Right.
And now we're just trying to check the boxes that need to be checked in order to get something out the door.
Got it. So that's. So Even today at 300 million plus run rate, you don't need to do top down sales at all. Everything is most, even your most non techy customers, they're still getting pulled in by developers.
Yeah, it's usually more of that.
Bottom, you've got this brand now, right. So how does the brand change things? Right. In the early days you were having to convince people they could trust Twilio. I assume that's mostly faded away even with these multiple stakeholders.
Well, you know, it's interesting, right? We've got that billboard on the 101, it says Ask your developer. And like people often ask me, why would you like why do billboard advertising anymore?
It's a good question too. Yeah.
And you know, I think what it does is it provides air cover. So let's say a developer builds a thing and they're in some meeting where they're saying, oh, how did you build this? And they say, Twilio, if you have name recognition, even though maybe I'm not thinking about those people as literally the first customers, most important that we hit, I want them to say as you did in here, oh yeah, I've heard.
Of Twilio, I've heard of It.
Right. They're trusted. Aren't they the ones that power Uber? Aren't they the ones who power IMG's, call centers? Aren't they? Yeah, I heard about that.
Right. Yeah.
You want that name recognition? Because I have to believe that just that kind of greases the process now eventually. I think that CIOs and CEOs should care about communications as a strategic part of how they're going to deliver on a great customer experience, which is ultimately the only way they're going to survive.
Yes.
And that's. I don't care if you're a software business or you're a bank or a automaker, whatever. It is, like, customer experience is going to be king. And communications is almost always a major part of that customer experience. And so in the long term. Yeah. I would love the C level suite to say, yeah, you know, we use Twilio because communications, how we communicate with our customers is actually really important.
Yeah.
But it takes time to build that kind of awareness. Absolutely. But right now I'd say it's about that air cover.
Yeah. I think we missed how important that air cover second and third touch are. We want to have heard of something we haven't heard of. And that has a profound effect with.
I always thought about it as. You know that NetSuite billboard, it's been.
There for a decade, right? Yeah.
I didn't know what the hell netsuite was. And I was in some board meeting like four or five years ago, and it was like when we were still on like, QuickBooks or something, like whatever system I had set up. Right. And it was like, okay, like, we need to get off that to our next thing. And, you know, somebody, I think it was our CFO said, great. It's either, you know, I think intact at the Time or NetSuite. And I immediately was like, oh, yeah, clearly NetSuite. Right. Because they have a billboard.
We laugh. But it does matter.
It works.
It doesn't get like.
I didn't question that decision at all. I'm like, oh, I've seen that billboard a lot. They seem to have a lot of good logos on it as customers. Like, yeah, that just makes it so that when someone recommended NetSuite, it's like, yeah, it makes sense. Like, I'm not gonna really challenge that or like, want to dig in and just sort of like, yeah, sounds good.
Yeah, that. I think we mock a lot of this stuff, like billboards earliest founders, because we're like, there's no way we're gonna get leads it's not about leads. Right. It's about reinforcing the brand and supporting that. And then I've heard of it. You do it just right. It can even work at like a millionaire revenue. I think you've heard of it. Yeah, it can even work. So related to that, let's talk a little bit. So for folks here, as the insertion point, still all developers, which is super cool, but as you have the stakeholders, how does that drive changes in the product? We talked a little bit about SLAs and other things like that. How is two factories, maybe we get three factor. But how has it changed? How has going more up market changed the product?
Yeah, well, I mean every product. Yeah, every company starts with, you know, you trying to figure out the utility you provide to your customer, which usually it's not about say security and compliance and things like that because you know, those things can block you from delivering utility from a customer. But you need to first figure out what utility you're providing. And if you succeed in doing that, then you start reaching these customers that are, you know, bigger, more sophisticated. They know what questions to ask. They have a lot of compliance and processes.
Did you go through a phase where you failed like every security audit? Because a few of us have.
One of my co founders was a security guy. Yeah, we always had a good stance, but we didn't have good answers to the checkboxes. Like he would be like, wait, we're way more like, these are the stupidest questions. We're way more stupid.
That's what you hear from the guys that are too smart that they're stupid questions sometimes.
Well, it's because it's the checkbox questions, not the actual security questions. But we made it through that stage so we could actually say, yes, we are going to check the boxes in addition to actually being secure.
They are related, but two separate things.
Yeah. And of course it's a never ending journey to security. No one ever just says they're secure. But so you have to go through this process where you start seeing these customers and the first one you get, you kind of be like, oh, silly customer with your processes. And then as you go on, you get more and more and more of them. You're like, yeah, we should probably, if we want to get this segment of customers, we should probably be investing in this roadmap. And so I think most companies that are successful do go through that transition where you end up investing in quite a bit of those things. And as somebody who, as entrepreneurs who are looking to make more revenue and figure out how to differentiate your customers and price points. This is an obvious. A lot of people have done this. It's obviously a great way to differentiate your pricing. So for Twilio, for example, we have got our enterprise plan. It adds things like single sign on and client certificate validation and a bunch of other security and compliance related things that clearly enterprises with a lot of checkboxes because of their compliance requirements need to check. So great. It's a value added product. We monetize it separately. It's a monthly recurring revenue product and actually one that our enterprise sales reps are regularly bringing in because it is a great way to sort of go in the door. If you're not willing to sign up for this monthly recurring package, then you're probably not a very qualified opportunity.
Right.
Because with our usage based model, the prices at Twilio start at a penny.
Yeah.
And you can sign up on our website and get going and just pay us as you go. And that's fantastic. But it's hard to put an enterprise sales rep's time towards a deal if literally our SKU costs a penny.
Right.
And so for us it was a great way to distinguish between the types of customers that we have and also which customers need an enterprise rep because they have that kind of requirement set and those who merit our investment in an enterprise rep. So it's a good, it's kind of a win all around. They get what they need, we get what we need and we grow our business by delivering them the things that they need.
And do you find sometimes that can be a slightly challenging cultural change? Especially if you come, if you start up early, you're super cool hacker culture, you're doing cool stuff and then all of a sudden you've got to go more enterprise. Some of that stuff does not always seem fun to everybody.
This surprised me.
Right.
So I'm a developer by my background. How many folks in here are like sales by background?
Probably 25%.
That's a good number of people. Awesome. So I'm a developer by background and so the thing that I'm always thinking about, how many of you are developers? Right. That's probably like even split almost. You know, developers, we often think about culture. Right. Is really important about giving us freedom and do the creative energy which is developing and focus and concentration and big screens and all the things that we always think about as culture for a great engineering organization. And I never really thought as much about the notion of the sales culture of an organization just because I'm not a salesperson by my background and I, I thought that the cultural shift that happened was not so much a struggle for the developers, it was actually a really interesting struggle for the salespeople, especially the early ones that we brought into the organization because they were the ones who in many ways were asking, hey, we want you to conform to this very engineering centric.
So sales was driving a lot of that change.
Yeah, well it's not they were driving. It is that we had to figure out how to build a great sales culture alongside a great engineering culture.
Got it. Without. Without engineering viewing sales as some sort of tax. Yeah.
I mean imagine if you're the first engineer inside of an all sales organization, you'll feel a bit out of place.
It is hard. Yeah.
And, but we just did it the other way which is that we added a very engineering driven organization and then we introduced sales into it and like they were the fish out of water. And I felt that I had to go overboard as the CEO to let them know that I support them, that sales is important to our company. Even though we do talk about the power of that self service developer led model, we do believe that sales is a critical part of our growth and a critical part of our long term success. And so we have to be great at both engineering and engineering culture and sales and sales culture and have mutual respect between the two. And I think that's really hard to pull off. And I don't know, a lot of companies, I think about a lot of Google you typically hear stories about, oh it's all engineering led. In Salesforce you typically hear the story, oh, it's all sales led. And every company has this story about which culture is dominant. And I think it's really hard to pull off. But I think it's my goal that if you're a salesperson you should have an amazing sales culture and sales team to work with. And if you're an engineer, you should have an amazing engineering culture and amazing engineering team to work with.
Now did you try and make the transition a little teal like with no quotas or best efforts or, or did you move quickly to a traditional sales model when you added these folks?
Well, you know, I think our path to a sales model has been like nonlinear because our model is quite different. It is when you can sign up on the website and you publish all your pricing, you end up with a little bit different model than if the price list isn't published. If our SKU literally starts at a penny with no minimums and pay as you go. Yeah, it's hard to say what sales should do. Should do. And it's hard to measure what sales is doing because you chronically asked this question, would we have made that sale anyway?
Especially on people that buy more. They buy more minutes, they buy more usage. Right?
Sure.
And the usage, how much does the sales rep get credit for that?
And the usage is. We have multiple vectors of growth inside of an account, but one of the most dominant ones is just the customer built a thing and they roll it out. As they roll it out and more and more of their end users account use it, we're gonna. With a usage based revenue model, we're gonna make more money on that account. And so the question is like, do we have a sales rep who is causing Airbnb to rent more apartments? That's driving more communications? Like, no, clearly we're irrelevant to that. They bought a Super bowl ad. That's what we like. Right. A sales rep didn't cause that to happen. And so we're always questioning. And that took multiple iterations. I feel really good about where we're at right now, but it took multiple iterations to figure out how do we separate the organic growth that happens with or without what we do from the inorganic growth that is what we're investing in with a sales model.
It is hard and it's really hard.
And we went through a lot of iterations about how to figure out how to do that.
Yeah. So let's talk about a couple.
And by the way. And it's never good when a salesperson is like, I made the sale. I'm really awesome. And then management's like, yeah, are you constantly questioning the value? So that was one of the challenges we had to get over in building the sales culture and also define the sale moment. When every account at Twilio starts at a penny, literally every account spent their first penny at some point. And it's just a continuous stream from 1 penny to 2 to 10 to 100 to 1000 to 100,000, whatever. At what point did the sale occur?
Yeah. I don't know. I drew the line at 99 bucks a month. That's what I allowed it.
But most companies, you're not a customer and then you are a customer.
Yeah.
And it's a step fund here.
You just became a customer.
Yeah.
Right.
And for us, it's like, it's just a linear. I wonder where along the way you became the customer such that the salesperson can declare victory. And it took a while for me as an engineer to figure out the sales game It's a game, and you want to know when you're winning the game.
You do.
And in our model, it was kind of hard to tell you if you were winning or not. And that was a really interesting challenge that I think we had to figure out along the way.
So to me, winning those models, it's about whether the rep can inflect the curve, because if you'd achieve the same amount of revenue without a rep, then you can do it all with happiness, officers.
Right. And it's interesting because I've made a blind faith, you know, I have for many years made a blind faith investment in sales. Because what I did is I look back at, like, every major customer that, you know, I could look at, like, I top, like, 50 list or whatever, and I go through the list, and I, like, a substantial number of them I looked at, and I was like, wow. When we were really small and even before we had a sales team or much of a sales team, I had gone in, and almost every one of these accounts had, like, sold. And that's how these accounts got started.
You'd sold.
I did the CEO.
You went there, you sold.
So at the same time, I would be like, I don't know if we need sales.
Yeah, but you were doing sales in.
The very early days. I was doing sales. When I realized that, I was like, well, wait a minute.
So the top 50, I'm doing that. How many of them had you met in person?
Do you know a lot of those?
A lot. So that's sales.
Cause I was being a founder and hustling and meeting customers and, like, shaking hands and learning about their business and saying, hey, what if you did this or that? Hey, we can help you with that. Right? And then I go back to the office and be like, I don't know if we need a sales model. Right. Then I had this realization one day. I'm like, wait a minute.
That's what I'm doing.
Every major account that we have, it feels like I'm touching. I'm actively. I'm giving them love and all that. I'm like, yeah, that sales. Okay, screw this.
Yeah. That's a critical insight some of us missed. Right?
And I think a lot of. Especially the engineers out there, we like to think that our products are so good that they don't need to be sold.
Yeah, that's a tragedy. When I hear that. It is true on occasion, but it is true very rarely. What's that? Very rarely. It's hard to get to 300 million with the product selling itself.
But even, I mean, some products get started on their own. But again, if you really want to go deep in the customer, make a long term relationship, continue to go deeper and sell more and more things and be more meaningful to their business, like that's going to be a relationship.
Yeah. And worst case, if you go visit them, you're going to make more money from them one way or the other. Absolutely right. The churn's going to be lower. I mean, they're going to have to call Jeff before they leave the platform. No one wants to do that. That. Can we talk? Let's talk a little bit about sort of agility as a high level topic because it's something I as I've worked with more founders, I've learned I'm in love with founders and companies that are more agile than I was as a founder or CEO. And so two things around Twilio, one we chatted about backstage, which is multiple product lines and I was barely ever able to do one product line. In my second startup, my first one, I was able to do more. But with Twilio, you launched with Voice first and then sms.
Yep.
And you launch, it's a hack in the beginning and with 18 months you've got another product line. Is that the history in the early days?
We launched voice in 2008, very end of 2008.
Yeah.
And the number one thing we were hearing from customers was, hey, we've got these phone numbers. We're buying from you through these voice calls. You know what would be really cool is if we could send and receive text messages with those phone numbers too. And we said, yeah, that makes a lot of sense and I bet there'd be some cool stuff you could do. And so about 18 months later we launched Twilio SMS which was, I don't think we exactly realized it at the time, but it was a completely different market, completely different set of use cases. Yeah, really, I mean a very different product line. But for us we were A, just following our customers needs and B, we've never really wanted to be a single product company. And I know there's this advice that entrepreneurs often get about find a niche, get rich. Focus, focus, focus, focus, focus, focus. You know, there's a lot of ways to phrase this bad advice. And for me it's always been about, you know, every time you ship a product it's like it's a bet. It's a bet that the customers need the thing that you're building and you know, you didn't get it right. The first time. But that with iteration, ultimately you will find something there. Right. You're digging holes, trying to find oil, whatever. Pick your metaphor. Bezos had a great one in their shareholder letter last year.
What was it?
It was like more at bats.
More at bats.
And he says every at bat is a chance to score.
He does have a significant amount of scale, though.
He does have scale. Right. He's like, your goal is to just get more runners on the basis because every one of those, every time you get a runner on the base, that's an opportunity to score a home run. But then he has this great, like, zinger at the end of it. He says, but unlike baseball, where the best outcome you can have if someone hits a home run is four runs.
Yeah.
In the world of business, your outcomes are unconstrained. A grand slam in business can be 100 million home runs. There's no limit to how much you can. No ceiling to what you can achieve if you get a home run. And so I just believe that. I think that it's a probabilities game with all sorts of things. Whether it's starting your company or whether it's your product itself, there's a probability to it. And I'm also a really big believer in the power of a small team to build and operate a product.
Yeah.
So you don't need 100 engineers to build a product. You need five engineers who work really well together and who know the problem domain, know the customer, can prioritize well, and can ship and operate code. That's the unit of progress in any company.
That small team, a group of five.
And so for us, it was all about saying, we're not content with just having one bet out there. Let's have more bets out there, and then let's continue to invest in them when they work.
But they're all discrete teams.
Discrete team.
Engineering team.
Yeah. Now, as the products get bigger, like our voice product now is a much bigger product than it was back then, you end up breaking the problem down into many smaller problems. And so our voice team isn't one team anymore. It's many teams that each own parts of that problem. But they have clarity about what they own, what customer they're serving, what success looks like, even as you break down. And as an API company, it actually becomes pretty easy to break down problems because you've got different kind of parts of the API that interop nicely together. And so I've just always believed in this notion of it's not about finding a niche or focusing on only One thing, because you're very single threaded on that one thing working. And yeah, you're gonna be very determined to get it to work. But you know what? Not every place where you dig a hole you're gonna find oil.
So the five's the rule. Put five folks on a project, five to 10, five to 10. And then it was interesting yesterday we had Michael Pryor from Trello who was at Fog Creek before and Trello began to consume all the resources of Fog Creek. Fog Creek was small. I mean I was an old customer, 50 people and all of a sudden 20 people at Fog Creek are building Trello and then they have to spin it out. So when do you shoot it? If you put five or 10? Because then it's gonna. Then it is more, right? It is. How many employees at Toyota today?
Today about 730.
I mean it's big but it's not huge. Right. So when do you decide? SMS was probably obvious, right? Because it probably took off so quickly, but maybe it didn't.
It took off pretty quickly.
Right. Are there other that you killed with like machines, are there initiatives you killed with those small teams?
Well, you know, it's interesting, yes and no. We've killed the teams but maintained the products so we find another home internally for the product to live. We have never killed an API that.
We'Ve ever built, thank God. I hate that.
Yeah, no, it's one of the key tenets of our company. We've got, you know, our still main API, the version on it is 2010.
You got to maintain it, don't you?
And we just keep adding to the same APIs, we don't make backwards incompatible changes because that's really critical to building our trust with developers. But yeah, I mean you change your staffing, your resourcing, you try to put your investments where the best opportunity for success is and then you manage a portfolio of investing in your core business to keep growing and scaling the key drivers of the business, but also making new bets. And that's kind of how we think about it every year. So at any point in time we've got investments that are kind of your shorter term incremental roadmap for your main revenue drivers, then your medium term. Clearly we have customer demand and we have to build it and we have to get it out there in the right way. But this thing, and then you've got your long term, long shot bets that you really have no idea if they're going to work out or not. And for us it's been about managing that Portfolio. Even since we were quite small, we would start new initiatives with one person and just say, hey, let's try to ship a thing, see the best you can do. And let's just explore this new area. And when the whole engineering team was so small that the only way you could make an investment was one person or part of a person's time. Right. It's still something that I think you have to do.
Yeah, no, I love that. And then one related topic I want to make sure we can dig into. I'm not an expert, but I've learned a little bit from the sidelines. Voice is a challenging area. Right, right. It's mission critical. And in some ways achieving end user expectations is impossible. I'm guessing with SMS you have a bunch of. You can disguise any issues on service level. I mean, people don't. I mean the SMS is if it's a minute, if it's 60 seconds late, does it matter? I mean, it sort of matters.
Well, every product has its own.
But voice is hard, right?
Voice is really hard.
How do you remain agile and try and have quarterly, monthly, daily hourly releases and not break a mission critical application?
Yeah, that's a really good question.
I've never figured that answer out to that question.
That's one that we've worked, we've spent a lot of time figuring this out and I'm really proud of where we are today. We have given a name to this, it's called agility with resiliency. And the way we've sold it internally, and I've actually started talking about this externally as well, is that the goal of a high performing engineering organization is to remain agile but deliver resiliency at the same time. And a lot of companies mistakenly believe that there's a false dichotomy between those two. They believe that we can be agile, but we're going to give on quality. Zuckerbergs move fast and break things.
Yeah, we don't even need a QA team. We'll just roll back.
Or the opposite, which is, hey, we're going to ship quarterly and be really methodical about things and make sure we get it right and ship quarterly. But at Twilio we have, we ship. We're now annualized 18,000 production deployments a year. It's about 100 a day. Production deployments.
Got it.
Production deployments a day. And it used to be a few years ago that when you plotted our production deployments against our incidents, they followed each other the graphs. And so we had this very conscious moment a few Years ago we said we either need to slow down our deployments, but we know that's not best engineering practice, or we need to figure out the root cause here. And we went about figuring out the root cause, solved a lot of problems about how to build resiliency. Now we can ship 18,000 times a year and we have a 5 nines available API and a 7 nines success rate of the request that we're serving. And so we're really proud of what we've accomplished. That and how we've done it is, I would say, two things. Number one, the small teams approach is really important because the small teams build the software and they operate it so there's no throwing it over the wall to ops, that kind of thing.
They're responsible for it.
Yeah, they're responsible for it. They run the services internally and externally. But the other key thing here is we've trained people. You can't expect everyone to just know how to build resilient things. And so we've trained people and coupled that with platform services that they get to consume internally and made a big investment in our internal platforming so that teams who are building product can ship fast and have a really good safety net that's built by other teams over here who are building services as well. And then we train everybody. We have a program we call omm, the Operational Maturity Model. Internally, it's codenamed Ironman and it's six vectors. It's things like testing, monitoring and alerting security architecture. And what we've done is we've documented best practices, we train the teams and then we test them and then we.
Retest them against this, against the OMM model.
And what we've done is we've found is that every engineer wants to do a good job of this.
Yep.
But she doesn't always know how to do it. And so what we do is we do a training model where we figure out like, okay, here's how we do it here, here's what we figured out as best practices. And we've actually started externalizing this. We've started talking about omm. We talked about it at our conference last year and we started actually going into our customers because they're really curious, how do you do this? We want to try to achieve this. And we've started actually sharing a lot of our wisdom with our customers as well. And the interesting model is also with our product lines. So the product development life cycle starts with a new product, comes out, it's an internal alpha, then it's A developer preview, then it's a beta and then it's a ga. And it used to be several years ago that a product got called GA because customers wouldn't adopt it if it was called a beta.
Yeah, right.
It was like we called it a beta, we put it out there and then we would hear feedback from customers. We don't want to adopt something, it's a beta. When's it going to be ga? And we'd be like, it's GA now. Hey. And we were never quite comfortable with that. And so what we figured out is what GA should be a six of is from Tulio to you, our customer, is that we stand by this as a operationally excellent product. And in the early days of a product, by the way, you shouldn't hurry to make it operationally excellent because you're still trying to figure out your product market fit. Did we build the right thing? Let's not harden it if we didn't build the right thing. But once you figure out that you've built the right thing, customers want it now. Your job is to harden it. And we've defined what that means. It's this OMM Ironman model. We've once you can check all the boxes, prove you have checked them to the engineering leadership of Twilio. That's when you get to call your thing ga. And that's how we've achieved this resiliency, by putting the tight iteration loops where they need to be, then having a model where we train and check and then call it ga. So that our customers can expect operational excellence from products that have gone through that whole process. And then communicate what you do internally with your customers so they're with you.
Right.
If you're a beta, here's what that means.
That's cool. Yeah. All right, we gotta convince someone on your team to write a guest post on sastr on omm, because I need to learn for everybody.
Yeah, we'd love to do it.
It's a good one. So we're over time, but one last question. What are you most excited about for this year for Twilio? What are you looking forward to? What's exciting?
There is so much. We've got a lot of new product lines in the market. Programmable chat, programmable video program, programmable wireless. So we've got a lot of really cool things coming down the line. And then in particular, I'm excited to hear what other communications problems we can be solving for customers. In fact, actually, I'll tell you the thing I'm most Excited about. Last year was a really crazy year. We had ipo, of course we had a follow on offering. So I spent a lot of time with bankers and lawyers and road shows and all this kind of stuff. And when I look back at the previous year, I realized actually I feel like that was all very time consuming. So this year I'm returning to spending a lot of time with customers. And so I set the internal goal. I'm gonna meet with at least three customers a week.
I love it.
And face to face meetings with customers and I ask the sales teams help. Hey, I want you to bring me in. I wanna meet customers. When I get on a plane, it's gonna be to meet customers, not to meet investors or to do PR or speaking gigs. I was able to walk over here. That's why this BE is gonna cool.
I appreciate it.
But, you know, really focus on customers this year because, you know, the process of going public and all that does distract and be distracting. And so I made a very conscious effort, but also set the tone for the company. We're very customer centric organization. We strive to be. One of our core values is wearing the customer shoes. And so, you know, again, I like to make sure that I'm wearing customer shoes as much as anyone in Tulio. All right, guys, Excited to do that.
If Jeff can do three a week, I think you each can do at least two, don't you think?
Absolutely.
Pretty cool. All right, everyone, give it up for Jeff Lawson. This was amazing.
Thank you. Super cool.
Thanks for doing this. It was great.
Absolutely.










