A Deeper Dive on How to Collaborate, Manage, and Work with Developers with Twilio's CEO Jeff Lawson

So I wanna kind of do a follow-up on this, "Ask Your Developer." We're gonna learn from Jeff. I wanna ask him a few more questions on how to work with a great developer, but I also wanna talk about how it's going, what he's learned from this book. And then we'll do live, 5 interesting learnings from Twilio, which has always been one of my favorite cloud and SaaS companies, but also has been one of the great beneficiaries of this incredible, incredible growth in cloud. Um, and we had Byron Dieter earlier. Obviously Byron and Jeff go way back, and when he did State of the Cloud, he's got 100 free copies of Ask the Developer out there on social media. We will do another 50. Just tweet out whenever you want, hashtag #AskYourDeveloper, and put SaaStr in any tweet, um, and we will track you down aggressively and we will get you a copy of Ask Your Developer. Um, and again, I wrote this before and we chatted on the bottom right, there's another session and we'll sort of tie them together. But I found that this was one of the most impactful— I don't know if it's a business book, but I guess we'll call it a business book— I've read in a long time because it is the insider's playbook to working with a CTO, a VP Eng, a top developer if you haven't done it before, even if you have. But if I recommended it for no one else, to business leaders, to business folks, to folks that haven't, or even if you have, even if you wrote the V1 yourself, if you haven't operated at scale, this is, this really is the The Playbook. And just one sec, let me get this. And so, Jeff, I want to ask you a couple questions on it. But at a meta level, you've put a lot of effort into this book, haven't you?

Yeah.

A lot. I've noticed you on social media and a few events. I mean, this is a major undertaking for you, right? So how long did it take? And why did you do it? Is it worth it?

Absolutely. You know, I will say, I've had the conversation so many times through the years, especially with business leaders. Hey, how do I hire great developers? How do I get the most out of them? How do I know if they're any good? All these sorts of questions, or companies, that goes for startups as well as big Fortune 500 companies who are undertaking these big digital transformations, and they really are asking, where do I get started? How do I know if it's working? And a lot of those questions. I've walked through my thoughts on those topics so many times. I was like, you know, I've got this really interesting point of view. I am both a developer and I'm an executive running a public company. And so I've got one foot in both worlds. And if you think about it, both of those functions, like developers, your technical teams, and your business people really don't speak the same language. And you get the, like the sense from the technical people, right? You've got the Dilbert pointy hair boss, you know, characterization of the, you know, the business people, the MBAs don't get it, right? And then you've got the tech, the business people who are like, "Oh, those developers are kind of prima donnas. They're always avoiding questions. They won't tell me when the product will ship, or they can't tell me what features it will have when it does ship. What is this BS?" And so you get the sense that they're both speaking very different languages, despite the fact that they have exactly the same goals. Like both executives and developers, technical folks, what do they want to do? They want to build great digital products and experiences that millions, maybe billions of people are going to use. And that make the company money. So despite the fact that they have the exact same objectives, they just have very different ways of going about doing their jobs. And so I wanted to write the book as a bridge to help explain the developers and technical world to the business folks so that they can be more effective at engaging their technical talent in building the company that they want to be. And I had the hypothesis that like if I do a good job of this, if the book resonates, then I can help more companies succeed in the digital economy I can help more developers to have more impact in the work they do and in their careers because they understand the business side better and they're better able to collaborate with the business side. Those would be two great outcomes if they end up being true.

A related point, when Byron was doing State of the Cloud earlier, everyone's talking about product-led growth these days, like it's something magical new. Viral products aren't new, but he put out Twilio as an example of product-led growth, and maybe it is, I'm not sure, but certainly in many use cases, I don't even know I'm using Twilio. Right? I mean, it's as an API. So is it, as a CEO, as a leader, is it more important to put a face to your product when I don't get to see a little Twilio, powered by Twilio, on the app? Because I feel like it makes Twilio even more differentiated when I have a connection with the CEO.

Well, I think that, you know, I've often thought that my role as both a developer and as a CEO is an interesting one because for developers out there, you know, I can essentially speak to like, how do you build a business as a technical founder? And then as an executive who really understands code and technology, I can really speak to other executives about how the digital economy is playing out and how the role of software is impacting their industry and their business. And so being able to speak both languages, I think I'm in somewhat of a unique position to be able to do that. And so that's why, you know, I've thought about writing a book and being more out there, because I think I have something to offer to like kind of every part of our customer's business, the executives, the technology people, all the people who are trying to affect those digital transformations.

And have you heard anecdotally that customers are reading the book?

Well, we're a Wall Street Journal bestseller. So that's one thing.

I guess I should have known that. I was such an early reader. I didn't keep track of that. It's just, I wonder if it helps, how it helps. It's just so interesting that the book spoke to me, right? And it felt like the target audience was founders, right? Folks doing this for the first time. But I was just, you know, at Saastr, I'm just curious if you know how it influences those customers, right? Those big customers. I suspect they are reading them, right? And I suspect it helps differentiate Twilio at some level, right? As a trusted vendor, as someone that speaks my language. Maybe you aren't hearing it, but I'd be curious. I know you jump on customer calls. If you've been hearing that folks have read the book.

Yeah, you know, I have had those conversations with customers, you know, with executives and with developers, even though I wrote the book primarily for the business-minded folks to help them understand the developers more. But I think developers are finding a lot of value in it too, 'cause they're saying, hey, look, if I can actually bring the business people along on the journey and like help them to understand how they can, we can succeed together, that's another way that people are using it. But yeah, I've been talking with a lot of companies. Anecdotally, what did I hear? I heard that the book is making the rounds in the executive team at SAP. I think I saw that in a tweet. So, you know, it's like, there's anecdotal aspects and then the direct conversations I'm having with folks. I was chatting with a Fortune 50 CEO just yesterday. And it was interesting because I didn't realize that this particular CEO had been a developer in a prior life. And so, you know, we were talking about the book. He hadn't read it yet. I was telling him about it. But, and it was interesting because I don't think anyone would have expected that this company was led by a former developer. I won't name who it is.

Yeah, I just love this idea. I don't know, have you been on Clubhouse much yet, or you may be a little too busy running, running A Cloud Leader?

I've hopped on Clubhouse a handful of times.

What I love is that, and obviously they're selling themselves, but I love how the founders do office hours every week, right? Even now that it's at scale, right? And in a sense, a book is a way to connect with customers at scale, right? But I think we'll hit on a slide how many customers does Twilio have? I should be able to do the math in my head.

220,000 now.

220,000. So you have to find ways to connect with them at scale, right? Otherwise you don't connect, right? Any other? So a book is an interesting one. Any other? Things you think move the needle for connecting at scale?

[Speaker:JASON M. LEMKIN] Well, I think there's a lot in terms of social media that you can do. I think there's a lot just like, you know, your marketing does end up being the way of connecting. And the question is, how do you make your marketing personable? Like, how do you actually make it a personal connection, not just a, you know, the veneer of marketing? And I think that as a developer-focused company, we do a lot of that. It's not always me, other folks on our team, our whole developer relations team, our marketing strives to be like very personable and connected. That's why we do a lot of like, you know, live coding on Twitch, where people are very— it's very interactive, right? I love showing up on our developer channels and things like that too, and interacting with our developer community. But, you know, you're right, connecting at scale gets harder and harder. But interestingly enough, a lot of the digital engagement that we're all now doing because of the pandemic also provide more opportunities for personal connection. If you think about how we're all in our own individual box on these screens, it actually allows us to connect and ask questions. And I'm looking forward to questions from this audience later. And like, that's a great example of having that personal connection. Whereas if you were on a giant stage, you probably wouldn't have that.

Yeah, they have their— it is an interesting contrast. But we'll have 15,000, 20,000 people be watching this on social media, right? 130,000 people will listen to it on podcast. And who knows on the YouTube. It's a scale that we didn't even really think about it before the pandemic, did we?

You know, and podcasts, by the way, that's another great example. You think about how I mean, I think that's why everybody is doing podcasts now is because it is such a personal medium. Like when you listen to somebody for an hour, you feel like you know them. And that's an amazing connection, even though it is like done at scale. That's why, you know, when we did the book, they asked me, do you want to narrate the audiobook or do you just want to have a professional, you know, professional reader, an actor do it? And at first I was like, oh, I don't, you know, I'm pretty busy. Like I don't have time to go read the book myself. And I'm not a professional actor. Seems like I'd be better off having a professional actor. But then I asked the question, I said, what percent of people consuming the book are going to consume it in audio format? And our publisher said, probably about 50%, half.

Half of the total audience will consume it in audio.

Half of the total audience these days is probably an audiobook. I said, wow. And you think about a podcast where you spend 1 hour with somebody and the connection you create. What about when you spend, you know, 15 hours or however long the book is? That is a great opportunity to create connection. So I recorded the audiobook myself.

Yeah. People don't— it is part of the insider's— the ROI of doing your audiobook at scale as a bestseller or doing a podcast that has scale, people don't get it. It's the highest ROI use of your time for scale, right? The reach is incredible, right? So let me ask you two I had two sort of tactical questions I want to hit. They're so broad, but when I reflected on our last conversation today, I wanted to distill just two things we didn't hit. And then let's talk a little bit about Twilio. But this is the most basic question that I think half your book is about. Well, maybe not, but it spoke to me. But how do I, for folks, how do you know, especially if you, for folks that you're first-time founders or you're running a division, you've inherited something and you haven't met, how do you know if you have a great developer? How do you know? What are the signs? How do you know the answer to this question?

[Speaker:JASON M. LEMKIN] I think what you're really looking to understand is not how good is their code and what algorithms did they use or whatever. What you should really be asking yourself is, are they a good business partner? So are they able and willing to think about the big customer and business problems that we have, and then come back with reasonable solutions built in reasonable timeframes that address those problems? And I think if you answer yes to those questions, and that's something that every business executive can understand, like you don't have to know what's going on under the hood. Do they use this operating system or that language or whatever? Like, you don't have to understand that. What you really have to understand is, are they a good partner? Are they able to take— like, are you able to discuss, like, here's this big business problem that we're trying to face. And they're a sparring partner for you. There's someone who wants to bat around those ideas, then come back relatively quickly and use sort of an agile process to say, I think we've got a solution to these ideas. What do you think? And if you have that kind of back and forth, I think that's a great developer because they're able to take their domain, their technology skills, and apply them really successfully to the business and be a partner for you. And I think it's the kind of developers that may be less of a good partner, you maybe say, oh, it's not as good of a developer if they're like, hey, just tell me what to build. Because then you're not really unlocking, you don't really have a talented, well, you don't have a partner bringing a different talent to the story. You've got someone who's just saying, give me orders. And I don't think that is what makes a developer who's really going to, especially at a startup or at the early stages of a new project, that's not the person who's really going to help you get there. And a lot of people focus on this idea of what makes a great developer. And people talk about the 10x developer, the person who can build some amazing things single-handedly in one, giant Mountain Dew and beef jerky fueled session. And I'm like, I don't think that is a great developer, actually.

At least they don't scale, right? At least they don't scale.

Yeah, they can do some heroic things in the short term, but ultimately, it's, you know, my classic, like, who is the most famous 10x developer from popular culture? Dennis Nedry from Jurassic Park. Remember? I guess so. Remember, he's the actor who played whatever on Seinfeld, the postman. And, you know, he's like the one guy, he built the entire everything for Jurassic Park, right? And then what happens? He gets eaten by a dinosaur and gets bought off by their competitors, right? And he gets eaten by a dinosaur and they're all screwed because they can't get the security system back up and running. It's like, is that the outcome you really want for your company, right? Where I've got this one superhero and if they leave the company, you're screwed and the dinosaurs are all loose. You know, it's like, no. Like what you want is a really high functioning team and you want the ability to scale that team. You don't wanna be over-reliant on one superhuman. You know, you want a great team and you want a great culture of developers. And oftentimes, that 10x developer actually sours the culture, prevents progress, and impedes other people from actually contributing and doing a part of their job. And so my understanding of a good developer is not that 10x developer who gets everything done in like 2 hours and they're the only one who knows how it works and it's all in their head, because now you are completely reliant on that person and that's not the way to build a company.

Yes. I— They have their place in the early days, right? But it's, you know, at Adobe Sign, the company I last founded, our 10x guy is still one of the chief scientists because at $400 million ARR, he may be the only one that knows how 20% of the codebase runs, right? It's good and bad. One niche question, and then if in terms of risk, right, I see this play out a lot in terms of the one, When a developer wants to take a risk, I want, I just want, I want it to work. Someone comes up with some kooky idea for some voice API I've never heard of. I don't know, we can come up with a different example for fun. The better your developer, the more you can trust them to take risk on a new vendor, right? Or do you agree with this? Or when can I trust my developer to take risk on an emerging vendor or something I haven't heard of versus the brand name, right?

[Speaker:BRAD_STONE] Well, I mean, I think the question is one more of, do you value execution, rapid execution, experimentation, and the ability to build quickly and answer to your customers in an agile way? Do you value that? Or do you value a more slow and steady approach? It's not a great way to phrase it, but what I think you need to be trusting your developers with is picking the tools that they're using to serve your customers. [Speaker:JASON M. LEMKIN] Exactly. [Speaker:MICHAEL SEIBEL] So what you should agree on is like, here's what we want to accomplish and here's how we want to accomplish it. So the what is, what is the big business problem we're trying to solve, or the big customer problem we're trying to solve? And the how is, are we going to be a company that's agile, that would rather experiment our way towards the right answer and iteratively build things? Or are we the kind of company who thinks like, well, we've got this big master plan and we're going to just execute against our master plan, and it'll hopefully all work out in the end. And I think most companies nowadays are thinking more in that agile sense of, you know, we've got a vague idea of the customer problem we want to solve, but exactly how we're going to solve it, or even if that customer problem is the right one to be solving, is a hypothesis to be tested against customers. And in that world, you're going to really value the ability to execute in an agile way. And what's amazing is that's what the software supply chain So all the APIs in the world are there to help you do, whether it's AWS with compute and storage, Stripe with payments, Twilio for communications, the whole software supply chain enables your company to buy the things that let you build. And that's what the best companies are now doing, right? Because you don't want to be beholden to just something you bought. And that's what happens oftentimes in SaaS. Like I bought an app and it does what it does. When the customers say, well, I want it to do this, you have to be like, well, that's not what it does. Or worse yet, you know, you and all of your competitors bought the same app to power some part of your customer experience. And now you're all undifferentiated because you all just have the same exact app, right? And so the best companies are out there saying, well, I need to listen to my customers. I need to hear their problems that are going unsolved, and I need to build the solution to those problems. But if you think about like, oh, but I have to go build everything myself. Well, now it's a Herculean feat, right? You're not going to be able to build everything. And so that's what the software supply chain of APIs like Twilio, Stripe, or AWS allow you to do is to buy the things that get you up to here, that then let you go build the differentiation. And so I think as companies are getting on board with and winning in the digital economy, it's the companies who recognize that you buy the things that enable you to build, and ultimately the things that you build that differentiate you in the market is what allow you to win.

Do you think as even the biggest and oldest companies get more agile, to your point, when you talk with bigger customers, is no-code for real, or is this too nerdy a concept? Do they get it, or is this sort of a wrapper around something we've all been trying to do for a decade?

The way I look at it, there's sort of like— there's 3 types of things. There's no-code, low-code, and what I call yo-code. Is like the three flavors. I think clearly we understand the world of, of Yo Code, uh, because that's how most of the world has been written. But I look at no-code and low-code is there are plenty of areas where either developers, you know, really don't have to build all the things, there's a little bit of flavor they need to put in, but ultimately they want to build something with as little code as possible and not have to worry about actually operating it. Because if you think about it, part of the value of low-code, no-code, and just APIs generally is the fact that it has gotten easier and easier and easier to build software. Think about all the libraries and frameworks and everything that we now have. It's getting easier and easier and easier to build software. But at the same time, over the past 20 years, it's gotten harder and harder and harder to operate software at internet scale. Because the scale, the global customer base, I mean, you're now serving billions of people on the internet. So it's getting harder and harder to do that reliably, securely, with low latency, et cetera. And that's where the value of all these platforms allow you to essentially outsource operations to somebody else who's going to specialize in that. That's why I think APIs have replaced in a lot of ways the role open source 20 years ago might have played in business.

[Speaker:JASON M. LEMKIN] Yeah, that is interesting. Isn't it?

[Speaker:JEFF LERNER] Because with open source, amazing software out there, but you had to operate it yourself. And that was hard, it was scary, it was ripe with like areas where you can shoot yourself in the foot. And so the more like hosted versions of open source came out. I mean, a lot of AWS is just hosted open source, but the value you get from them is that you're trusting them to be expert operators of that software at scale. And so I think low-code and no-code are flavors of that, both because they open the aperture, like who wants to write code for something where you don't really have to, when you could drag and drop? I don't think developers love writing code for the sake of writing code. They love writing code because they get to build things. But if they can build things in a way that is a quarter of the time and has no operational overhead, because it's just deployed and operating at internet scale, who doesn't want that? Then you start to get into, oh, and now there are people who aren't developers who are now able to participate. I think that hypothesis has been less proven out, honestly, but I think developers Even developers who could write code and could put it up on a server that they run opt to take the path of least resistance and the most operational security when they can. And I think that's the role low-code and no-code is certainly playing. And I think there's an open hypothesis about whether non-developers will be able to use those same tools.

Yeah, I'm embarrassed to say I had not really thought through the idea that in many ways API is like the next open source, right? It is, uh, it is forget about the technicality of the license, it's taking that power and making it two orders of magnitude easier to deploy and use, right? Open source is not easy to use, right? It's just powerful. It's a— one, one just sort of high-level question because of the two types of audience you're speaking to in Astro developer, big companies and startups. I don't know your— I suspect for many large companies that want to automate a particular workflow, software is 10 times easier than a decade ago and maybe even 100x even 15 years ago. For startups, and I wonder if it's the opposite, because now that I have Twilio and I have SendGrid and I have Segment, the bar is so high, right? What you have to do to create a sellable product with 100,000 SaaS vendors, they have to do much more because there's no excuse, right, to not automate, to not have all these pieces automated from the beginning. So I feel like software actually has to be much better today, which outweighs that it's easier.

Well, I don't know if that's exactly true. I think the most important thing that folks think about, while it is easier to build software, in some ways, it's just as hard to solve a big, important customer problem and build a go-to-market around that.

Yep.

Now, there are things that make it easier, whether it's AdWords or if you have a mobile app, distribution via app stores and things like that, But those two get very saturated. It's very noisy. And so you still have to build software that solves a customer problem. And I wouldn't say like the hardest problem is how do I build really good software? There's a lot of people who can build good software. Still, I think the crux of the problem is how do I build the right software to solve the right customer problem? And that's the challenge of business time eternal. And I think that it's still, because it's a relatively crowded marketplace for SaaS, figuring out what's the right problem to solve that's a big enough market, and have I cracked the nut on the go-to-market to figure out how to get my software in the hands of the customers who need it?

Like, for example, for, for Flex, right? I want to chat about a little bit later, but Flex is Twilio's toolkit and service to build cloud contact centers, right? Which, which almost didn't even exist just 5 or 6 years ago, right? Has that enabled new use cases or new types of things that folks weren't even doing in contact centers 5 or 6 years ago?

That's a great example. So what we built with, with Flex, we call it an application platform, which is it does the contact center things out of the box, but it's a developer platform that is designed to be built upon. And so on the backend, there's all the APIs, even on the frontend and the user experience, it's all React app. Customers can build their own React components, upload them, and really make that experience whatever they want it to be. And truly whatever they want it to be. Like a lot of SaaS products have few customization parameters here and there. Like you change the logo or the colors or whatever, right? But you can't really get in there with code and completely change how the thing works. And that's what we did with Flex. And what's interesting about it is that has enabled truly developers to build new types of use cases on top of Flex in record time. And I'll give you a great example from last year. Contact tracing is a use case we never anticipated when we built Flex.

That's for sure.

The idea that somebody would get a virus and you need to call all the people he interacted with, right? And nonetheless, when that use case rose to prominence last year because of COVID we had a number of organizations build contact tracing on top of Flex and deploy it in record time. And so now Flex is being used to contact trace over half of the American population, because it's been deployed by the city of New York and, you know, many states, cities, universities, etc. Who are using Flex to do contact tracing. And that's a really interesting example of like, well, we didn't build it for that, but when the need arose, developers were able to take Flex and really quickly build the answer that the world did need.

Hmm, and then what's the— and then I get, I mean, that's incredible that half of the contact tracing is powered by Flex, right? What were they doing? I haven't been contact traced myself yet. What are they doing at the end-user developer perspective that they couldn't do with an off-the-shelf product? Like, what was that novel use case?

Well, it's all about a workflow that society didn't really need until last year, right? So there's a whole workflow around who do you contact? What do you say? What do you track when you contact them? All of that had to get built out.

I see all that workflow and then in the apps and everything is managed by Flex.

Yep. And then what happens, you know, what, you know, I call you Jason, Jason, you were in contact with someone, I'm going to follow up with you in one day. If you've got a temperature, you need to reach out to me, blah, blah, blah, blah, like that whole Workflow, and it's not just one touch, it's multiple touches and all that complicated needs to get built out. And so it's like, well, do you have a platform that allows you to build? That's the fundamental question. Yep.

All right, one last high-level one from the book, and then let's talk a little bit about some learnings from Twilio. But we just chatted about this a little bit over the year. This is implicit in the book, is alignment between business and your developer alignment, right? What are your just top 1 or 2 tips to get folks on the same page, to have them see when the sales team's pulling out their hair because they won't automate this workflow? And how do you bring folks together? Is it just transparency? Is it KPIs? Is it getting on the phone with customers? What are the top couple of ways you've learned to drive alignment here?

Look, the number one thing that I would say is think of your developers as creative problem solvers. Don't think of them as people who grind out code. Think of developers as creative problem solvers. They love chewing on hard problems, and their particular tool that they like to use to solve those hard problems is code, is software. And when you think of developers that way, what you want to do is share problems, not solutions, with those developers. When you do that, you get a great amount of alignment, you get intrinsic motivation out of everyone on the team, and you solve business problems faster, better, and with higher quality. And I'll tell you why. Most companies think of software developers as people who just turn specs, like product specifications documents, into code. And so they think of developers as people who are disinterested in the business and don't really want to talk to customers, who really just want to be headphones on, head down, with their face in a computer. And so therefore, if you believe that, what you would believe is that, okay, I'm going to have my MBAs or my product managers or someone customer-facing, go write a product specifications document. And then if I hand specs and enough Mountain Dew in the top of this machine, the developers turn it into code at the bottom of the machine, and that's how it's supposed to work. It's like this digital factory assembly line, basically. And I think that model is completely wrong. Because in reality, if developers are creative problem solvers, and you see this all the time, right? How many founders are actually developers? How many founders are creative problem solvers and actually create companies because they want to solve customer problems with code. If you think of developers like that, what you need to do is share problems. So instead of saying, "I need a form that's got a field that says first name and it's 40 characters long," like that's what a spec says. But sharing a problem with the developer says, "Hey, you know what we're trying to solve for? If we could make it so easy to sign up for our service that it takes 30 seconds instead of currently it's 10 minutes, then we could really drive the needle of our signup rates and our business growth." Share that problem with developers. Now they might come up with all sorts of interesting ideas for how to solve that problem that aren't just a form field that's 40 characters long that says first name. The other thing that's interesting, another insight I got from talking to one of the developers I interviewed for the book, this developer named Chad, he said, you know what's interesting is when you're handed a product specifications document, it specifically spells out a path that in order to solve a business problem, you need to go here and then here and then here and then here, 'cause it spells it all out. And in fact, developers in that bad model will often say, "Oh, the spec doesn't indicate if I need to do it this way, this way." And they send the spec back. You gotta tell me what to do, right? They're enforcing this idea that they're just assembly line workers. But the developers, they're the ones who know the most about how the code currently works, how the architecture works, the available options that are out there. And so when you tie their hands by saying the solution has to go this exact path, and then you say, "Developer, give me an estimate for the project." And you come back and they're like, "Well, you know, I looked at it. It's gonna be about 9 months." And what do the business people do? They pull their hair out. What are you talking about? That's crazy. Why is it 9 months? Well, you tied my hand. You said I had to go here, here, here, here, here. And I spec'd out how long that takes and it's 9 months. But if you remove those handcuffs and you say, what we're trying to do is get to here. Now the developer can say, oh, interesting. I see a much shorter path, which is the straight line. Because I know how the code works, the architecture works and everything. Oh, that could be 1 month. And so that's why I say if you share problems, not solutions with developers.

Yep.

You're going to get better solutions written faster and with higher quality. Because guess what? Now the developer actually cares. Like they have an intrinsic understanding of the problem they're solving and it's personal. They're bought in. I want to solve this problem. I've been amazed at the problems that I, as a developer throughout my life, have gotten excited about solving. Like not things that are like, you know, just stupid little things that you start to wrap your head around. You're like, oh, that's really interesting. Like when I started a retail business, I started a bricks-and-mortar retail business. Doing extreme sporting goods. My co-founder, who was completely non-technical, and I had a really good working relationship where he'd share problems with me. And I share this example in the book of the time he came to me and said, you know, Jeff, I'm trying to figure out, we got all these store employees and salespeople, and I want to incentivize them to like approach every person that walks in the door and offer to help them. And I think the best way to measure if they're doing that is actually to measure the conversion rate of people who walk in the door to how many people buy. Just like you might on a website. I was like, oh, that's super interesting. He's like, can you figure out how to do that for me?

That's inspiring, right? That's—

I was like, I'm like, yeah, like, that's not like intrinsically a really interesting, like, you know, problem. But as a developer, I was like, oh, that's super interesting. Well, you know, they have those like those door counter devices with the beam of light at the door that you walk through, it breaks the beam of light. I bet we could get one of those and find one with an API so I could pull the data off of it. And then I could correlate it with the purchase data in the point-of-sale system. And I could put a little widget on the point-of-sale that shows in real time, like the conversion. Yeah, I think we could do that. And literally I came back like, you know, 3 days later with an idea all fleshed out. A week later, I got my hands on one of those people counters. And like 2 weeks later, the problem was solved. And I got really into it. Like, this is an exciting— now that I'm thinking about it, the gears are turning off. Like, who would have thought that I'd ever give a shit about these like people counters at the door of a store? But when he shared the problem with me, I was like, that's a really interesting problem.

Yeah.

How do we incentivize our salespeople to do a really good job serving our customers? And so I go back to, if you share problems, not solutions, you're going to really unlock the talent. Your developers are going to be more engaged. They're going to be happier. And because they understand the customer and the problem they're solving, they're going to be able to do much better work.

[Speaker:JASON M. LEMKIN] Yeah, I think that's really the biggest learning that I've had and takeaway is that share the problem, right? And let them come up with a solution. Just one final follow-up on that, and then We'll hit the next point. But so I'm all with you on that. I mean, you're the leader. It's my experience. Is it— what do you think out of all of this in terms though? And I hate giving them the spec and forcing them to build the product exactly the way it comes from the design. I mean, it just, it's suboptimal. But is it fair at the end to judge folks on story points or similar goals? And is it fair to ask your lead developer, your VP, whatever it is, to increase story points, say quarterly? And how do you feel about this whole quantification of all this process through story points or similar metrics?

Yeah, I think that is, that is totally fair and it is healthy because what that is is a measure of team health and team efficiency. And story points are just a made-up number, right? So you can't compare, you know, the story points of this team to that team or the story points of that team to your last company because story points are just a fictitious number. All that matters is that the way they measure story points, which is essentially the amount of work that some task is going to take, is that they measure it consistently, sprint over sprint. And what you want to see is sprint over sprint, and more likely, kind of quarter over quarter, year over year, those teams getting better and better at both predicting their velocity, so how many story points they can complete in a sprint. So predicting the velocity and increasing the velocity. And what that is a measure of, and it's not because you're trying to create a sweatshop of like, you know, more, More story points, people. What you're really trying to do is how well is this team working together? How good are they predicting the workloads and their own ability to execute? And is that essentially that system, that process getting better and better and better as they go? And I kind of liken it to if you have a sales team. I make a lot of parallels in the book to sales teams. I find that a lot of executives, especially in B2B companies, really understand how sales works and they really know their sales leaders. Because the perception is that that's how the company makes money. So I really have to understand that function. But I make the argument that you should really understand developers in the same way. And so the parallel I make to sales is, in sales, you want to know your salespeople's quotas, you want to know their quota attainment, you want to know how the pipeline is progressing through the quarter. Those are all things that you inspect and you want to know. And with developers, it's kind of similar, but what you probably want to ask about, not is this feature ready, is that feature ready, Is this product shipped? Like those are output metrics. The input metrics that predict future success in your developer team is how good are they at predicting story point velocity and how good are they at increasing that velocity over time? Because then that says whatever problems we need to solve tomorrow, we've got a healthy team that is working well together and knows how to predict, knows how to predict the workloads and then execute on them. And that's what you want a really healthy engineering team to be able to do.

I think it's a huge takeaway. I mean, personally, sometime in the last 24 to 36 months, I don't know, I've seen a sea change of the resistance to being measured by story points fade away, and I've seen engineering leaders love it, like really lean in on it, like consistently. Um, and I'm glad to hear you're a fan because I think there was a time when people thought it was, it was also de-creative, not giving developers enough credit for the unpredictability of some, of some feature development, right? Turning them—

that's interesting, right? In, in, in story points, you actually get a measure of there will be unpredictability. But if you're really good at breaking down projects and predicting story points and projecting those out, then you can actually account for predictability. And so if your teams are really good at that, then unpredictability becomes part of the equation. And I liken it to, for engineering leaders who push back on this kind of stuff, I liken it to sales. Like in sales, if you have a sales leader who misses their projections or misses their commit on a quarter. Well, what do you do? You're like, you can't do that, sales leader. You do it twice in a row, you probably get fired. Right? And so predictability of your sales process is really valued. And so I think the same thing goes in engineering. So teams that can't predict how much work they're gonna be able to get done, or even how much work there is ahead of them, that's just not a well-run machine. And, you know, so I think you liken it to that. Now there's a lot of, I understand the pushback, by the way, because there's a lot of bad measures historically people have tried to hold engineers accountable to. How many lines of code written? You're like, that's a horrible measure. Horrible. There's a lot of bozo metrics that are out there. And so engineers are often skeptical about some measure. But I think if you push back and say, well, you can't measure us at all, well, that's also unhealthy. And that's not what engineering leadership should strive for.

One follow-up on that, because I think it could be so helpful to other folks. It's your point to me, it's so insightful that a great engineering leader should create predictability around that unpredictability, right? As cycles go on, you get a sense. How many projects take longer? How hard is this code? Base to maintain.

It's like, it's like to carry that parallel forward, I would say, hey, engineering leader, do you think those salespeople, like, can they control a customer and like force them to sign the contract? Of course not. Yeah, there's a lot of unpredictability in the sales function. Yet a well-run sales machine is able to account for, yep, there's a probability the customer is going to sign or not in this quarter. And the sales machine accounts for that. And a good, well-run sales machine is able to really well predict. What we think the sales are going to be in this quarter or next quarter, whatever it is. And so I think when you, when you make that point, you're like, are they holding a gun to the customer's head and saying, you must sign it because I told my manager you were going to sign? No, there's a tremendous unpredictability in that process. Yet that discipline has figured out how to get predictability. I think engineering can as well.

Do you think then, just do you think it's fair when you bring in a new engineering leader to just like in two quarters of sales, Sales aren't increasing. You had the wrong hire for your VP of sales. Do you have to see an increase in velocity in 2 quarters? And if after 2 quarters you hear your engineering leader complain about technical debt and others, is that acceptable? Shouldn't they be able to predict the impact of these things after 2 quarters? Do you have to see that improvement?

What I would say is I think the discipline of predicting engineering velocity is less mature than the discipline of sales.

That's for sure.

Right.

Yeah.

And so I intellectually, the parallels hold up. In reality, though, it is a less mature discipline, but you can't hold engineering leaders, sadly, to the same standards. But it doesn't mean you shouldn't try and work towards that goal. That's what I would say.

That makes sense. We're there, right? Just a couple minutes on this, and we'll just take a couple questions, then we're out of time. I mean, goodness gracious, the cloud got big, didn't it? I mean, look at this number. You should be proud. I mean, good God, 65% growth last quarter. I mean, it's crazy, right? Top question, curious what you think, because you talk with so many folks. Cloud got really big, right? That's not ending, right? If you look at AWS, Azure, Google, we can look at the very top of this, and they're all predicting, you know, another doubling. But the CIOs have also moved more of their budget, right, to cloud. Like, can this last forever, or is there— do you hear, or is there going to be any pushback from so much of the CIO's budget going to cloud?

I mean, I don't think there's a natural point where you'd say we've reached the right on-prem versus cloud, right?

Well, it's more we can't have 100% of the IT budget go to SaaS and cloud, right? Why not?

It's probably 110%, 150% of their budget. The reason why is because two things I would say. Number one, the budgets are just growing because what's happening is IT is moving from a cost center to the profit center.

Yep.

Right? So in a cost center world, you're trying to outsource as much as you can, you're trying to minimize costs, because when IT was about, you know, does the printer have paper in it, do the laptops work, and does the financial software keep humming along, it's like, okay, that's a cost center. Customers don't care about that. That's not how I'm going to compete for customers and win. But now, you're looking at the role software plays has moved from the back office to the front office. Software is how I'm going to win customers. Software is how customers are going to interact with my company. And software is how I'm going to not just earn customers' business and serve them, but also create loyalty and repeat business. So in that world, you're investing in making software your competitive differentiation. It's a totally different role that software is playing than it was 20 years ago. 20 years ago, you said, oh, we need something. Do I build or buy it? And usually you'd say, well, it's a call center, there's some vendor who will sell it to me and I get RFP with 5 of them, I'll grind the cost down, and then I'll pick one and never have to think about it again. And that was the world of financial software. But now, what happens is typically a startup enters the field and says, oh, we're a great software company. We're going to go listen to customers. We're going to go build great software, build great experiences. And they start winning the hearts minds, and wallets of those customers. Because think about it, this is now where you win customers. Think about your bank. 20 years ago, you liked your bank if you walked in the front door because it was a physical building and it had a recent paint job on it. And the teller was friendly and they gave your kid a lollipop. You'd be like, oh, I like my bank. Nowadays, you like your bank if the app doesn't crash and it's got features and it's getting better all the time and it's easy to log into and all this kind of stuff. So when your bank becomes a digital one, the competitive battlefield is all the software that they build. And so nowadays, it's not a matter of whether you build or buy. You can't buy. You can't buy a differentiated customer experience. You have to build it. So it's not build versus buy, it's build versus die. It's literally a Darwinian evolution of every industry that's going on. So in that way, these budgets are getting bigger and they're more strategically important. These projects have visibility at the C-suite of the company where 20 years ago, they probably didn't. Yes, I just think it's a totally different ballgame.

I mean, I think for me, the idea that software was eating the world took me a while to understand it, but if it keeps eating the world, the CIO's budget approaches revenue, right? It approaches all the revenue. I mean, not literally, right? Because you have to pay folks, but it could be close, right? So just two others here because we'll get short on time, but I want to get— let's, let's do the third one on the slide last. So we're, we're all going to be getting our vaccines in the next couple months, right? Um, what are you seeing? What's going to be different after COVID? I thought Zoom's last quarter was interesting. I mean, Zoom quadrupled last year, $1 to $4 billion in ARR. I mean, oh my God. And then they predicted 43% growth next year, right? And that's still adding $1.6 billion of net new. That's a lot to add. But Zoom didn't say we're quadrupling, obviously, like we're— so what are you seeing? What, what are we What are you seeing from Twilio's or other perspective as we come out of this last, this current phase and get vaccinated? What are we seeing in terms of software or otherwise?

Well, I think we've seen essentially an acceleration of every company in every industry's digital roadmaps. Yeah. I actually don't think a lot of what just happened to software and to the cloud is like a diversion from what would have happened otherwise. It just happened faster. Do I think companies would have adopted teleconferencing, video conferencing, and really leaned in on that? Absolutely. Probably wouldn't have happened as fast. I look at telemedicine, great example. So telemedicine, we've got a lot of customers building telemedicine on top of Twilio, like Zocdoc and Epic, the EMR company. And I think about telemedicine, because early in COVID, almost all doctors visits that weren't emergencies turned into telemedicine visits. And so many of us had our first telemedicine experiences during COVID And I think about that experience. I'm like, so let me get this straight. I used to, like, if I had a minor medical thing, I'd have to, okay, make an appointment with a doctor, you know, a month out, and then drive across town and take a half day off of work, wait and sit in the waiting room with other people that I think are getting me sick. And so you're kind of like, you know, and now I can just make a 15-minute appointment probably for tomorrow. I don't even have to leave my desk, just look into the camera, talk about some minor thing and get a prescription or advice or whatever it is I'm looking for and be on with my day. What an amazing experience that is. Before COVID telemedicine visits represented a fraction of 1% of all medical visits. At their height, I think it was like 40%, 50% of all visits, like a year ago, last April, May. It's coming back down to a more normal level, but it's probably going to be in the teens or 20%. Because it's such a better experience for the patient, for those visits where you don't need to see the doctor in person. And so I think that like that's a great example of this acceleration of the future we were already heading towards, but it's just happening sooner. Same thing with e-commerce adoption, same thing with a lot of delivery and curbside pickups, same thing with a lot of these digital experiences that we're having. Look, society was already on the path to digitize a lot of these experiences, it just happened faster. And so it's really exciting to see these roadmaps that are unfolding with urgency quicker. These projects are getting C-level attention where they might not have otherwise. And that's just raising the stakes, but also raising the execution at companies of every shape and size.

I think early in this, maybe not you because you had a lot of data, but I think some of us wondered, okay, would we revert back a little bit, right? After we came out of— seemed like this might not even last that long, right? But maybe we'll turn off our Zooms, maybe our Slack will go back to normal or what be it. But it doesn't seem like there's any evidence of that. We've just pulled the future into the present, and there doesn't seem to be anything that's going to go back to the way it was before.

[Speaker:JASON M. LEMKIN] Well, it's funny, some investors have taken that literally. They've said, oh, well, if— we did a survey last year, and we asked, how much do you think COVID accelerated your digital engagement roadmap? And on average, companies said 6 years. And so in some conversations I have with investors, "Well, so literally, did you pull forward 6 years of revenue into one?" I'm like, "No, like maybe Zoom Day, good for Eric." But I don't think that's literally what happened, just the importance and the execution of something was going to take 8 quarters to build, it's probably taking 4 quarters now.

[Speaker:TREY_LOCKERBIE] Just got pulled forward.

[Speaker:MICHAEL_SEIBEL] And it's like, what's going to happen after COVID? Are the companies going to fire all their software developers, like, "Great, we don't need you anymore." It's like, no. Now your business is even more dependent upon digital, and customers expect it. So the these roadmaps get even more strategically important to every company, not because everyone's at home in a pandemic, but because that's just the new expectation. That's the new definition of a great customer experience.

Do you think, just think like cloud contact centers are super interesting, like Zoom and all that gets more attention, but actually contact centers were amazing because folks all of a sudden had to spool up thousands of agents in weeks. And these were projects that often had multi-year planning, right? We're going to go from an on-prem solution like Genesys, and in 2027, we're going to go— and it had to happen in weeks. Has that changed? Was that going to change folks' expectation in the enterprise of deploying faster all this? Can we go back, or is it not okay to have to wait 3 years to deploy Salesforce? Or is that behind us?

Well, if you look at what happened during COVID you saw the typical change management that goes on inside of a big company. There's an idea, there's a project, people worry about the risks. Is it my fiefdom? Is it your fiefdom? I'm the naysayer, I'm the proponent, like all these. All this stuff just disappeared, right?

Disappeared.

Right, because when you say, I've got all my agents, and they're sitting at home, and they can't answer the phone, I got to put something in. Like we have the story of, you know, QVC Italia, who when Italy was on lockdown, they had all their agents at home, couldn't leave their homes, they put in Flex in 3 days. Typically, one of those projects would have taken a year, 2 years, right? They got it done in 3 days. Because they had to. In some ways, a lot of the conversations I've had with executives, especially bigger companies, they're saying, how do I capture that sense of urgency? Maybe not 3 days, but how do I get through the molasses of the usual mechanisms of the company and actually instill that sense of urgency in people every day of the year when there's not a pandemic? I think people are trying to capture that fear because all the fear went away. Like, oh, well, what if it goes wrong? Well, we don't have a choice. It's already gone wrong.

Right?

Like that's what happens in a pandemic. But now how do you actually get over that sense of fear and you get that ability to experiment and act more agilely and say, I want to try something. And by the way, we tried a whole lot of things in COVID and guess what? They worked out great.

Do you think as a net result, maybe it's too early to tell, but to challenge us all, do you think enterprise sales cycles could come down after all this? Because now we know, like now there's no excuse to not at least get it done this calendar year. Do you think we might see dramatic shortening in some cases?

That's a great question. I don't know the answer. I won't project that one. I do think, though, that the—

We'll check it in a year. We'll find out.

Yeah, that's a good question.

All right, just a couple of questions from the audience before we run out of time. The first one I had in the deck we didn't get to, because you're so early here on pricing, consumption pricing. And the audience asked, it seems like this, annual SaaS contracts becoming a thing in the past, not literally, but less the default. It's certainly becoming less— I mean, if nothing else, Snowflake and all the rest after, really, we can see that developer-centric stuff, it's nuanced, like, truly. But what, what have— what are you thinking at scale? And you've got— we have a different slide— you're not highly concentrated, but you've got something like 12— 10% of revenue comes from 12% of your customers, right? So you've got everything. You've got small, medium, and large. An extra, extra, extra large. What have you learned on this pricing? What's state of the art in like 2021 for pricing for an API?

Well, I think consumption-based pricing really is the future for two reasons. One, it's better for customers, because they pay for what they're actually using. So who wants to pay for overages and breakage and buy software they're not really using or have to predict capacity? I just don't see companies really liking that exercise. When you can actually pay for what you use, there's an economic benefit to the buyer that they want. We've experimented in the past. We've said, I wonder if companies, especially enterprises, I wonder if they value predictability. We floated big packages in front of them. Here's a package of Twilio, and there's going to be this breakage notion. Every time we floated those ideas, they say, well, why would I pay you more when I could pay you less? Then we're like, well, that's what we assumed, but we thought we'd try it. They were like, it makes sense. Why pay for what you actually use? It's just a better business model. And it's like at Twilio, there's absolutely no shelfware. That concept is just gone. It doesn't exist anymore. And that benefits customers. The second reason is that it benefits both customers and the vendor. So Twilio, when you have a usage-based pricing model, it allows us to onboard customers incredibly easily because any developer and this goes for, I think, a wide variety of functions at companies— any developer can get started with Twilio for $1. And they can get started experimenting and building. And look, you don't have to take our word for it. You don't have to watch our sales presentation. You can actually prove it to yourself. And then that employee becomes our biggest advocate inside of the company. So yes, at some point later, when that customer becomes a meaningful size, we're going to engage in a typical sales cycle, of course. But when we do, we're going to have the technical people who are saying— who are our biggest advocates. They're at the table. And some of our salespeople have described the process in like prior lives selling prior software products, how, you know, they're selling to the business person and the business person turns to the IT people and says, you know, is this possible? I'm like, I'm really excited about this. Is this possible? And the IT people are like, no, there's no way. It's going to take years. It's not going to work. And at Twilio, their sales cycles, the developers are the ones at the table saying, yes, we already actually already built it. Check it out. This is amazing. Like we're ready to go. In fact, we already did the work. And so it completely changes the nature of who your advocates are inside these sales cycles, let alone the deals where you don't even need a sales cycle because it's smaller scale, self-service, etc. You open yourself to another part of the market. But the other thing is it doesn't just ease the adoption, it allows both the customer to pay for only what they use, but the vendor to capture upside as the company is growing.

For sure.

So that's how you get the dollar base.

But is there a level, with your bigger accounts, They may not want everything to variable, right? Is there a certainty trade-off, whether it's just in committed use discounts or at others? Is there a breakpoint where the numbers just get— where they have to roll up into a fixed budget in a big company?

Well, typically what happens with a company like Twilio, where we are fairly well aligned to the company's revenue-generating activities, And so when that's the case, when they're paying more to Twilio, it's usually because they're making more money.

I see. It's Stripe-esque in their mind. Stripe too.

When you pay a percentage of your credit card transactions, sure. Would you generally speaking rather pay less than more? Absolutely. But you're not a cost center, but you're part of the revenue-generating machine. And I think that's where the role that software is playing is just changing the dynamics there, where if you're helping companies to make make more money, to be more successful, to onboard more customers, then you are providing a lot of value. And so if you scale with their ability to generate revenue, it's just a different conversation than if you're like a cost center.

Got it. Just two quick ones from the audience, then we will run out of time. Just for that, when you still hear knee-jerk VC and other founder advice to get a lot of cash up front, prepaid contracts, it helps you scale in SaaS, is your feedback poppycock, just make it easy on the customer, which is generally my feedback, or how do you see those trade-offs of trying to pull that cash forward versus pay a dollar to get started?

Yeah. I mean, pulling cash forward is not a bad thing. You pay a dollar to get started, that is pulling cash forward. That's building upfront instead of in arrears.

It is an early dollar.

So what I would just say is follow your customers. If you say, I'll give you— it's just an economic value to a dollar. I'll give you a discount if you pay me upfront. And if you give the right equation to a customer, And if they value the discount more than they value the cash in hand, then it's good for them. They'll take it. And if it's not, they won't. Right? So I just think follow your customers and depending on how much you value the cash flow aspects of that, you might give a greater discount than if you value it less and your customer probably is doing the same math. And so if you can overlap in how much you value that cash, then you've got a good customer success story.

[Speaker:BRAD_STONE] Okay. Last question. It's sort of related to some of these big themes in Ask Your Developer. And the question is, because you talk a lot about giving the great developers a problem and having them come up with a solution, which I think is the way you win. But the question is, when you work with developers, how do you find a balance between maintenance, sustainability, DevOps, technical debt, performance improvements that aren't revenue-generated, and the pressure to do revenue-focused growth projects, right? How do you maintain that balance?

That's a good question because that's a continual source of frustration, I think, for everybody. How much time do we have to spend maintaining? And I think a good healthy dynamic is one where you have a strong voice of engineering at the table. So where you get into trouble, to be honest, the revenue function of the company always has a strong voice at the table. 'Cause everyone's highly incentivized to care about that and to grow revenue and all that, right? So by the very nature, they will have a strong voice. That could be represented by sales, that could be represented by product, variety of people, but the incentive to grow faster and to make more money is always present. And so what you need to do is in some ways artificially elevate the role of the engineering leadership, and that could be your VP of engineering, it could be architects, people like that, and incentivize them, not literally with bonuses, but make it their job to care about the long-term outcome of the company, to build things right, and to give them an equal voice, and to hear them out equally. Because when you do that, you've got a chance at striking the right balance between— people always complain about technical debt. Oh, technical debt, right? Well, guess what? Technical debt is one of those good things that happens when you succeed.

Indeed.

Right? It's a natural outcome of business success. So we shouldn't bemoan it. We should just accept it as a fact of life. And once you do that, then the question becomes, we need to make good decisions about do we optimize for the next feature or the next market, or for shoring up the technical underpinnings? And what you can track is how much of our time— and we do this with surveys, so it's imperfect— but we survey how much of our developers' time is being spent on keeping the lights on, which I don't actually like that term because it's a derogatory term, versus new feature development. And I think actually good tracking— oh, there's a dog behind you. I just noticed.

[Speaker:MICHAEL_SEIBEL] Marilyn.

[Speaker:BRAD_STONE] You've got this— how much of our time is spent basically on these really strong technical underpinnings of making sure the product performs well, and we're not putting duct tape over duct tape, and new feature development? Because if you ignore, if you only do one or the other, you're not going to succeed. If you only— and I've met companies where great technical, really strong technical founders, and they've really built this amazing architecture, I'm not sure, but it's like, they're not winning in the market. I've also seen the story, right? Where you just build feature over feature over feature and the thing is like rickety and falling apart underneath and eventually it fails. And so you need to have the right balance of both. So I think there's like a rule of thumb somewhere in there that like, if you're spending about 30% of your time on maintenance, like that's probably really good. If you're spending 50, that's probably about average. If you're spending 90, you're probably, you probably need to shore things up. And so somewhere in there's a rule of thumb. I don't know if there is a commonly accepted one, but I know at Twilio, that's kind of how we think about it.

That's, I mean—

But the best way to answer that question successfully—

So I'd say that 30, 50, 70 kind of ratio is when you're in trouble. Yeah.

The best way to answer that question for your company where you end up, but it's not like one, it ebbs and flows, right? The best way to make sure you're striking the right balance at the moment in time for your company is to give your engineering leader a really strong voice at the table.

That's a good one. Well, let's end on that, Jeff. I know we're like a minute over. It's incredible to have you back. And a quick reminder, there's 150 copies of the book between Byron and us, but just throw out #AskYourDeveloper anytime, #AskYourDeveloper in SaaStr, anything you want. You can say, "I love Twilio," #AskYourDeveloper in SaaStr, anything you want, we'll track you down. And Jeff, congratulations on an incredible, incredible ride so far with Twilio, and we're all super fans, and we'll catch up with you soon.