CEO Jeff Lawson Reflects on the Peaks and Valleys of Twilio’s Growth Story

EP.15 - Jeff Lawson

Jeff Lawson: [00:00:00] Our chief product officer, she shoe has a saying, he says every day, our goal is to suck a little bit less. That was like that. It's very self-deprecating obviously, but it kind of expresses this idea that it's okay, everything's not perfect. We suck at certain things, but if we just suck a little bit less every day and we're building a stronger company as a result,

welcome to in depth, 

Brett Berson: [00:00:31] a new show that surfaces tactical advice, founders and startup leaders need to grow their teams, their companies, and themselves. I'm Brett Berson, a partner at first round, and we're a venture capital firm that helps startups like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review.

We've shared standout company, building advice. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast in depth, you can listen 

Jeff Lawson: [00:01:04] into these 

Brett Berson: [00:01:05] deeper conversations every single week. Learn more and subscribe [email protected]

for today's episode of in-depth, I'm really excited to be joined by Jeff Lawson, Jeff, the co-founder and CEO of Twilio, which creates products that power business communication. Jeff co founded Twilio back in 2008 and led the company through a successful IPO in 2016. He's also a new author, his book, ask your developer how to harness the power of software developers and win in the 21st century was published earlier this year in today's conversation.

We traverse a ton of ground in Twilio's company journey and Jeff's 13 year evolution as its CEO. He dives into some of the initial wins, like going against conventional wisdom to launch a second product in the early days of Twilio. But he's equally game to unpack some of the mistakes along Twilio's path.

Like when one of their biggest customers, Uber significantly scaled back their investment in Twilio's products. Jeff also opens up the pages from the playbook. He pulled from his time at Amazon chiefly. Twilio's write it down company value, and he makes the case for why PowerPoint is a terrible decision-making tool.

He takes us inside Twilio C-suite including why they do postmortems. When things go right, not just when they go wrong. He also sketches out his aha moment that his executive team needed to argue more. Finally, he outlines how he tries to strike the right balance between two CEOs. He looks up to Jeff Bezos and mark Benioff.

And grapples with one of the thorniest challenges for leaders, which is maintaining pieces of that startup DNA as a company scales up today's conversation is a really unique peek behind the curtain at one of the most quietly fascinating companies. And CEO's around, Jeff's got a refreshing, humble streak that shines through whether he's talking about Twilio's peaks or the valleys.

I hope you enjoy this episode. And now my conversation with Jeff. Well, thanks so 

Jeff Lawson: [00:03:21] much for joining us. Yeah. Thank you for having me here, Brett. Appreciate it. 

Brett Berson: [00:03:25] Wanted to start super high level and then use the time to go down in varying degrees of detail, but maybe want to just start with when you reflect on the Twilio journey thus far, why do you think it worked?

If you were teaching someone, the lessons or the reasons it worked maybe outside of. Some of the more obvious things like tech tailwinds or hiring exceptional people. What are sort of the primary reasons you think you were able to take this thing from idea through longstanding large durable 

Jeff Lawson: [00:03:54] standalone business?

Yeah. Thanks Brett. I think we'll never totally know the answer to that question. I mean like any business, I think you think, you know, what made you successful, but the reality is I just have to start by acknowledging that there's so much luck in what we do. And there are a lot of smart people working just as hard, if not harder and just aren't getting the break for whatever reason.

And so I just do have to acknowledge that there is so much lock in all of this stuff, as far as the things that we consciously did. I would just say there's probably two things that I would point to. And I think one was just. Knowing who we were and what we wanted to be and what we wanted to do. And in the very early days of Twilio, we got a lot of advice from people saying this whole developer thing.

Like, no, one's done it before. And developers, aren't an audience and it's the go to market. Nobody knows how to do that. And so we got a lot of advice telling us to go build an app. And the conventional wisdom was like, you can always add an API to an app if that's what you really want to do, but really APIs can't be a business.

And I think first of all, we had conviction that the developer was going to be an influential buyer inside of companies. And that developers were being trusted with innovating inside of every kind of company. And therefore it made sense that if they were empowered to be able to pick up new tools that were low risk and low cost, and you know, it wasn't like signing a $10 million contract.

It was just signing up for, you know, spending a dollar to go build a prototype. That developers would really lead the charge and that conviction wasn't just like our idea. It was being proven out by the early customers that we had in Twilio. We worked with a lot of developers early on, and we saw them putting in their credit cards.

We saw them bringing us into all kinds of customers. I remember some of our first customers were Intuit and Sony and the developers had brought us into those relationships very early on. And so we had early proof that what we thought was right was correct. And we stood by that conviction. And even though there were a lot of very smart well-intentioned people who said this probably isn't the way to build the company.

I think we kind of knew who we were. We knew what we wanted to be, and we had enough evidence that that was correct. Yeah, we stuck to our guns. And I think the result of kind of sticking to our plan, even though a lot of people told us we should do otherwise and knowing who our customer was and knowing who we're serving.

I think that really made the difference than if we had waffled on that or tried to serve multiple different customers or kind of had in our heart. We wanted to do this, but we let investors tell us to go to that. I think we would have had a very different outcome that 

Brett Berson: [00:06:45] conviction come from. Was it just the voice of the customer and focusing on them and seeing that, did you find conviction in some other place?

Jeff Lawson: [00:06:54] Well, as often as the case, it started with our own lived experiences. So I'm a developer, my two co-founders were developers. And in the beginning, we are just basically trying to say we are building something that we had needed. In our prior lives. In previous apps, we have built and previous companies, we have built, you know, I started three companies before Twilio and I was sorta thinking, I can imagine cases where I would have needed this at every single company I built before.

You never want to let your own personal experiences take you too far. Cause there's always a chance that you're an aberration that somehow your experiences are just different than the vast majority of people out there. And so the next step is to validate it with other developers with potential customers.

And before we wrote a single line of code to start Twilio, we just talked, we talked to developers, I had developed this very informal methodology. Whenever I had an idea that I thought, oh, maybe I want to do this idea. Ella, go talk to people who were likely customers of that idea. And usually friends, family, you know, people that I knew somehow somewhere.

And I would just sort of say, Hey, you know, I'm working on this idea. I'm curious, I'd explain the idea. And I always thought it was really interesting. So you explain an idea to people. And one of two things happen either you really tickling a niche that they have, you are talking about something that solves a problem that they have and may not have even known they had, but once you start talking about it, they kind of get intrigued like, oh yeah, well, that's interesting.

And they start to ask you questions about it and they start to ask you a clarifying questions. Like, oh, what would it do this? Would it do that? And what they're doing is they're pattern matching. What you're saying to a problem that they may want someone to solve for them. The other thing that happens, if you have not tickle the age that they have is it's just tremendously awkward.

They will listen to you. They'll be polite. And then they'll just change the subject because they don't really even know what to say. They'll be like, oh, Hey. Yeah, the job that's really, uh, that's super interesting. Hey, you know, Hey, how about those? Uh, how about those giants? Did you see the game yesterday?

And you're like, oh, well I guess, uh, you know, I didn't connect with them. And when we started Twilio, I did, I did that. I went and talked to a lot of developers that I knew, and I would explain what we were building. I'd say, oh, you know what? We're, you know, I'm working on this idea with an API, you write a few lines of code and you can make a phone ring and you can do all sorts of cool stuff on a phone call, or you can send a text message or receive a text message.

So like a few lines of code, you know, what do you think about that? And a funny thing happened at first, they would say, oh, Well, that's really interesting. Jeff, how about them giants? You see the game? I was like, okay, well maybe this is a bad idea, but about 30 seconds later, it's happened every time. About 30 seconds later, they would say, say, Hey, remember that, that thing you were telling me about with the phone, could I, and they'd name use case?

Could I notify a customer when the package ships from the commerce site that I recently built and I'd say, yeah, yeah, you could be super easy and they'd be like, oh, I get it. Yeah. Okay. Can I try it out? And I had enough of those conversations where you could see the gears start turning and they're, and they're matching what I'm telling them with a problem.

They had recently experienced as a developer where they had wanted to build a thing and couldn't, and just assume that they could, that's the way the world works. I want to do the thing, but I can't do it well to now realizing, oh wait, maybe I could've built that thing. And when you saw that pattern matching occur, they would suddenly like to perk up and they say, oh, I'd love to try it out.

Once we have that conversation enough times. That's when we got the conviction to say, let's start building. And so we built the prototype of Twilio. We did it pretty quickly. We did about three months was the first prototype muse, you know, not great by any stretch of the imagination, but it was enough to start getting feedback.

And we circle back with all those developers we talked to and said, Hey, remember that idea I told you about here. It is. Just try it out, give us feedback. That's all we want. And sure enough, those developers started building some really interesting things with the API and they started saying, and this was even the best part they started saying, oh, I know, like you asked me to keep it a secret, but you mind if I share it with this other person, because I really think they would have a great use case.

And we heard developers actually wanting to spread it to other developers. And so what we validated in that period of time was this idea that there were all these latent use cases out there that developers had wanted to build and just assume they couldn't because communications just, wasn't something a developer knew how to do it could do.

And that gave us a lot of that really conviction. If you think about 

Brett Berson: [00:11:22] the last 13 year journey, it sounds like this conviction in the problem and the solution and a unique go to market. This is long before the API economy and bottoms up and everything was a thing was sort of one key bet that worked. Are there other bets along the way that you attribute to the outside success that you've had in building 

Jeff Lawson: [00:11:43] the company?

You know, I'd say the other thing that I look at is we've always had a willingness to try new things, new products in particular that has served us really well. For example, a lot of people will give you startup advice and things that like, they basically say focus, focus, focus, or find a niche, get rich.

And like there's all these phrases that tell you to just do one thing and do one thing. Well, and that's. Not bad advice, but I will say that we owe a lot of our success to the fact that we were always very willing to branch out and try new things. So we launched Twilio voice was our first product back in 2008.

And that let you make and receive phone calls with API requests. And very quickly our customers started saying, Hey, I got these phone numbers from Twilio and you know, the phone number on my cell phone lets me not just make them receive phone calls, but also send and receive text messages. Is that something I could do with these Twilio numbers?

We said, oh, that's a really interesting question. And so we started researching this and at the time you really couldn't do that with phone numbers. You could text with your phone, but there was no way for like a business or an app to text with a phone number and the advantage of a phone number over what was the system of the day, which was a short codes, was five or six digit numbers you could text with.

With speed, because with a phone number or with a short code, they cost tens of thousands. You have to do long commitments. It took six months to get provisioned by a carrier. It was really reserved for big enterprises aligned towards that sort of style of building things, not towards the agile iterative nature of let's try something that's cheap and fast.

And if it works great, scale it up, if it doesn't work. Oh, well, cause that's our software works. And so we did is we brought the cost, the barriers of entry for them building an app with text messaging from thousands of dollars, months of approvals to 30 seconds and less than a dollar, it took to buy a phone number and tenure first text message.

And because of that, we were able to encourage so much more experimentation of new ideas and therefore so much new innovation. But that wouldn't happen if we had said no, no, no, no, no. We just launched our voice product. I think at the time it was probably doing. $300,000 of ARR. And so we could have very easily said, look, we have this brand new product.

It is just getting off the ground. Clearly the voice market is almost like a hundred billion dollars. We've got a lot of work to do before we think about product number two, but instead we followed our customers and we said, great, let's work on that. And so while we kept building our voice API, we started working in the very early days.

I mean, their company was probably less than 10 people at the time we started working on product number two, and I'm very glad that we did. Cause it turns out that messaging has become such a big driver of new use cases, new experiences that we all have interacting with a variety of products and has become a huge driver of Twilio's growth.

I mean, it's our largest product today. And so I'm very happy that we were willing to follow our customers where they took us, even if it meant launching a brand new product area, when the conventional wisdom would have said that was the wrong thing to do. So when you think about those 

Brett Berson: [00:14:53] first few years, How did you resource allocation across at that point?

It went from one to two and I'm sure other products and sort of the classic do we launch a new product versus invest 

Jeff Lawson: [00:15:02] in the core? You know, it's interesting. I would say that in the early days of a startup, I mean, I don't know if other startups like this, but at least in the early days of Twilio, the notion of resource allocation would have been such an academic concept for us.

Right. You really are following your gut in the early days. I would say maybe other people ran their startups differently at the beginning. Like, yeah. I remember at one point, oh, you know, we should have an annual planning process where we do budgets. And I was like, really? That's the thing, you know, like, so in the early days of the company, it was very much just like, we're going to try to follow our customers.

We're going to follow our gut and we're going to try things. And we made a lot of mistakes in that, by the way, too. I'll give you an example. There was a period of time where we launched our SMS product. It was growing really nicely. And the company, I don't know, it was 10, 20 people is still very small.

And we had all of our engineers working on a new product after that. And none of our engineers were working on the SMS product, even though it was growing like a weed. And that was a mistake, right. We should have said, okay, we got, we got to hit here. We got to double down, we've got to invest in it. We have to re we have to resource allocate ourselves.

Well, but we didn't do that. And so like that kind of following our gut is both good in terms of like, we listen to customers, we had an instinct that said, Hey, there's something here. We should go follow it. But the flip side of that is we made the mistakes of actually not intentionally, really investing in the core product that was winning.

It was taken off because we got distracted by the pejorative term is the next shiny thing. And, you know, I got definitely accused of that in the early days of Twilio, by some of our employees like, Hey, we keep chasing the shiny things. Which was true. And you do need to balance both of those things. We've gone through a bunch of frameworks through the years.

There's the horizons framework of horizon. One horizon, two horizon. One is the thing that makes you your dollar tomorrow. Horizon two is the thing that'll make you your dollar in a year from now. And horizon three is the thing that might make you an hour, five years from now, we've gone through that framework.

We've gone through a number of those things, but ultimately I think that some framework that is helping you ensure that you're investing in your core, keeping your core business healthy and growing. But clearly that can suck all the resources of the company. The current thing, there's no shortage of things.

Customers need. There's no shortage of wisdom that will say, Hey, you've got this core business. That's the cash cow of the company that makes all the money. And so therefore you need to keep investing growing it. And so if you don't ring fence off, some amount of resources know conventional wisdom is like 5%, 10%, whatever.

Into investing in the thing that you think might make you money five years from now, the next big bet, then you're probably running the company for too short term of an outcome. And I ascribed to that. The one thing I would say we don't really do at Twilio is think about things as the next big bet, because I think that you need to be having, you need to have five or 10 or 20 bets.

And that depends on the size of the company and the scale of the company, of course, but you need to have more than one potential bet that you're working on. And in the early days of those ideas, it's really easy to get married, to like, oh, we got this great new idea. I'm like, we did this to like, say like SMS and it is Twilio or the next thing that was after SMS that we were all excited about and all ran towards.

And instead you need to think like, well, there's many things that could potentially be the next great thing, but we need to run experiments to figure out if indeed customers want those things. If it is the opportunity that we think it is. And I think if you put all your chips into one next big bat and it doesn't pan out, then you've probably got a problem.

And so at Twilio, as we got more scale, what we started to think about is how do we run a number of those experiments at any one time? And there's a certain wisdom and discipline in being able to run multiple of those experiments and to be patient and to not expect those things to become giant businesses overnight.

So that's the first part of how do you run an experiment and treat it as a learning exercise? Not yet as a business exercise, like it's not measured in dollars and cents. It's measured in learning. If the market wants this potential thing you could build, but then the second wisdom that you need in those areas.

And we've screwed this one up too many times is when you learn that the market does want and need that thing, you're onto something is then pour resources into fueling it. And I think one of the common mistakes that we in, I'm sure other companies have made. Is like you fully allocate your budget at the beginning of the year.

And so you've got, okay, I'm going to five people go work on that idea. And five people could work on that idea and whatever you allocate. And one of those things is just taking off. We need more people. Well, you know, it's March and you know, your budget gets done in December. So, you know, we'll talk to you in December.

What a great way to starve an idea because of an arbitrary budget cycle on your calendar. And so one of the key things you need to do is to hold back and to be prepared, to invest when you see the signs of success and the idea merits that investment. And so there's both a matter of venturing out, you know, sending people out in the boats to explore these new ideas, but then when you see those signs of success, make sure you've got the ability to double down in real time when those things are needed and can use the resources that are taken off.

So I think that's where we've landed in our framework 

Brett Berson: [00:20:15] before we move on. Is there anything else in this category of how you launch new businesses or new products that you've come to rely on, or you've kind of figured out in the way that you operationalize that now at Twilio, 

Jeff Lawson: [00:20:29] that's still a pretty hard thing.

I would say for us to do, I will say one of the mistakes that we made early on, right? If you listen to folks giving startup advice, especially in go to market, what do they tell you? They say the classic mistake that especially engineers make when they are starting companies or creating new products, is they just assume that the thing they've built is so amazing that if you build it, they will come the classic term for the mistake.

If you build it, they will come. And everyone says you don't have that assumption. You've got to actually build a go to market plan. And I would say a Twilio with our first product voice. We didn't have a very strong go-to-market plan and we built it and they came and then we built our second product, Twilio SMS.

And again, we didn't have a very strong go to market plan and we built it and they came. And so we got away with what essentially wasn't anomaly twice in a row and the company was doing very well. And then we started introducing more products and guess what? People didn't necessarily come. We didn't know what to do because we never had to build that muscle.

We didn't really have the muscle of actually doing an integrated go to market and product plan. You figuring out the market and trying to figure out who you're bringing the product to and how are you going to get it to them. And so it was sort of interesting. We had this anomalous experience, I would say twice in a row that really got the company off the ground.

And then later in life had to actually figure out our go to market muscle. And in fact, when we went public in 2016, we only had about a dozen sales reps in the company supporting what in the 2016 of my memory serves me correctly. It was about $200 million of revenue and for a B2B business, even on the supported by developers as we are, but to only have about a dozen sales reps supporting, you know, a couple of hundred million dollars of revenue.

Is very strange. I don't think we knew it at the time. It wasn't necessarily that the developer led go to market was so good. It was that we were under invested in distribution. And so that was, uh, a challenge we had to quickly fix. And we did over the subsequent years and have successfully figured out a much better integration between a product and developer led motion.

That is the beginning of how we get into the accounts that we get into. But then a sales led motion that really cements those accounts and enables us to cross sell and upsell over time. And so what I think we've come to realize is that with a platform and a developer first product and a developer first go to market, really the key is saying, how do we build certain of our products that we know are going to be developer lead developer, adopted developer bought?

And maybe that's it. Maybe that's the whole go-to market of that product is just the developers taking it. But you have to measure the right metrics. Separately. We're going to have other products that are developer led, but then clearly a sold product. And what's the difference? Well, chances are, if the price tag gets high, eventually with usage, you're going to want to have a mature business relationship with the decision makers, the purse string holders of the company.

I'll give you an example. Any developer can adopt a Twilio and send their first text message for, you know, a dollar text messages, the customer, you buy a phone number for a dollar, and the second message costs a penny. Um, so penny one, you can send your first text message, but when they launch a product that's built on top of that and it starts scaling and it's scaling globally.

The total bill to Twilio can grow. And once the bill reaches tens of thousands or hundreds of thousands of dollars in some large scale B to C company, We want the relationship to not end at that developer. We want the relationship with the C suite member or the CFO's paying the bills or the head of product.

Who's responsible for that thing because you better believe that when a company is spending that much on a vendor, they want to know the vendor and guess what we want to know them too. And so knowing essentially the full life cycle, how your product gets adopted, how it gets used, and then who the various stakeholders are as you become more and more strategically important to the company is really important.

And when we add a dozen quota-carrying reps, we just didn't have enough capacity to go talk to all of our customers. So the implicit assumption in that model was that. You know, they just would keep buying and they didn't need to talk to us. In fact, a lot of customers told us that they said, no, we're really happy.

We don't need to talk to you. We're good. And that, that was coming from the developers, right? Developers notoriously would probably prefer not to talk to somebody, but when the numbers started getting bigger, well, that's when actually you do want to have a relationship. You do want to talk to somebody.

Maybe it's not the developer, the half to actually build a relationship throughout the company. And so that's the first thing. If you're going to get to meaningful revenue with a customer, that's when you need to flip the relationship and actually build a mature B2B relationship with the company. But there's other products where they may not merit sales.

They may not need sales, but you also just want them to be kind of, self-service easy to use, easy to adopt and more secondary potentially to the customer's use case. So there's a lot of products that we've built that are infrastructure, API APIs that honestly our sales team. Does not understand. They're like, what is that thing?

And we're like, you know what? You don't have to worry about it. It's for the developer to use and we're helping developers get more jobs done and we're helping them make these four products easier, but we're not expecting you to go in and sell this thing. We're just expecting developers to buy it. And so knowing the difference between the products, if you've got a large product set, which we do, we've got, I think, 60, 70 products in our portfolio, knowing the difference, not treating them all the same has been another part of our playbook and making sure that we know what every product wants to be, and we know how it is going to be running.

So in that case, 

Brett Berson: [00:26:10] what was the process for you to figure out that your worldview, right small go to market team, 10 people at IPO was wrong. 

Jeff Lawson: [00:26:21] Well, it hit us in the face. When our, I think our third quarter as a public company, we had to disclose that one of our largest customers at the time was Uber. And that they were intending to use, not just one vendor, but they were intended to use multiple vendors for the services that we provide them.

So they had grown to be about $60 million annual account for us. Huge, enormous. I mean, for any software company, a $60 million account is enormous. Let alone for one that was relatively young, like we were, and they had grown like a weed, which is just a function of their growth as a company. And the thing was for the longest time they had basically said, you know, we don't really want to talk to your salespeople.

You know, the developers can say, no, we're happy. We're growing. And their mandate has been growth at all costs. You know, they were growing around the world incredibly quickly and we were supporting that growth. We're launching them in new countries all the time and helping them do that. Meanwhile, something changed inside of Uber where their mandate became less growth at all costs and became more about efficiency and suddenly their priorities became more about how do we save money as opposed to, how do we get into the new country and that never got to us.

Because again, we didn't really have a mature relationship with them. I'll put this into perspective. When we, we had only about a dozen sales reps, the rep who was assigned to Uber had also about, I think, about 50, 60 other accounts. So that rep would go visit Uber maybe once a year, is the customer paying a $60 million a year?

That was, that was wrong. You know, that wasn't, that was not the right way to approach that account. And so what I realized in that moment was that we had accepted the customer saying it's okay, we're fine. Just leave us alone and taken, uh, you know, we were trying, but like still a relatively laissez-faire attitude towards the accountant saying, no, no, no is in our interest.

And the customer's interest that we know what they're thinking and we know what they want and when their needs are, because we could have easily addressed those problems. We could have easily become more focused on cost for them, but that wasn't essentially what we have been told, or we did not allocate enough bandwidth to be able to hear it nor we'll be reaching into the right levels of the company.

For those people to say, actually, we've got a new priority. Can you help us with this? And so that was the wake-up call for us that somehow we had misallocated the resources of the company to truly support our customers and to do it at scale, we did, uh, a post-mortem actually inside the company to ask the question of like, well, what went wrong here?

Like, clearly something went wrong. If we had a customer this large and so impactful that when they had a change in their strategy, we had to inform our investors. It was a huge deal. So something went wrong here. What is it? We were a few root causes, but the main one we settled on was we just had insufficient coverage on an account that is that big.

They should have had their own sales rep and that all they did was service that account. And so that's when we started the process of right-sizing our go to market machine. And the interesting thing about our business model is even though we have really grown our distribution capabilities in the last several years, it hasn't fundamentally changed.

The economics of our business. Our developer led go to market is still extraordinarily efficient. Last quarter. We only spent 23% of sales on sales and marketing to grow the company. And more than 50% at 2 billion of ARR. And so I think there may have been a fear of like, oh, well, if we need more salespeople, maybe that ruins our business model.

But we had a lot of conviction that the developer model is so efficient that we could afford to run this as an experiment. And we didn't hire all the reps on day one. And we said, well, you know, the first thing let's go from 12 to 50 reps. And if we see a lot of efficiency and the business keeps coming along and we see a lot of growth because of that, then that'll give us the courage to keep going from there.

And that's exactly what we've done. 

Brett Berson: [00:30:07] I think this highlights an interesting idea, which is the general concept of good decisions and good outcomes, bad decisions, and, and good outcomes, et cetera, et cetera. Right? And that it's often hard to understand if a good decision caused a good outcome or a bad decision caused a good outcome.

And I'm curious, do you think about that all as a CEO? Like if you take the Uber example up until they shifted from growth to a more cost orientation, you might think of yourself as a genius CEO. This is the greatest CAC math that ever existed. We have a $60 million account. We spent zero on it. We spent almost zero on supporting it were geniuses.

And then 90 days goes by and it's like, oh, I guess that we had a good outcome in this case, but maybe the original decision. Wasn't fantastic. 

Jeff Lawson: [00:30:52] I don't think, I think that we thought of ourselves as geniuses. I think we, we did. See natural efficiencies in our business model. And I still do believe that that's true.

I think having developers as our biggest advocates inside of every company is a structural advantage that we have in building our business. However, we were kind of puzzled too. Actually we kept saying, it seems like we should be having a more mature relationship, but we had trouble actually getting in there.

We were kind of blocked almost if you will, at the developer. And there was just sort of this lack of interest in engaging because the developers are like, yeah, we built it. It's working great. We're going to, we're working on the stuff now. Like we're good. And we would try to actually mature the account, but there was just a lack of interest.

And I think that we accepted that too easily. So I don't think we said we were geniuses, but we did say like, huh, I'd imagine, imagine that they'd want to have more regular contact, but okay. Like I guess not. And we accepted that outcome as opposed to saying, look, this really isn't normal. This isn't the way it should be.

And we got to figure out how to make sure that we build the relationship. Even if they think they're fine, it's in our interest and their interest to make sure we've got a mature relationship there. But the notion you set up there's good decisions, good outcomes and bad decisions. That's still net good outcome.

That's absolutely true. You know, people may bad decisions all the time and the results of those decisions are not immediately. Okay. Yes. If that was true, have no one in the world would smoke. Right? And so you have, I have to look at the outcomes that you get and not purely ascribed them to Greg decisions.

You've made either way the same as on the other side, when bad things happen, you don't immediately them to bad decisions you've made the world is full of a ton of luck. Well, what you want to do is continually try to draw the correlations between the decisions and the outcomes, even if they're imperfect.

And to me, that's the essence of a continuous learning environment. And one where you do a regular regime of postmortems, when things go well, or when they go not well. And it usually postmortems is the word you use to describe the things that don't go well, but we do them for when things go well, too. And I think that is the way in which you continually build this muscle of analyzing the outcome and asking what all of the inputs were, not just one decision, but all of the inputs were that led you there and try to do your best in the moment when everything's fresh in your head to learn and to capture knowledge.

So, yeah, I talk a lot about this actually in the book that I released earlier this year called ask your developer of how do you create a learning environment? And I talk about the post-mortem obviously a lot of engineering minded folks are accustomed to this notion of the five whys blameless post-mortem the site has an outage.

You don't blame the person who wrote the bog and deployed it to pride. Instead, you asked the question of, well, how did we enable a system where human being made a mistake, which by the way, is what human beings do we make mistakes? Every single one of us, how do we let a single mistake by a single human being actually take down our website instead of blaming that person for being a human being, you blame the system and say, okay, what do we need to do to make the system more robust?

But the interesting thing, a lot of engineers are accustomed to this idea of the five why's you get to the true root cause the root cause. Isn't the engineer who wrote the bug. The root cause may be the lack of testing you might ask. Why don't we have testing? Okay, well, we don't educate developers how to write good testing.

Okay. Or maybe we don't have a good investment in infrastructure to do testing. So it's too hard to write testings. So the incentives are misaligned. And when you get to the true root cause, then you can make systemic change. And so we do that not only in engineering cases, but we do it in other cases too.

So when we have that Uber situation with our investors, we did a blameless post-mortem and we got to the true root cause. The other thing that happens is we do this when things go well, like when we do signal our annual customer event immediately, like the whole company is exhausted. We just put on a huge event for our customers, thousands of customers.

And the next day, the event is usually like, you know, Tuesday and Wednesday and Friday, when everyone really wants to sleep in, we do, however, do one thing. We do a recap and we capture what we call worked, not worked. So what worked, what didn't work and we do it while it's fresh in our baby, easy for everyone to be like, all right.

And I'm taking the next week off. We just worked our butts off. But two weeks later, if we came back and did it, they would have forgotten a lot of stuff. So we do work, not work, we document it for posterity. And so when we start working on the next year conference, we can pull out the work, not worked and we've documented what we thought were the outcomes we liked, the outcomes we didn't like and what we thought were some of the decisions that went into that.

So that next year we could continue to make good decisions and avoid some of the bad decisions. We can continue to get the good outcomes and avoid some of the bad outcomes. And by doing that every year, you just get a little bit better. Our chief product officer chief shoe has a saying, he says every day, our goal is to suck a little bit less.

That was like that. It's very self-deprecating obviously, but it kind of expresses this idea that it's okay. Everything's not perfect. We suck at certain things, but if we just suck a little bit less every day, And we're building a stronger company as a result. 

Brett Berson: [00:36:05] Are there other things that if people came in and watched how you run Twilio, they might go, huh?

That's funny. Or that's weird or that's unique. I think the post-mortem on when things go well, might be one of those things. Are there others that come 

Jeff Lawson: [00:36:20] to mind? Yeah, I think some of the things we do are practiced elsewhere. Maybe not broadly. One of our values is write it down. And so we are big believers in the written word.

I worked at Amazon before starting Twilio and two things happen. Number one is the weakness of PowerPoint as a decision-making tool. And people often say, oh, what if you know charts and graphs? I, you know, you're supposed to write those out in words, like none of the charts and graphs can go into PowerPoint.

That's fine. But when you're sitting down to make a decision, how our point is a really bad way to communicate an idea, why? Because bullet points on a slide, destroy a lot of information. There's an information scientist named Edward Tufty, who wrote this white paper about how, uh, he was on the commission that I think investigated the Columbia disaster, the spacial disaster, and his conclusion was that PowerPoint killed the astronauts.

It's a fascinating paper if you haven't read it. And basically you said when the shuttle took off, they asked these engineers who knew the systems really well knew about the tiles, whether they should go inspect the tiles. And the engineers said, yes, this is a big problem. And the engineers handed it to their superiors and to theirs and through multiple layers of management, these PowerPoints went and every time the PowerPoints got abstracted with more information and the answer went from, yes, this is a problem to maybe it's a problem, could be a problem.

And by the time it got to the top brass at NASA was like not a problem. And it was because when you've only got six words to describe the title, we'll have a slide. You have to abstract a lot of complexity into a very few words. And that is a lossy format. And when you do that, multiple times ideas get lost.

And so the better way to communicate information is with the written word, because the interesting thing is human beings have been expressing ideas using pros for well verbally thousands of years and written hundreds of years. And we've gotten very good at it. We all learned how to do it in school, right?

We had to write essays Moby Dick, whenever we had to write all of our essays. And so we actually learned this skill through the course of our education. And for some reason, when you enter the world of business, that all gets thrown away, you got to ask, why is that? Why is it? We throw away things that human beings have learned over thousands of years, about how to communicate ideas and things that we spent more than a decade of our lives, learning in school only to throw it all away.

Once we enter the world of business and suddenly we should just look at a screen. The other thing that happens is that the act of writing and communicating this document is very useful for the author, because it's really hard to write a narrative. Essay explaining an idea. If you don't have intellectual clarity yourself, it comes very clear while you're writing it.

And it's very clear when you're reading it. Meanwhile, a PowerPoint presentation, it is easy to BS your way through. Everybody has made the PowerPoint like that, right before the presentation, you're like, oh crap, I gotta do this. PowerPoint, throw together some slides and just talk your way through it. It is easy to do that without having intellectual clarity.

Yet it is very hard to write a narrative essay when you don't have intellectual clarity yourself. In fact, the act of writing it is clarifying. There's been a bunch of times where I've thought I've had a great idea and I sat down to write it. And in the act of writing it and developing that mental clarity, I come to realize that in fact, that is not as good as I thought it was.

And I said, nevermind. And so the act of writing it as better, the act of communicating it is better. And so the written word is something that we are pretty religious about it Twilio, because I believe it leads to better decisions. The other thing I'll say is one of our other values is ruthlessly prioritize.

And in the early days of Twilio was very interesting. Every year. At some point we started writing an annual plan and it was actually a written document. It was like a six page document. That was the plan of what we were going to do. And the document would say basically as a quick synopsis of our business at that time.

And it was okay in the coming year, we're going to do a, B, C, D E F G, blah, blah, blah, all this great stuff. And I remember at one point I hired an executive who joined and I gave our annual plan that year to that executive. I said, here's our plan for the year? And this executive read the plan. He said, okay.

Yeah, it was very, very nice, a lot of neat ideas in there. But the thing I don't understand is actually, which of these things are like, do we have to get done? Which were, these are nice to get done, which of these are just ideas. It's kind of not clear. And I said, huh, that's interesting. And I took that feedback and I thought about something else that it bothered me.

And in fact, one of the things that bothered me about Twilio was that as an executive team, we never actually argued. Which is a strange thing to bother a CEO. We don't argue enough. It's something always felt not quite right to me when we always agreed. Right? It's like, well, clearly we must not be making good enough decisions if we all agree all the time.

And what I came to realize was that the reason why we didn't argue is we didn't have to argue when you don't prioritize. One person says, I like idea a and the other person says, I like idea B you say great. Put them both down. We'll do it all. And in fact, when you look back on those documents at the end of the year, we rarely got very much of anything in those documents actually done.

In fact, one of the biggest mistakes we made early on it was, I, you know, I can't remember like 2013, maybe 2014, somewhere in there. He said you don't one of the hardest things for companies to do in this is hire engineers. And so we told our RNs D group, we said, you have no limits on your budget. You can hire as many engineers as you're able to actually hire and onboard because we thought this was a great way to tell people recruiting and all this it really needed to focus on.

And guess what? It turned out. It turned out the. The team that got the most budget and the team that was defacto prioritized over everything else was the team that happened to have a hiring manager was particularly good at hiring. It wasn't even intentional. It just happened to be that hiring manager was great.

Therefore that team hired a bunch of heads and it turns out that that was our priority for the year, I guess. And so what we realized is along with prioritization, so debating, not just all the things we could do, but the order of importance, which is first, which is second. Now you get disagreements and then you make your budget, follow your prioritization.

One of the other phrases that comes up at Twilio quite a bit, which is sort of ingest, but it's really true is that your budget is your priorities. So first decide what you want to get done, debate it, argue it. And once we started ranking our priorities, now you saw a lot of vigorous debate, healthy.

Deciding what is more important than what? Then you go through the act of making your budget, follow your priorities. And once we started doing that, we started accomplishing a lot more and having more clarity in what we wanted to get done. So prioritization, write it down. 

Brett Berson: [00:42:53] A couple of things that sort of come to mind first.

So what is your planning process look 

Jeff Lawson: [00:42:58] like? I've never met a CEO who likes their planning process. In fact, I've talked to a lot of other CEOs about this and everyone's like, yeah, I hate mine. What do you do? So I'll caveat with, it's always a work in progress. Our planning process has multiple stages. Uh, we typically around mid-year do something.

We call an LRP, a long range plan. And the purpose of that is to realign with our major leaders in the company. What our plan is over the five to seven year horizon that we're building for. Then after we've aligned on that teams go back and put together their next year plan. And it's really it's next year.

It's like 12 to 18 months actually, what it is they want to accomplish. And the format for that document is what we call a BPM. And this goes along with sort of an annual plan, which is like a written narrative and the BPM stands for big picture priorities measures. And we created this as a, more of a shortcut because it is difficult to read the full like six page decision-making document as a way of checking in on progress.

So we create the abstraction, which is a BPM. It's a big picture is what that group or that team or that division or whatever it is. And we write one for the whole company too, by the way, what we want to accomplish over the five to seven years that are ahead of us big picture. And it's usually two to three sentences below that are the top, usually five to 10 priorities.

What's most important in order. Or how we're going to accomplish that big picture and what do we need to do? What do we need to prioritize over the next 12 to 18 months in order to get there? And then below that are the measures. The measures just are the markers that tell us, are we making the progress we want to make towards these priorities?

And what's interesting about this is most companies use OKR ears. And the thing that I've noticed about, okay, ours is really two things. First of all, the objectives aren't prioritized in most companies. So you get that problem of well, which is more important than which that Omar's don't solve for you.

And the second thing is I noticed that most companies, the energy of okay hours and we use ocairus by the way, before we did the BPM process, the energy of, okay, ours is really around the key results. Everybody gets very focused on the metrics. And I actually think the most important part of our BPM is not the measures.

It's actually the priorities, because the priorities communicate what I call the commander's intent. What do we really want to happen in order of priority? The measures in some ways are just an outcome because what you measure should be reflective of what it is you're trying to accomplish. And oftentimes people get so focused on the measures.

They lose sight of the forest here of what are we actually trying to do. And so the priorities are actually the main way that we communicate inside of Twilio. What it is our plan is for the year. And then those parties should be supportive of the big picture. And the measures are actually in my opinion, the least important part.

Cause they're not very strategic. It's like, oh, you have to figure out how we're going to measure it. Of course. But those are just the measures that tell us if we're on the right path, charting, the right path is actually the hard work. Can you give an 

Brett Berson: [00:46:10] example or do you remember back a year or two ago, an example of how that weaves together or here's an example of a good or bad priority or that type of thing to give it a little bit more definition?

Jeff Lawson: [00:46:20] Yeah. I'll give you an exact, there usually are BPMs aren't made public, but one of them we did actually make public BPMs are a useful tool for not just say annual planning, but also when there's something that arises, that requires clarity of thought and alignment, BPMs can be a great tool to actually drive that clarity of thought and alignment.

So we have used BPMs, not just for the divisions of the company or the teams. And we do this all the way down to the team level. But for example, signal our annual customer conference. I remember at one point there was like this question, what is the goal of signal? We got a lot of developers that are increasingly, we've got C-suite executives at enterprises there.

It's getting really confusing. Who's the customer for signal? Is it a business conference? Is it a developer conference? So let's write a BPM. That's right. A big picture. Why are we even doing a conference? Let's write our priorities. What do we want to get out of it? So that's one example, but we also ended up using our BPM process.

It's a process to write the BPM and it's a communication vehicle outcome when COVID began or when it became clear that COVID was gonna be very impactful to our business and society and everything else. Last March, there was so much confusion. There was so much like there's activity. We had to shut offices.

Nobody knew much about the virus and it was so much going on. What we said was, okay, let's write a BPM to clarify what it is we're here to accomplish. Let's take a lot of the confusion and the fog of the situation. Let's try to clarify for ourselves what we're here to do. So we wrote a BPM and the big picture.

I don't remember all the details off the top of my head, but the big picture started with essentially this idea that we want to emerge stronger from this pandemic crisis. That's the big picture. Then we start to talk about the priorities and we actually had priorities that said priority. Number one was ensure the health, mental, and physical of our employees party.

Number one, party, number two, support our customers through what is going to be a very trying time in their businesses. And then the list went on. And as we wrote this document, there was a lot of debate. Oh, is it customers first? And then employees, or is in place first and then customers. And a lot of questions that came out from that and where we landed was like, look, if we don't take care of our people, you know, we often say, oh, people are the number one resource of a company.

They're the most important part of the company. If we don't actually think about our people first during this, there are time of great need and uncertainty, and everyone's scared, obviously we're not gonna able to emerge stronger. So we put our people first and then we said, okay, and our customers, some of our customers.

They're going to see massive disruptions in their business. So how good of a partner we are during this time will be the indicator of how good of a customer they are after the pandemic and other customers of ours, like their businesses, probably going to take off because of the pandemic. So again, how good of a partner we are during this will indicate how good of a customer they are down the line.

We use this process to clarify, what are we here to do in an order part is not told us like if there was a customer who really needed something and we were making extraordinary asks of our team and they weren't able to fulfill on it because of the stresses of a pandemic, we would have to say, I'm sorry, customer, because our number one priority is our people and they can't do it right now because of whatever issues are going on.

And like, while that's not what you want to ever have to say to a customer, when push comes to shove, we did have a document that told us and told our teams how to prioritize. And so I think that was like a moment where BPM served us really well, because we could communicate that out to our employees and all the managers in the company, because the demands on them didn't go down because of the pandemic.

They went up, we had customers, you know, they were reconfiguring on the fly. They were building new things. Other customers were scaling like mad. And there were a lot of demands on our teams and we've told managers, look, you really have to listen to your employees. We are here to succeed. We're here to emerge stronger, but the only way we're going to do that is if you listen to your employees, when they're saying they are really struggling and we all know everyone has struggled a lot during this pandemic, you need to hear that.

And if the company is asking too much of you and your team, we want you to surface it. Cause we need to moderate things to make sure our employees mental and physical health is the number one priority. And I think that really did help our employee engagement went up massively during COVID while we achieved amazing growth.

And we succeeded in supporting our customers. But I think if we'd taken an opposite approach, there was a much greater chance that our employees would have burnt out or had other very bad outcomes based on if we had not prioritized our employees first. And so that's an example of where that was a real debate inside the company of what matters more than what during a pandemic, because none of us had been through this before there, no playbook for it.

We had to invent it and BPMs were a tool that allowed us to write that playbook in real time. 

Brett Berson: [00:51:16] Surfaces and idea that I'm always curious about, which is as a CEO, do you have a mental model or framework for how you think about adopting best practice way to do something versus invent or sort of rethink it or do the opposite?

It sounds like you were. Given your early career at Amazon were influenced by the writing culture that they had established. And you chose to bring that into your company. And I'm sure there are other things that you go back to first principles and don't adopt the way another company does sales comp.

Or do you think about when to adopt best practices versus invent or do something differently, or that tends to be just 

Jeff Lawson: [00:51:55] more organic? I think you need to have some degree of wisdom and understanding what matters and if it matters, therefore being more inventive is probably more important. And if in the fullness of time, it doesn't matter, then maybe that's an area where you don't need to spend the energy.

I'm not a believer and you need to innovate all the things all the time. You need to decide where it matters. And so like a good example of this, I had a number of investors, you know, we went public in 2016 and in the subsequent years, direct listings have gotten much more prominent. And the promise of direct listings is usually in the IPO.

There's a pop between the price at which you offer the stock. And then the first trades that occur now, pop can be 20, 30, 50%. And that could have been money that the company took in as opposed to handing it to your IPO investors. And so there's a lot of allure of saying, Hey, all the companies are not getting the short end of the stick and these IPOs and yeah, that's probably true.

I mean, I think it is true. Right. And I had a lot of investors reach out to me because direct listings were just starting to get traction right after our IPO. And they asked me like, you have regrets, do you wish you'd done a direct listing? My answer was honestly, no, I get it. It's inefficient investors and bankers make more money than maybe they need to.

But an IPO is an event we do exactly once in the lifetime of the company. Therefore, do I need to optimize it extremely and actually go wrap my head around a brand new model and do a lot of work around that. Or am I okay saying, you know what, it's imperfect, but we're going to do it exactly once. So once we do it, we never have to do it again better for, it's fine.

If it's not optimized. Like that was my approach to it. So my answer to those investors was actually, I don't really care that it was not optimal because I never have to do it again. But if it's something, if it's a process or an idea or something, your customers experience or something that you do a hundred times a day or a million times a day, it's like, well, that's a good area where you should go optimize and you should go figure it out from first principles, because it's a repeatable thing that your company does all day every day.

And if you get better and better and better at it, and you know, the principles that are driving that improvement, then you are going to be in a much better competitive stance and you're going to build a stronger company. And so I tend to think about things that way. The other way of thinking about a principle that we've started talking about quite a bit at Twilio is we need to get better as we scale.

So what does that mean? Right. As companies get bigger, the natural entropy of the universe wants to make the company shittier. There's more chaos. There's more, decision-making, there's more divisions, there's more politics. There's all this stuff that creeps in. Like the universe wants things to companies to get worse as they grow.

And we as customers, we experience this all the time. Companies kind of lose their edges. Yeah. Great companies use their scale to their advantage. They get better with scale, oftentimes because they've invested in software and really good automation to make it so that this repetitive thing that we do, we are making it and we're codifying it in software and we're improving it in iteratively, applying the agility of software and the continuous improvement mindset to take this thing that we do a thousand times a day and everyday make it a little bit better instead of, oh wow.

It got worse because it's really confused because the org chart got bigger and all this sort of stuff. And so one of the things that I think where companies should. Invest energy and where we're investing a lot of energy in Twilio is this idea that you get better as you scale, because if you don't say it and you don't focus on it, you don't make it a goal.

Chances are things get worse as they scale because that's just the nature of the universe. So being very conscious about that is a goal of ours, both in terms of using software intelligently organizing into small teams, they always keep the company operating like a bunch of startups, putting the customer at the center of what you do.

And I think if you take those ideas and put them together, you end up with a more holistic system for how as the company gets bigger, you still keep that startup culture that startup focused on customers and the energy and the drive to serve customers, as opposed to the things that take over in many large businesses, which is, you know, more focused on the org chart and the walls that arise and all the complexities of the org chart.

Why do you think that 

Brett Berson: [00:55:58] is. The statement, continue to focus on customers, autonomous teams, et cetera. I don't think if you told most CEOs, if you shared those ideas, no one say, well, that's stupid. You know what I want to come in. I want everybody arguing over their fiefdom. I want everybody focused on themselves, but yet to your point, it's like a law of the universe and happens over and over again 

Jeff Lawson: [00:56:20] over again.

I always think about it this way. You think about the early days of a startup in the early days of a startup, like when Twilio was five people in any given day, I might be writing some code architecting, some new idea, doing customer service on a sales call with a prospective customer and paying the bills and doing a Costco run.

It's like, you're doing all of the tasks. You can hold the whole picture in your head. You can really think about the long term. You really close to those customers. Why? Because you probably spoke to a bunch of them today and you can execute quickly and decisively because there isn't a lot of complexity.

It's all right there in your head. And as a company grows, what happens is people specialize. And so obviously you're going to hire a customer support team to go do customer support and specialize in that. And you're going to hire salespeople to specialize in selling, and you're going to hire all these functions, whose job it is to specialize.

And look, that is great. You need specialization, but executed to perfection. What you've done is told everybody to keep their heads down and focus on essentially the one thing that they do, meanwhile, the customer gets very lost in that world and it becomes very impersonal. It's like, well, you know, I'm a developer.

I write code from a spec that a product manager wrote and this product manager wrote the spec because they talked to the sales team who talked to a customer and it's like, everything is very hearsay oriented in encourages you to just take the passion out of it and dispassionately do a job. As opposed to really having proximity to a customer, understanding why you're there and executing like you do in the early days of a startup, being able to keep the whole picture of what you're doing, why are there in your head?

And the reason you can do that when you're a startup is because things are small because the people you work with, it's a small group of people can't get too far from a customer because the people who are working with customers, even if it's not you, the person price sits right next to you. If it's like the sales person or the support person.

So scale introduces a lot of walls that are well-intentioned, but they serve to separate out the tasks. And therefore actually insulate most people from the customer in silo, people from the mission they're there to accomplish. And so at Twilio, we organized into small teams and each team is defined by three things.

A customer that they're there to serve. That could be an internal customer, an external customer, but be explicit, say it. Who is the customer, a mission? What are they there to accomplish for that customer? And the metrics that tell you if you're actually succeeding in serving that customer. And once you've developed a customer, a mission and metrics for a team, now that team is pretty free to sprint and to serve that customer.

But I think it's when you don't have clarity of the mission, you don't have clarity of the customer and you don't really know what the metrics are. That's when it becomes dispassionate. And you're like, well, you know, I'm here to stamp this piece of paper every day. It becomes a little more like, uh, clerical work.

And, um, and that's where people lose sight of ultimately what you're here to do. And that's what we strive to do. And it's imperfect, you know, we're always in the process of improving that and, and, you know, reformulating our teams to make sure that they have clarity around customer mission and metrics.

And we have to continually subdivide the company as it grows, right. The teams get big and they can start to lose focus. So we've got to redivide them again. But ultimately the way we as executives organize the company in this way to make sure all the things that our customers need us to do are owned by one of the frontline teams and empower those teams and make sure they've got the best talent and make sure they have the clarity of focus.

That's ultimately how we can serve our customers at scale. And if we're able to continually recreate the conditions of a startup, even at scale, that is I think what makes the best companies. 

Brett Berson: [01:00:02] I thought maybe we could just end by just talking a little bit about the people that have had the biggest impact on the way that you think about your job as a CEO.

When you think about the last 13 years, are there folks that have had outsized impacts or delivered the most aha moments to how you think about your role when you're wearing the 

Jeff Lawson: [01:00:20] CEO hat? The biggest thing say about wearing the CEO hat is you have to continually reinvent your job. If the company is growing, the needs of the company will change continually throughout the course, right?

The, the things that you did as a CEO and how you internalized your job and what the company needed from you at five people is different from 15. People is different from 50 is different from 150 and so forth. And so you have to be prepared to really rethink your job every 12, 18 months. And, you know, what I found is that things just kind of stop working the way I did it last year.

It doesn't seem to be having the same impact as this year. Okay. It's time to rethink that. And so I've had a number of, of people who been influential. I think one person will Albert Wenger from union square ventures. One of our first board members, sorry to mention a competitor. All I will say first round had their chance to do our seed round, you know, postmortems.

Brett Berson: [01:01:10] The Royal screw up that we made is one that we describe a lot. And I vividly remembered that the conversation it was either, I think it was oh eight. Yep. And it was all about market size. That is a great example of how we postmortem and have learned a tremendous amount about how tricky it is to figure out what market sizes in that case.

Jeff Lawson: [01:01:31] I think the lesson here, and I think the world of all the partners at first, John, that's why I really wanted to work with you guys. But I think one of the lessons to internalize for a startup CEO is the first investors you pull on, especially those that become your board members. They can be really influential in how you navigate that job and how you think about the job.

And there's a lot of wisdom from them. Having worked with a lot of other CEOs through many stages that can really help you through those things. And like, one of the things that Alberto is encouraged me to do is to keep maximum future optionality available to me into the company is that goes into how you fundraise amazing, like the valuations you raise money at.

And like there's a lot of things. Yeah. You can do as a CEO that actually close off avenues for the company. And I always thought about how do you not close off potential futures from the company? I keep every option available to you, but I will also say there's other CEOs that I've learned a lot from and in particular there's two.

And the interesting thing is they couldn't be more different from each other. One is basis. The other is Benioff and these are two extraordinary CEOs, but very different. Couldn't be more different basis is completely intellectual. And Amazon as a culture is a very intellectually correct. Environment, thus you get the written word.

Um, you get a lot of analysis. They're very rigorous in terms of making good decisions, but also very quick to make decisions. And you like you read basis, his annual shareholder letter. There's so much wisdom in there. It is a very intellectual environment. The company is a capitalist machine and you don't get, I get the sense that there's a tremendous amount of heart.

The idea I think of Amazon is like it's capitalism at its finest and it's there to make money. And then society generally is better when there's more wealth creation for employees and other stakeholders. And that that's its contribution to society. Meanwhile, Benioff is a very different point of view.

He's like all heart, you know, and it's like, you build a company, but one that is doing good around it's one that is positively impacting community in society, around you. One that really cares about its role in building a more just and equitable world and using the vast resources of a corporation to do good.

And Benioff spends a lot of time on that. Meanwhile, I don't get the sense that Salesforce is as like intellectually driven as say an Amazon and what I've sought to do as both the CEO and in building Twilio is to try to take the best of both worlds. Can we have a company that is intellectually rigorous in making good decisions while having a huge heart and really investing in our communities and society around us to make really good ethical decisions.

And I think if we could take the best of both of those companies, like the intellectual rigor of Amazon and the giant heart of Salesforce and that's the company I want to lead, that's why I've thought about 

Brett Berson: [01:04:18] it. That's a great place to end Jeff. Thanks so 

Jeff Lawson: [01:04:21] much for the time. Absolutely. Thank you, Brad. It's been great to be here.