Several years ago, Twilio CEO and co-founder Jeff Lawson unpacked his granular approach to creating company values that stick, right here on The Review. When you give it a re-read, values like “Draw the owl” and “No shenanigans” stand out as unusual choices.
That unconventional streak paired with a fresh take on oft-overlooked company building processes is something of a theme in Twilio’s story. Consider back in 2008, when it seemed as though the company was swimming against strong currents of accepted startup wisdom. “We got a lot of advice from people saying that developers aren't an audience and nobody knows how to do that go-to-market, we should go build an app instead — you can always add an API to an app, but APIs can’t be a business,” says Lawson.
But 13 years — and a successful IPO — later, Lawson’s seen his bullish bet on developers being influential buyers bear out. Of course, the API economy and bottoms-up self-serve strategies have since reached critical mass, but they were still untested waters in Twilio's early days. “Some of our first customers were Intuit and Sony — and it was the developers who had brought us into those relationships very early on,” says Lawson. “If we had waffled on who our customer was or tried to serve multiple different customers, I think we would have had a very different outcome. We knew who we were, we knew what we wanted to be, we had enough evidence that that was correct, and we stuck to our guns.”
This illustrates a classic conundrum — founders and CEOs are threading a delicate needle between approaching problems with first principles thinking and pulling from well-established playbooks. “I’m not a believer that you need to innovate all the things all the time,” he says. “If it matters a great deal to your business, being more inventive is probably more important. If it's a process or something that you do a hundred times a day, that's a good area where you should go optimize and 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, you're going to build a stronger company."
That sentiment also stands out as a theme when you talk to the repeat founder. "One principle we've started talking about quite a bit at Twilio is how we need to get better as we scale," says Lawson. "Companies should invest energy in this idea because if you don't say it and you don’t make it a goal, chances are things will get worse as they scale because that's just the nature of the universe."
As companies get bigger, the natural entropy of the universe wants to make them shittier. There's more chaos. There's more decision-making. There's more politics. But great companies use their scale to their advantage.
“Being very conscious about that is a goal of ours, both in terms of using software intelligently, organizing into small teams, and putting the customer at the center of what we do,” says Lawson. In this exclusive interview, he reflects on the key unconventional lessons from the past 13 years of Twilio’s journey to do just that — including some of the company’s most critical peaks and valleys and his own evolution as CEO.
He details some initial wins, like continuing to buck trends by launching a second product in the early days of the company, but also candidly talks about the hard-won lessons, like when one of Twilio’s biggest customers significantly scaled back its investment and they had to reassess their go-to-market efforts. Lawson also makes the case for why executive teams should argue more, why metrics are the least important part of annual planning, and why post-mortems are a helpful tool even when things are running smoothly.
It’s a unique peek behind the curtain at one of the most quietly fascinating companies and CEOs around — company-builders across all industries and growth stages, as well as folks who have hopes to someday occupy these same seats, will find heaps of inspiration to pull from his playbook. Let’s dive in.
For more of Lawson’s thinking on these topics and many more, be sure to pick up a copy of his recent book, “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century.”
LESSON #1: WORRIED IT’S TOO SOON TO LAUNCH A SECOND PRODUCT? FOLLOW YOUR CUSTOMERS OFF THE BEATEN PATH
Twilio Voice launched as the company’s first product in 2008, which enabled customers to make and receive phone calls with API requests — and it was quietly picking up steam with $300K in ARR. And while there were plenty of oft-repeated startup maxims Lawson remembers hearing at the time, like “find a niche, get rich,” the company’s next move swerved off this well-tread course.
“Very quickly after launching Twilio Voice our customers started saying, ‘Could I also send and receive text messages with this Twilio number?’ So we started researching, and at the time it really wasn’t available in the market,” says Lawson. Instead, large enterprises would get provisioned by a carrier in a lengthy approvals process, followed by spending tens of thousands of dollars each month.
“While we kept building our voice API, we started working in the very early days — when the company was probably less than 10 people — on product number two. We brought the cost and the barriers of entry for building an app with text messaging from thousands of dollars and months of approvals to 30 seconds and less than a dollar to buy a phone number and send your first text message,” he says.
It’s a bet that paid off in a big way — Messaging is now the largest product in Twilio’s suite (one that has since expanded to what Lawson estimates today is 60-70 products). “We could have very easily said, ‘Look, we have this brand-new product. It is just getting off the ground. We've got a lot of work to do before we think about product number two,” he says.
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.
LESSON #2: THINK IN HORIZONS SO YOU DON’T FOCUS TOO MUCH ON THE CORE BUSINESS — OR SUFFER SHINY OBJECT SYNDROME.
While there are lessons in that experience of launching a second product quickly, there was also a flip side, says Lawson. Now with two products in the product suite grabbing customer attention, Twilio set off to find their next big hit. “We launched our SMS product and it was growing really nicely. The company was 10 or 20 people at the time — 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,” he says.
“That was a mistake. We should have said, ‘Okay, we got a hit here — we’ve got to double down, we've got to invest in it, we have to resource allocate ourselves well. But we didn't do that.”
Some early Twilio employees said, “Hey, we keep chasing the shiny things,” which was true. We made some mistakes in not intentionally investing more in the core product that was winning.
You need a balance of both — and a framework is helpful to ensure you keep investing in your core business, but don’t let that suck up all the resources of the company, says Lawson. “We used a number of frameworks over the years, including the horizons framework. 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 a dollar five years from now,” he says.
“So if you don't ring-fence off some amount of resources — conventional wisdom is 5-10% — into investing in the thing that you think might make you money five years from now, then you're probably running the company for too short-term of an outcome,” says Lawson.
There's no shortage of things customers need, and there’s no shortage of wisdom that says you need to invest in keeping your cash-cow core business going — you have to balance both.
LESSON #3: STRIVE FOR EXPERIMENTS, NOT BIG BETS, AND FUND THE BOATS, DESPITE WHAT THE CALENDAR SAYS.
But “the next big bet” is one phrase you won’t hear if you sit in on a meeting at Twilio. “We don’t think about things as the next big bet, because I think that you need to have five or 10 or 20 bets,” he says.
Here’s why: “In the early days of those ideas, it's really easy to get married to the next big thing and all run towards it. Instead, you need to think that there are 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,” says Lawson.
“And so as we got more scale at Twilio, we started to think about how to run a number of those experiments at any one time. There's a certain wisdom and discipline in being able to run multiple of those experiments — to be patient and to not expect those things to become giant businesses overnight,” he says.”Treat it as a learning exercise, not yet a business exercise measured in dollars and cents.”
As founders struggle to master the juggling of multiple experiments and shifting their mindset when it comes to outcomes, it’s easy to overlook the part that comes next: what to do when it’s not a swing and a miss, but rather a base hit. In Lawson’s experience, putting more firepower behind the bets that seem to be taking off is trickier than it might sound.
“One of the common mistakes that we, and I'm sure other companies, have made is that you fully allocate your budget at the beginning of the year. You’ve got five people working on one idea, five working on another, and one of those things is just taking off. And when they ask for more resources leaders often say, ‘Well, it’s April, we do budget allocation in December, so we’ll talk to you in December.’ What a great way to starve an idea because of an arbitrary budget cycle on your calendar,” he says. “You need to hold back but be prepared to invest when you see the signs of success and the idea merits that investment.”
You’ve got to send people out in different boats to explore new ideas, but when you see the signs of success, make sure you’ve got the ability to double down in real-time on the winning boat.
LESSON #4: IF YOUR EXEC TEAM ISN’T ARGUING, YOU’RE NOT PRIORITIZING.
Lawson implemented an annual planning process that in the early days seemed to be working just fine — but a new exec unlocked an aha moment that deeply altered how Lawson interacted with the C-Suite. “I remember at one point I hired an executive and I gave him our annual plan to review. And this executive read the plan and he said, ‘Okay, a lot of neat ideas in there. But the thing I don't understand is which of these things do we have to get done, which of these are nice to get done, which of these are just ideas? It's not clear.’ And I took that feedback and I thought about something else that had bothered me,” says Lawson.
He came back with a plan to stir up more debate within the walls of the C-Suite. “As an executive team, we never actually argued — which is a strange thing to bother a CEO. But in fact, something always felt not quite right to me when we always agreed. Clearly, we must not be making good enough decisions if we all agree all the time,” he says.
“What I came to realize was that the reason why we didn't argue is we weren’t prioritizing. One person says, ‘I like idea A,’ and the other person says, ‘I like idea B,’ and 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 around to very much of anything in those documents,” says Lawson.
He sketches out an example: “Around 2014 we decided that one of the hardest things for companies to do in this environment is hiring engineers. And so we told our R&D group, ‘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 that recruiting was what they really needed to focus on,” says Lawson.
But the scales quickly fell out of whack. “It turned out the team that got the most budget and the team that was de facto prioritized over everything else was the team that happened to have a hiring manager who was particularly good at hiring,” he says.
The lesson? Be vigorous not just about what makes the list, but the specific order in which priorities fall. “We realized it’s not just about all the things we could do, but the order of importance — which is first, which is second. Now you get disagreements and a lot of vigorous, healthy debate,” he says.
One of the phrases that comes up at Twilio quite a bit is that your budget is your priorities.
LESSON #5: METRICS ARE THE LEAST IMPORTANT PART OF YOUR ANNUAL PLAN.
With the caveat that he’s “never met a CEO who full loves their planning process,” here’s how Lawson approaches annual planning at Twilio. Each team creates what Twilio calls a BPM — which stands for big picture, priorities and measures. “The big picture is 2-3 sentences about what the team wants to accomplish in the next 5-7 years, aligned to what the leadership team has sketched out in our long-range plan. Below that are the top 5-10 priorities. What do we need to prioritize, in order, over the next 12-18 months in order to get there? And then below that are the measures. The measures just are the markers that tell us if we're making the progress we want to make towards these priorities,” he says.
And while there’s parallels to the traditional OKRs, Lawson points out a few potholes he’s keen to sidestep. “The thing that I've noticed about OKRs is the objectives aren't prioritized in most companies. At most companies, the energy of OKRs 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 the priorities,” he says.
Metrics are, in my opinion, the least important part of an annual plan because they’re not very strategic. The metrics tell us if we're on the right path. But charting the right path is actually the hard work.
LESSON #6: EVEN IF YOU’RE PRODUCT-LED, START BUILDING YOUR GO-TO-MARKET MUSCLES BEFORE YOU NEED THEM MOST.
Between Twilio Voice and Messaging, the company had struck gold twice with what Lawson admits wasn't a particularly strong go-to-market plan. “If you listen to folks giving startup advice, they say the classic mistake that especially engineers make is they assume the thing they've built is so amazing that if you build it, they will come,” he says. “So we got away with what essentially was an 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 and we didn't know what to do because we had never built that muscle.”
The company slowly started bulking up later in life, but their salesforce remained significantly smaller than what you might expect — Lawson estimates that the company went public in 2016 with just a dozen sales reps supporting around $200 million in revenue. “It was very strange, even though we didn’t know it at the time,” he admits.
“It wasn't necessarily that the developer-led go-to-market was so good, it was that we were underinvested in distribution. So that was a challenge we had to quickly fix. And we did over the subsequent years and have since successfully figured out a much better integration between a product- and developer-led motion that is the beginning of how we get into accounts, and then a sales-led motion that cements those accounts and enables us to cross-sell and upsell over time.”
But before that fix came some painful learnings, says Lawson. First, some context to set the scene: In a classic bottoms-up SaaS motion, any developer can adopt Twilio for a dollar and send text messages for pennies. But when they launch a product that's built on top of API and the product starts scaling, the total bill can grow to tens or hundreds of thousands of dollars, especially in some large B2C companies.
“When we added 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 they would just keep buying and they didn't need to talk to us,” he says. It was a reasonable assumption — developers notoriously would probably prefer not to talk to somebody, and in fact, a lot of customers told them as much, says Lawson. But when the bill begins getting bigger, that dynamic starts to shift.
That was a lesson that “hit us in the face,” says Lawson. “One of our largest customers was Uber, and they had grown to be a $60 million annual account for us — which is enormous for any software company, let alone one that was relatively young like we were. They were growing like a weed." Twilio was supporting that massive global growth but was disconnected from Uber’s decision-makers.
“For the longest time, they were basically saying they didn’t need to talk to our salespeople, that the developers were really happy,” says Lawson. “We didn't really have a mature relationship with them. I'll put this into perspective — the rep who was assigned to Uber also had I think 50-60 other accounts. So that rep would go visit Uber maybe once a year for a customer that is paying $60 million annually.”
And while the CAC math may have seemed remarkable at the time, it would introduce plenty of headaches later. “Meanwhile, Uber’s mandate became more about efficiency — and suddenly their priorities became ‘How do we save money?’ as opposed to ‘How do we get into a new country?’” As a result, in just its third quarter as a public company, Twilio had to disclose to investors that Uber was intending to use multiple vendors, not just Twilio, for the same service.
The learning for Lawson? “That wasn’t the right way to approach that account. We accepted it too easily. We were trying, of course, but it was still a relatively laissez-faire attitude. Even if the customer thinks they're fine, it's in our interest and their interest to make sure we've got a mature relationship, that we know what they're thinking and we know what their needs are,” he says.
“Because we could have easily addressed those problems. We could have become more focused on cost for them, but we didn’t allocate enough bandwidth to be able to hear it nor were we 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 big 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.”
The company went through the process to right-size the go-to-market machine — starting gradually with upping to 50 sales reps. “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 at more than 50% at $2 billion in ARR,” says Lawson.
“What we've come to realize is that with a platform and a developer-first product and go-to-market, really the key is building certain products that we know are going to be developer-led, developer-adopted, developer-bought and maybe that's it — maybe that's the whole go-to-market of that product. There are products that may not merit sales, and are more self-serve, easy to use, like infrastructure APIs,” says Lawson.
“But if you're going to get to meaningful revenue with a customer, that's when you need to actually build a mature B2B relationship with the company. And so knowing the full lifecycle of 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 customer is key.”
If you've got a large product set as we do, knowing the difference between the products and how they’ll be brought to market — and not treating them all the same — is a key part of the playbook.
LESSON #7: LEAN ON POST-MORTEMS WHEN THINGS GO WELL — NOT JUST WHEN YOU’RE THROWN OFF COURSE.
When lessons are learned the hard way, it’s a good time for introspection and team-wide reflection to fully capture what went wrong. “I talk a lot about this actually in my book — obviously a lot engineering-minded folks are accustomed to this notion of the ‘five whys’ of blameless post-mortems. If the site has an outage, you don't blame the person who wrote the bug and deployed it to prod. Instead you ask the question, ‘How do we let a single mistake by a single human being actually take down our website?’” he says.
“And instead of blaming that person for being a human being, you blame the system and you get to the true root cause. The root cause may be the lack of testing. You might ask, ‘Why don't we have testing?’ Well, we don't educate developers on how to write good testing. Or maybe we don't have a good investment in infrastructure to do testing. And when you get to the true root cause, then you can make systemic change,” he says. “When we had that Uber situation, for example, we did a blameless post-mortem and got to the true root cause.”
Lawson’s seen plenty of companies leave post-mortems behind when every piece falls into place — but he’s a big believer in flexing these same muscles, even when things go well. “Usually post-mortems is the word you use to describe analyzing the things that don't go well, but we do post-mortems when things go well, too,” he says. “That is the way in which you continually build this muscle of analyzing the outcome and asking what 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,” he says.
There are good decisions that net good outcomes and bad decisions that still net good outcomes. People make bad decisions all the time and the results of those decisions are not immediately obvious. So you have to look at the outcomes that you get and not purely ascribe them to the great decisions you've made.
Here’s an example: “Signal is our annual customer event and afterwards the whole company is exhausted. But the next day, when we all really want to sleep in, we do one thing — a recap where we capture what we call ‘worked, not worked.’ It would be easy for everyone to say, ‘All right, I'm taking the next week off. We just worked our butts off.’ But two weeks later, if we came back and did the post-mortem, they would have forgotten a lot of stuff,” he says.
With “worked, not worked,” documented for posterity, it’s a valuable resource to return to again and again. “When we start working on the next year’s conference, we can pull out the ‘worked, not worked’ and we've already documented the outcomes we liked, the outcomes we didn't like, and some of the decisions that went into that. By doing that every year, you just get a little bit better,” says Lawson.
This approach is perhaps best summarized by one of Twilio’s favorite mottos, which comes from Chief Product Officer Chee Chew: Every day, our goal is to suck a little bit less. "It expresses this idea that it’s okay that everything’s not perfect and we suck at certain things, but if we just suck a little bit less every day, then we’re building a stronger company as a result."
This article is a lightly-edited summary of Jeff Lawson’s appearance on our new podcast, "In Depth." If you haven't listened to our show yet, be sure to check it out here. Cover photo by iStock / Getty Images / Jokic.