Introduction

Patrick: [00:00:49] My guest this week is Jeff Lawson. The founder and CEO of Twilio. Twilio is a $15 billion company offering a cloud communications platform to its customers. Twilio is used by customers Lyft, Twitch, and Yelp to make communications in their products easy. Jeff and I talk about why it pays to be a platform, how to build a platform and how to sculpt a company's culture. This is a must listen for anyone building a business, whether it's a tech business or not. Please enjoy our conversation.

Jeff, it's a random story how this conversation came to be, which was, I was trying to figure out who to study, what companies to study when it came to learning about APIs and a friend mentioned that Twilio should be the first company, I go read all the financials. I found you on Twitter and on Twitter you have a number that you can text. I texted that number and sure enough, it works. It got to you and I invited you and here we are. A great example of the company technology itself leading to a really interesting conversation. I thought a fun place to start would be... We're surrounded by some interesting, what look like company values and there's one that stood out and you see owls all over your office, which is draw the owl. I have to start there because it's the one that I can't figure out what it means. I'm very curious. Can you describe what draw the owl means?

Jeff: [00:02:00] The best values that our company has I actually believe requires some explanation because if it's like... We're integrity-

Patrick: [00:02:07] Work hard.

Jeff: [00:02:08] Yeah. Okay, you just kind of dismiss it out of hand but you arrive in a new company and you're talking about the values and one of them is draw the owl. Wait a minute. Hold on a second. Those are the ones you remember because they're real and you take time and you have to explain them. Draw the owl goes back to one of the early memes of the internet. In the early days of Twilio we couldn't get enough of it. Here's how the meme goes. It's just a picture, you can Google this. Google draw the owl and you'll find this. It's a picture. It says, how to draw an owl, is the title. Step one, draw some circles. It's got head, circle and then a sketch little body circle. Then it says step two, draw the rest of the owl. It's got a beautifully drawn done owl. It's a two-step process. Sketch some circles and then draw the rest of the owl.

It's funny but for some reason this meme wouldn't die in the early days of Twilio. We're printing it out, putting it up on the wall, taping it to the back of monitors. Then it started creeping into our conversations. Someone would email... It was when we were small we were 10 people. Someone emailed the whole company, "Hey, does anyone know how to do this or that?" And inevitably, somebody would reply with this meme and we're like, "Why is this funny? Why does this work?" We thought about it and we're like, well, this really represents the very notion of what it takes to get something done. To build something because there is nobody here who's going to give you the instruction book of here's exactly the 100 steps you have to go through to actually get this job done, or to build this company because it's not that obvious. The opportunity is here because we have to figure it out.

The subtext underneath draw the owl, is figure it out, ship it and iterate. There's no instruction book. It's ours to write and it's this call to action really if you think about for builders saying, "Look, when something is hard or ambiguous, you don't know how to do it. Well, our job is to go figure it out. And that's exciting. And that's what gets us out of bed in the morning. And that's why we love doing what we do because if there was an instruction book, if we were painting my numbers here, well guess what? It wouldn't be interesting at all and also there wouldn't be an opportunity." I think about Twilio, we were really the first API business. I remember when I started fundraising back in 2008. Started the company, built our prototype, talk to customers, got early customers onboard and then went out to go raise money for our seed round in 2008.

Figure it out, ship it and iterate. There's no instruction book.

The wisdom, the advice that I got from the investors I talked to was generally, "Hey look, developers they aren't a customer and APIs, well that is not a product. That's a feature of a product. It's not the product. It's a go build a product. Go build an app that does something. If you want to add APIs to it, go have fun. But the APIs aren't the product and developers aren't the customer." Our early customers were telling us a different story. They were saying that we were filling a valuable hole for them and that they needed our product so we listened to our customers. I always thought, if you think about draw the owl, well customers need a thing and it's not conventional to actually build an API as a product. But you know what? I think this is what the world needs.

We followed our vision there, and more importantly, we followed our customers and they led us to build this platform company, which is quite different from most product companies especially of that era in 2008. I'm glad that we did and I think that was the beginning of many such instances where we really followed our customers and followed our vision to be able to build something that conventional wisdom... If we were painting by numbers or following the playbook would not have led us to where we are. And those are the moments that I think are the most exciting actually as an entrepreneur. When you get to do something that you feel is right, and your customers are telling you is right. Those are the best moments of doings. You're not just rinse, wash, repeating some well-trod thing. You're actually figuring out how to have problems and that's what's so exciting. That's what draw the owl is all about.

A to Z of API's

Patrick: [00:05:25] It's an awesome mentality for builders and you mentioned two ideas, developers and APIs that I want to spend some time on. For the uninitiated, maybe describe what's important for them to know about what an API does, what it represents, why it's different than an app that you can click on stuff and interface with.

Jeff: [00:05:42] Absolutely. APIs are building blocks that developers use to build applications with. If you think about applications are a solution. They do a thing. If you need a solution for your marketing, you can buy an app and it does its thing. If you need a contact center, you can go buy a contact center app and it does its thing, whereas APIs are building blocks that are designed for developers to take and stitch together to go build something. Now think about every app on your phone. Every app on your phone is using some amount of computing power. It's storing a bunch of data. Almost all of them seems to use some geolocation or maps. They all take payments. They all do communications. If every developer, every company had to go figure out how to do those things by themselves, the world will be moving at a much slower pace. In fact, much of what we see on our phone still wouldn't be built if it was that hard. If you had to go invent everything yourselves.

Instead, what developers can do is take APIs that provide infrastructure and glue them together to build an app much more quickly, and much more scalably, and much more globally than they ever could before. If you think about that's what AWS is all about. AWS provides compute and storage as a service behind an API so that a developer can bring compute and storage into their app very easily. Twilio does it for communications. We have virtualized the global telecommunications network and provided it as APIs to developers. If a developer needs to make a phone ring, or send or receive a text message, or do a real-time video conversation, or real-time chat conversation. Those are all APIs with a few lines of code a developer can drop into their app and now have best-in-class communications functionality inside of their app. It's actually pretty crazy when you think about it. Going back to my story where in 2008 everyone said, "Oh, this isn't-"

Patrick: [00:07:28] This isn't a thing.

Jeff: [00:07:28] "This isn't a product. It's not a thing. Developers aren't customers." But you now look at obviously the success of AWS, the success of Twilio, Stripe is doing it for payments, Google maps for geolocation and map stuff. These are the fundamental ingredients into every app that you use all day on your phone and we obviously are using apps, whether it's on our phone or in the cloud, all the time. They are how we run our lives. And when you think about it, why have these businesses been growing fast? Twilio has been growing incredibly fast. We crossed a billion dollars of revenue last year. AWS is probably the fastest-growing enterprise software company in the history of the planet. Stripe is amazingly successful. Why is this category of products that are not solutions at all like most people would think but actually are APIs, why are they growing so fast?

It's because as our economy has turned into a digital economy and every company has had to become a software company. They have to start building software in order to delight customers because your customers want to engage with you over digital interface, whether it's their mobile device, whether it is a web application. If you are not a digitally enabled company, you're going to lose your customers. Every company is starting to become a digital company, hire software developers. Well, Twilio, Stripe, AWS we represent the supply chain for companies as they become builders of software. Then you think about every mature industry out there... I'm from Detroit so everything goes back to automotive for my brain and you're like, "Oh yeah of course. It's a very mature and sophisticated supply chain for building a car." General motors they don't build everything. No, they've got a supply chain for seats, and for the steering wheels, and for the steel, for the body panels, and the seat belts. There's a very sophisticated supply chain where people specialize in doing parts of the car and then GM assembles them and ships them.

Well, for the world of software has never had that. For most of the history of software if you were to build software, you really were building it yourself. You would be writing a ton of C code and actually having to figure it out all on your own. Then in the cloud, or in the early days of the internet you'd even figure out how to host it yourself. You'd have to go spin up your own data center or buy racks of servers and have people plugging cables in. You had to do it in order to get yourself online. That indicates to me there was no supply chain. It was every company for themselves to go figure out how to do this. What the last 15 years have really been about is recognizing that every company is becoming a builder of software and as such you need a mature supply chain to power all those companies so they don't have to go figure everything out themselves and that's what the platform revolution here is all about.

When we went public in 2016, I had this slide in our deck and it said, "We have entered the next great era of software." If you think about the eras of enterprise software, the first era was the 80s and 90s. It was the big enterprise era where every decision costs tens of millions of dollars and so the CIO made all the buying decisions and it was the highest stakes era of software. The vendors then were Oracle and SAP and everything was a big decision and high stakes. These projects took years to implement and they were extraordinarily complex and the high failure rates of all these enterprise software projects because it was on-prem big expensive lift. Well around the turn of the millennium, along came software as a service. Suddenly it became a lot less risky to do software because you could... Instead of having to go spin up a data center and rack up a bunch of gear, and hardware, and software the types of stuff that only a CIO could do, well now any line of business owner inside the company.

The head of sales could go put in Salesforce. They could buy it themselves and they didn't even need an IT department to implement it. They could essentially buy it online. The head of finance could buy NetSuite. The head of HR could buy Workday. Everyone could go out essentially and provision the services they needed and then pay part of the seat. Most people think that software as a service is the latest and greatest thing. That is software but actually the fastest-growing enterprise software company in history doesn't sell software, doesn't sell seats, doesn't sell anything like that. It's AWS and it's a platform model. When you look at the success of AWS, the success of Stripe, the success of Twilio, this indicates to me that at the scale that we're all operating at, the pace at which we're all growing this is a new era of software and it's that supply chain that is powering the need for platforms to provide things like compute, storage, payments, or for Twilio communications because these are the fundamental ingredients in every app that we use and every app that companies are built.

Patrick: [00:12:14] You sit in a very privileged seat because you get to see as a platform, maybe not knowing ahead of time, how developers are going to use you but then being able to observe the interesting ways in which they do so. You mentioned this idea and I love this idea of build or die as a replacement to buy or build. I'd love to hear you riff a little bit about how you recommend people out there that run businesses, which are not software businesses but understand the shift and want to orient themselves to becoming software providers or incorporating software into their business model. You've got to watch many do it. What recommendations would you give somebody like that out there that's running a business?

Jeff: [00:12:48] Yeah, it's fascinating. If you think about, for most of the history of software where your company would need some sort of, let's say back office system, you needed a new financial software or something like that. Any functionality I might imagine it would be really common to have a CIO and that CIO would undergo a build versus buy decision. The decision is really, should we go build this? Should we hire developers and build this part of our company? Or should we buy something from a vendor? For most of the history of software, you'd run that process and some vendor would come in and say, "Look, why would you reinvent the wheel? We've already built this thing that you need. Is this really the source of competitive advantage, your financial system, or even your marketing, whatever. That's not your competitive advantage. You're not going to build software to compete here. Go compete on your main thing let us take care of this for you." And honestly, they had a point.

And so most companies would outsource all parts of their company and they would buy vendor after vendor, solution for solution, rack them up somewhere or outsource it entirely even. Look at the IT departments. Most companies in the 90s and early 2000s will get completely outsourced to EPOs and things like that. And people said, "You know what? All this technology we use to run our company it's a cost center. And as such we are supposed to make it as inexpensive as possible, as cost-effective as possible. Outsourcing it makes a ton of sense." But suddenly around 15 years ago, around when the web started really becoming mainstream, when mobile started to really hit. Company after company realized that software digital interfaces was how they were going to talk to their customers and how they're going to compete in the market.

Think about banks. When is the last time you walked into a bank branch? Your bank is now an app. If your bank is outsourced it's app, well that's probably not very good if they saw it as a cost center. Well, that's probably not a good indicator of how happy your customers are going to be when you view your product experience as a cost center. And so in every industry they've started to realize actually building software is the source of our competitive advantage because if we are going to let either our competitors, or maybe even some digital disruptors, startups come out of nowhere and build this amazing product experience because they really understand how to build software, they know how to listen to customers, take customer's feedback and implement it quickly in the product and iterate, iterate, iterate. Those are the companies who are going to win.

When suddenly that is how customers have judged you. How good you are at listening to them and building great products and great customer experiences. That is how customers judge you. That's how customers reward you with their business and their loyalty. In that world you can't think of it as build versus buy, it's build versus die. Because if you don't build, and you don't listen to customers, and you can't answer customer's needs, and you're stuck with the same experience that everyone else has outsourced their product has. Well, then guess who's going to win? Some new startup that comes along and is brilliant at building product. Or the incumbent company that gets it and starts building, hiring software developers, listening to customers iterating your way.

One of my favorite examples of this is what's going on in the world of finance, especially in banking. Especially in Europe because they've got a lot of progressive laws about recording openness. And you got all these challenger banks. Companies like Banker, N26 are coming in as software companies and they're described themselves, "We're software companies that happen to have a banking license." And they build these amazingly beautiful customer experiences and the apps are incredibly easy to use and they look like... Think about the most modern, easy to use app in your consumer phone, I don't know like Netflix or whatever you want to think of as a great app. Well, these banking apps are that easy to use. That's how the digital disruptors are coming up in Europe and saying, "Hey look, this is an amazing product experience and our core competency is not even banking. Our core competency is actually software and we happen to have all the licenses and things we need to do to be a bank. But really we're here to serve you with amazing software." And they're winning millions and millions of customers that switching to these brand new digital banks.

But here's the most amazing thing. In response to that, the incumbents are doing the same thing. One of our customers is ING Bank. ING is fascinating because several years ago they promoted a new CEO and he came in and the first thing he did was say, "We as a bank are becoming agile." I'm not talking about the software developers. They're going to do sprints. That's almost a given. The whole bank is going to start acting like an agile set of agile teams. Down to the branches, and of course the software teams, every part of the company is going to be comprised of small teams. Those small teams are going to aim to operate autonomously. They're going to operate in two week sprints with stand-ups and the whole bit. If you're running a bank branch for ING, they literally are running it like an agile lean startup and it's amazing to see it.

You've got the digital disruptors coming in, building amazing software, and then the incumbents realizing that if they are going to survive, they need to act the same way. And ING is this amazing example of truly top-down. There's an amazing video on YouTube, agile at ING. I think if you Google that, I'm sure you'll find it and it's fascinating. It's a fascinating watch because you get to see the leadership of one of Europe's largest banks. Not the technical leadership, the business leadership say, "We have to be agile. Every part of this company has to operate a startup or else we will lose." And when you think about build versus die, that's the dynamic playing out right there. You got great startups coming in with amazing product capabilities building digital banks and then the incumbents in the space they're evolving to fight that. It's almost literally a Darwinian evolution because if customers measure you and reward you with revenue, when you have a great product in this digital era that is a software product, then build versus die literally plays out in that Darwinian sense of things because companies live or die by revenue.

You've got the digital disruptors coming in, building amazing software, and then the incumbents realizing that if they are going to survive, they need to act the same way.

Customer Focused Companies

Patrick: [00:18:37] I've talked to some of the senior folks at AWS about this notion of customer intimacy and building or extending, in their case, the platform very much like Twilio's in ways that align with their customer needs. Not just by asking them but by living with them. I'm curious how you, here at Twilio build, meaning how do you decide what product is the near term vision? How do customers figure into that? For those that are building software, what would you recommend as the proper product mindset?

Jeff: [00:19:06] Well, at Twilio we have a number of things that we do. But for us the most interesting thing is the fact that as a platform it allows us to learn from our customers. If you think about a product company that has a solution. When you have a solution, you've made a lot of assumptions about what problem your customer needs solved and how they want it solved because that's the definition in some ways of a solution. So you build a solution. Customers who have that problem hover around your solution. Customers whose problem is a little bit different than what you imagined. Well probably you're not going to intersect with them, or if you do, sales person will quickly qualify them out and say, "Customer you are unqualified to be a customer." You're what a weird concept that is? To unqualify a customer. Disqualify a customer.

What I love about being a platform is that as a set of building blocks, customers can go build about anything. When we talk to customers to find out why they're building the things they're building, it is extraordinarily enlightening because when a customer... Let's go back to that ING example. They built an entire contact center on top of Twilio. See I had this problem. They had 17 legacy contact centers that they had on-prem cobbled together over the years and they needed something better. Their team came to Twilio and started building a contact center on top of Twilio. When we went and talked to them and we said, "First of all, thank you for your business. Now I want to better understand why is it you're building? There's many solutions out there in the contact center market. Why would you go build your own on top of Twilio? That's not the path of least resistance. Now we make it a whole lot easier than it would have been 10 years ago but still you can go buy some solution and call it a day."

Well, they painted this picture for us. The context market was broken and they said, "There's nothing out there that meets our needs and that's why we are building our own on top of Twilio. Because with your building blocks, we can finally build the contact center we've always dreamed of." We said, "Huh! That's really interesting." We go talk to a bunch of other customers who are doing similar things on top of Twilio. We start to see this pattern emerge. The contact center market is broken and most companies are still on-prem. They've been stuck on-prem for decades and they want to graduate to the cloud and they can't. What being a platform allowed us to do was to listen to customers, observe how they use us, go talk to them and then say, "Did you want to go build all that stuff yourself?" They say, "Well, ideally no. If you had delivered something that gave us the speed of an app. Spin something up quickly and get to market quickly but then the customizability of your platform. Great APIs allow us to build anything we want on top of it that would have been fantastic."

Based on those set of conversations we built Twilio flex, which is one of our most recent products. It is a contact center application platform. What's really neat about it is you can go in and spin up a contact center in the cloud in minutes. Just go click some buttons. Here's your contact center. And there's all the things you'd expect a contact center to do. It does voice calls, and text messaging, and chat, and supervisor view, and agent views, and scales up to thousands of thousands of agents and all this stuff. But the next step after you create your contact center, it says, "End developer. Download the SDK and start customizing it." So really it's an API. It's designed for extension and integration and all this stuff.

We would have never seen this opportunity in the contact center market that really there's structural problem in the contact center market. We would have never seen it if we had built a solution. Instead, was having a platform where customers, by their activity, show us these hotspots on our platform of, God there is something going on here in this contact center world. Why is everybody going and building that? When you go ask the right questions, make the right observations into what's motivating the customers to go use your platform in that way, you can really paint this very rich product roadmap going forward in the future. That's one of the neat things about being a platform company. I always think if you have the opportunity to be a platform, and I know that's a word that's thrown around a lot, which I-

Patrick: [00:22:52] It's becoming a cliché.

Jeff: [00:22:53] Yeah, you say, "We're a platform for clean teeth." They're like, "You're a toothbrush, don't call yourself a platform." But in the true sense of the word, a platform to me is something that allows customers the flexibility to really build the things that they need with developers and APIs. That really is the true sense of a platform. That affords you the ability to really learn from your customers, and if you get your product teams and your customers close together so that learning can happen quickly and iteratively, then you can really unlock a lot of opportunities for the company and I've seen that work really well at Twilio.

Patrick: [00:23:26] I love this question, "Ask your developers", that I've seen related to Twilio. I think it was even on a billboard.

Jeff: [00:23:31] Yeah, we have that billboard up for six years now I think, on the 101 here in Silicon Valley-

Patrick: [00:23:36] I'm in San Francisco often and I've seen that billboard. Can you describe what that means? Why is ask your developers such an important idea?

Jeff: [00:23:42] We were taking up the billboard. It was 2014, 2015 around that time. We hired a marketing agency to come up with ideas for the billboard. They talked to our customers and they talked to our employees and they did all this work. At the end of their multi-month process they did the big meeting with us in the board room where-

Patrick: [00:24:02] Don Draper makes his pitch -

Jeff: [00:24:03] Yeah exactly right. It's the Mad Men pitch meeting-

Patrick: [00:24:06] The Carousel.

Jeff: [00:24:07] Presenting and they literally like the easel and the slides and it's great companies use Twilio. There's a logo of one of our customers. And they have a different version of that. Great travel companies use Twilio, and then there's a travel logo. I'm like, "Really that was months of work? What else you got?" And they're like, great hospitality companies use Twilio and I'm like, "Okay, thank you. Thank you very much. We have a billboard to put up on Monday. What are we going to..." We were literally in this meeting. I remember I was a Friday afternoon. We couldn't leave the office without getting the artwork to the company to put up the billboard. A bunch of ideas are flying around but one of the things that I always had in the back of my mind was, you know those pharmaceutical commercials where people frolicking in the fields and all sorts of metaphors for something and-

Patrick: [00:24:52] Hanging out in bathtubs.

Jeff: [00:24:53] Yeah, right? And at the end of it says, "Ask your doctor if Tryfloricol is right for you." Whatever. I always had this thing in the back of my head, ask your developer if Twilio is right for you. I blurted it out in this meeting. I was like, "What about ask your developer?" At first everyone was like, "Huh?" But eventually just mysterious enough, begged the question enough. There's always a question like do you want your billboard to be clever that people will remember it, or is it so stupid that no one knows what the hell you do? It's a fine line between them. And I never know... The billboards have been up there for six years but I still don't know whether if most people are like, "Oh, that's so clever Twilio." Or they're like, "What the hell is Twilio? What a stupid billboard!" But it worked because it created enough mystery and it works on two levels.

One, it's like this nod to the developers out there who are our customers, hey developers you get it. You understand what you need to go innovate. You understand the tools that you need to go build the things you need to build to delight your customers. And you know what? The business people they'll follow you. But it's also a nod to the business people of, "Hey look. You should really be turning to your technical talent. You should be trusting your developers with some of your biggest business problems." I actually think that is one of the mistakes that most businesses make, which is you take developers... Every business they want to be... Talk to any executive. "Do you want to be innovative? Of course. Do you want to be great at building software and delighting your customers? Oh yeah, of course. These are all things we need to do." Then you say, "Okay, how do you work with your software developers?" They're like, "Well, okay. We have this product team. We have executives who come up with ideas. Then product teams who write very detailed product description documents, product requirements documents, PRDs. Then only after everything is completely figured out we throw it over the wall to a developer and we say, build this."

Let me get this straight. You're taking the people, your developers have the most about what the technology is capable of and most knowledge of the existing systems and how they work and you're giving them tasks. Write code that does this, as opposed to going to your developers and really handing them the big business problems you're trying to solve. You go to your developers and say, "Hey, we're trying to increase conversion on the website by 30%. That's our goal. How can we do that? We're trying to decrease wait times for our customers when they're using our product by 50%. Hey developers, how do you think we could do that?" Developers, because they understand the architecture, they understand the software, they understand the domain. They could come up with some amazing ways of doing that but businesses don't think to ask them. Ask your developer is this observation, if you will, that most companies do not collaborate with their software developers in the right way to get their full potential out. To get their full energy out.

Then think about software developers are. Hard to recruit. They're hard to retain. They're very expensive. Everyone bemoans, "Oh my God it's hard to hire developers." Well let me get this straight. You're going to put them in the basement in like a software factory sweatshop and hand them tasks to go do and you're complaining that it's hard to retain them? No! How about instead of giving your developers tasks, give them problems. Share problems not tasks with your developers and guess what? Your business will be better, your developers will be more engaged, you'll get better ideas, everyone wins. That's interesting. I actually think agile and I'll assume that most of your listeners maybe know a bit about agile the software development methodology, which in a lot of ways is fantastic. It's far better than waterfall. There's a reason why it's basically taken over the industry as far as how software gets built. But the one thing about agile that I really take exception to is this idea that really we should model software development after a industrial age factory because that's literally what it is. It's a factory system.

Product managers write stories and specs and then they put them into the factory system to be built in the factory over a two week sprint. The developers can do planning and then it goes into the sprint and they can reject it if the specs are not good enough, blah, blah, blah, blah. What you've really done is taken this creative process creating an application that does something to delight a user of some variety, or achieve some business goal, which is a creative problem. How do I use this by pallet here, which has everything software can do and use it to solve big problems and you've taken this creative problem and turn it into a factory, which is bizarre. We all know that creative problems are not solved in that deadline driven factory soul crushing way. Yet for some reason software development has fallen into this. "No, no, no, no. Developers, you sit in your cubicle. You sit in your lane and you do the things that someone hands to you. You take in a wreck with your right hand, you write it and you hand it off with your left hand to be input in the done pile."

That's not how great software gets built because software is creative. Code is creative and the best software developers I've ever met in my life are incredibly creative people. They're able to see some customer problem out there and the first thing they ask themselves is how can software solve this? They're incredibly able to connect the dots between some business problem or some customer problem and the gears start turning in their brain and they say, "Oh, I bet we could solve it by boom, boom, boom, boom, boom." Putting the stuff together and that's how most great software projects get started. Here's the fascinating thing. I assume... Have you heard of hackathons?

the best software developers I've ever met in my life are incredibly creative people. They're able to see some customer problem out there and the first thing they ask themselves is how can software solve this?

Patrick: [00:30:08] Yeah, of course.

Jeff: [00:30:10] Hackathons are this idea that you put developers together and you share some problems with them or even leave it open-ended and in relatively short period of time, 24 or 48 hours developers can build something that's quite amazing. It's prototype quality but developers can take some problem and solve it in a very short period of time. Think about what that means. It means essentially that this is a creative energy that most companies think about, "Okay, once a year we'll do a hackathon. We'll keep the developers happy. We'll order some pizza and we'll get some lemonade and we will have the hackathon and the developers will be okay for another year." Let me get this straight. You see you're saying, we recognize our developers are creative problem solvers and for one day we're willing to let them do that, and 364 other days of the year-

Patrick: [00:30:54] Back in the coal mine.

Jeff: [00:30:55] Stop being creative. Stop actually solving problems. Get back in the coal mine. This makes no sense at all. What the best companies do is figure out how to actually pull developers in to the problem solving part. The here's this big business problem we're solving. Here's what our users need us to do and share problems with the developers and make them a part of actually the building of the solution and the designing of the solution and the ideation around the solution. Not just, "Here, I'm giving you a task now go do it."

The other fascinating thing I think about that whole hackathon thing is a lot of developers will do hackathons on the weekend. This isn't as big but it's several years ago startup weekends were a big thing. Where for a whole weekend actually a bunch of developers get together. I've been to a bunch of them, maybe 100 developers. It was hundreds of developers get together for a weekend and build an idea. Sometimes it would even turn into companies but they would mostly be thinking about, I wonder if we could solve a problem like this. For a weekend they would go at it and then Monday morning they go back to their day job. You think about it. What does that mean? How many professions do you... On your weekend-

Patrick: [00:32:01] That latent energy.

Jeff: [00:32:02] Yeah, I don't know about the lawyers on the weekend after a long week at the firm going, "I'm going to go do some amateur layering on the side now." No, usually they're like, "Okay, I don't have to work now for a few days." Developers, they love doing that creative act of solving a problem with software. They love it much that many developers actually do this as a hobby on the weekends. They'd be like, "Let me get this straight again." Business, you pay their paycheck and you didn't realize that your developers actually have so much more to give that they're actually doing the job you want them doing at your company they're doing it on the weekend for fun. Figure out how to unlock that energy. That's what ask your developers is all about. Ask your developer. Don't tell your developer, ask your developer about the big problems that they can help the company solve and the big business challenges. The big things your users need done. Ask your developers for how they should go about solving them. Don't tell them, "Here's what I need you to go do."

Creating a Company Culture

Patrick: [00:32:52] I love this idea someone told me, "You don't hire great people to tell them what to do. You hire them to tell you what to do." It's exactly the same concept and quite beautiful. I think business culture figures into this very prominently. Behind us is a board that says The Twilio Magic and there's 10, I guess what you would call values or principles and you can tell... Just 10 minutes in the office I could tell that this is all very intentional and a key part of what drives Twilio. I'd love to hear a bit about, again, the origin story of maybe some of the specific ideas like draw the owl that we already talked about but more generally speaking codifying aspects of the culture and why that seems, from the cheap seats 10 minutes in here, to be so important to what you're doing.

Jeff: [00:33:33] I always think that human beings we're tribal creatures. That's how we've survived for tens of thousands of years basically is by affiliating with some other grouping of human beings for our survival. It's really baked into our DNA and our ethos of this sense of belonging to a tribe and that can be the country that we live in. That can be the school that we went to. That can be the company that we work at. That can be the sports teams that we're big fans of. There's a lot of tribes who have actually ascribed to it during our lives. But when we feel like we understand what the norms are of that tribe and we understand what we do to fit in, or what we could do to not fit in. That really helps us to actually have that sense of belonging. As a company, it's incumbent upon us to figure out how to make it so our employees understand what we stand for.

What is this tribe we call Twilio, or in plays we call them Twilions. What are the things that we stand for? Why are we an important grouping of human beings on this planet? And how do we fit into your life? How can you identify as a part of this tribe? Because if you don't identify, you're not going to do very good work but you probably also won't enjoy it. We all strive... We crave being a part of tribes. Think about the behaviors that human beings do. The reason we grouped together. There's religions, and there's nationalities, and there's school identity, and brand affinities. Right now I'm a member of the Nike tribe. I'm looking at my feet and that's because of this tribal nature. As a company, you need to define what it means to be a part of your tribe. And I think that any of these groupings are really defined by three things. Your heroes, your symbols, and your rituals. That's what defines a tribe really.

For a company really defining your heroes, your symbols, and your rituals come to be the defining elements of what it means to be a company. What it means to be a unique group of human beings that's different from the group of human beings occupying the office across the street or anywhere else. So you think about that. First of all, who are your heroes? Who are the people that you talk about? What are the accomplishments they have? Countries have their heroes, George Washington. Religions have their heroes but companies do too, and who do you call a hero? And for what reasons? It's really important in a culture.

Patrick: [00:35:49] What's a hero of yours?

Jeff: [00:35:51] I think we talk about customers all the time and we talk about the amazing things customers have built. I think those are many of the heroes that we have at Twilio. I love, for example Skip Potter the CTO of Nike, spoke at our company last year and he talked a lot about their vision building unbreakable relationships with their customers and using technology to do it and being agile. That's a hero story. Serving someone like Skip and Nike is incredibly powerful thing to unify us all together. Talk about the ING story I told before. There's a company they've got 50 developers on a multi-year roadmap to reinvent their contact center and they're using our technology. You're like, "That's amazing. Look at the dedication. Look at how important look at the mission that they're on. That we're helping to be a part of." They're our heroes. We put them up on a pedestal and say, "We are here to serve you. That is absolutely amazing. We're here to make you incredibly successful inside of your company." Those are heroes.

The next are rituals. Think about the rituals that companies do, or any group of human beings. Obviously think about nations have all sorts of rituals. Religions have all sorts of rituals. Well, companies do too. Great, you have all hands every Thursday morning and there's bagels at it. That's a ritual. And for some reason, when that stops people get upset. You could go buy a bagel on the way into work. If you stop bringing the bagels in, it's not that big a deal. It's a 50 cent bagel but the reason why people get upset about the change in those things is because it's a ritual. It starts to define you. We've got bagels on Thursday morning for our all-hands meeting and I remember we actually do this. I started in the very early days, actually our all hands were Mondays and it started as the standup actually between the founders. At some point I started bringing bagels in. It was a half dozen bagels for six people in the company at the time. Then it was a dozen and the two dozen. At some point I was walking to the office every Monday morning with four dozen bagels. I'm like, "This isn't scaling anymore. I can't carry this many bagels." Even today we do our all hands and we have a few thousand bagels I think delivered to the office.

What a silly thing? But it's just one of those rituals. And it helps define who you are. We do Wednesday night dinner in most of our offices. Again, it could be any meal. It could be any night of the week. It could be anything but at Twilio we have W-N-D, Wednesday Night Dinner and that helps define here's who we are. We make them silly. There's a theme every week and there's something fun. That's the rituals aspect of it. Then there's the symbols. The symbols are the things that represent what mattered to the tribe. For most companies, the most powerful symbols you have are the values because the values are words that are handles on the culture. I'll separate out the culture and the values. Culture is what you feel when you walk into work every day. You don't and have to write anything down, it just is. Every company has a culture. Whether you've articulated it or not, there's a culture. There's a feeling you have when you walk into the office. A feeling you have when you try to get work done. It can be a good feeling. It can be a bad feeling. Whatever it is but that's the culture. It's how everyone feels during their course of their interactions inside the company.

Now the values are written words that are like handles on the culture. They allow you to describe it and they allow you to guide it. Without those handles, without those words you really have no way of describing. Think about what would you feel when you get into the subway. I feel something but there's no words because I don't think the subway system has really values or whatever. It's not really a tribe most of us belong to like the subway tribe. When you walk into your company, when you articulate your values you're putting words to that feeling and then you can actually go to work guiding it, and improving it, and making sure you stay true to the culture you want to have because you use the words handles to guide it. And so you can start to build them into... Okay, how do we implement these in a fair and equitable way in our hiring, and in our promotion, and in our recognition systems? How do we use them in our decision-making?

I hear our values articulated in decision-making all the time. I hear them in the hallways here and that's how I know they're working. One of our values is no shenanigans and I hear that invoked in decisions a lot. That's how I know it's working. Why did you pick... Someone's talking about a decision they made and I'll say, "well, why did you pick A over B?" And they say, "Well, we thought about it but B really felt shenanigans so we went with A." I was like, "Okay, good. Our values are doing the job.

Patrick: [00:40:07] What does shenanigans specifically mean to you?

Jeff: [00:40:11] Shenanigans is like-

Patrick: [00:40:12] It's a good word.

Jeff: [00:40:13] Yeah. It's like mucking around.

Patrick: [00:40:15] Yeah.

Jeff: [00:40:15] It's messing around. It is foolish. It is nonsense. All those words. I'm not conjuring exactly the right word I'm looking for but here's the important thing that we thought about when we did our values, when we articulated our values. And by the way, I say articulate very carefully because you can't create your values. You can't just invent values out of the air like I think it sounds good to say this. That'll be an empty word in the wall if it's not really representative of who you are. But what you can do is introspect the values of the company, or introspect to the company itself. Introspect that feeling that you have when you walk in the door. We did this early on. We did the first version of our values and our values have evolved over time. The first version that we did in about 2011 or so I pulled about 15 people into a room, that was maybe a third of the company at the time or so, and we did a series of actually dinner conversations for several months to think of what the words are, to describe the culture and debate that and all that.

Eventually, we were able to articulate, yeah these are the words that have the right handles on it. But one of the things I always thought about is there's a lot of ways to come up with those words. There's a lot of words you can use to describe a culture. What I've always sought to do though is to come up with words that were very human because there's a lot of words that are like... Say intellectual. You may know what they mean but you don't really internalize them. Most companies have a value that's the word integrity. "Oh yeah, integrity. That sounds good. You should have integrity as a value. Who wouldn't want integrity?" But when you really think about it, when you're walking around, you're making some decision you're like, "Do I have integrity right now?" That's not something you ever asked yourself. It's not something you could even answer. You're like, "Well, I know what integrity means in the dictionary but do I have integrity right now? Does this decision, is it integrity full? I don't even know what the bad verb version of that is." But it's a word like shenanigans.

Patrick: [00:42:08] You know when you see it.

Jeff: [00:42:09] You know it when you see it. You're like, "I have an idea. We can cover the pricing model. It's so complicated no one can ever figure it out." And someone is like, "You know what? That's shenanigans." You're like, "Oh yeah, you're right. I get it." So you know when you see it. One of the other lenses that we use is, can we imagine people saying this in the hallway? Can we imagine someone invoking this in the meeting? Can we imagine this as a hashtag? Believe it or not. Because think about the great hashtags. They're short and they're memorable and you can throw them out easily. If we want these things to be used in everyday decision-making, you want someone being able to throw this out into a meeting. Throw this out in a room as part of a conversation. You want somebody saying, "We could not. No shenanigans."

One of our other ones is be an owner. We hear that a lot. "Hey, we're having a hard time figuring this thing out, or it's hot potato. It's not us." Somebody just say, "Look, somebody needs to be an owner here. Who owns this?" And that [inaudible] be an owner. You know it's serious. That's one of our values and that means that we have to figure this out. You see that in a lot of our values. They're short. They're memorable. No shenanigans. Be an owner. Wear the customer's shoes. A lot of them we also try to make memorable. A lot of companies have a value around customer-centricity. We're a customer-obsessed customer-focused... Whatever they all sound good but a lot of those types of values are actually not quite opinionated enough to tell you what to do about them as an employee. You're like, "Yeah, we're customer-obsessed. Okay. Now what? Now let's have our meeting." Whereas at Twilio, what we've decided to do is to phrase it as wear the customer's shoes. Because to us the way in which you are a customer-centric company is by looking at problems and looking at the company from our customer's perspective. And the only way we can understand our customer's perspective is if we walk a mile in their shoes.

We will literally go into a customer and say, "We have a pair of Twilio shoes. We have these Twilio branded shoes. I will trade you a pair of Twilio branded shoes for your shoes." We have customer shoes hanging all around our office. We hang them in the conference rooms. We hang them in the public spaces and it raises these questions. Someone will walk into the office, oftentimes I'm interviewing a candidate for a job and I'll say, "Oh, do you have any questions for me?" Half the time they're like, "Yeah, I have a question. What's with the shoes hanging everywhere?" And there's a placard with a name and a company under it and I'll say, "That's a great question. It's a constant reminder that we're here to wear our customer shoes and those are actually shoes that our customers have given us. The reason why we hang them on the wall is to cause people to ask the question, what's with the shoes? It's a constant visual reminder of that value of ours."

The way you can think about the symbols, and the rituals, and the heroes and combining those things together to create a cohesive experience. I think that's a really powerful way to think about the culture that you're trying to intentionally build at the company and how you can guide it with the symbols, and the rituals, and the heroes and we being really thoughtful about that. It's really fun too. When you're starting a company you get to really ask, what kinds of... What collection of human beings do I want to actually cause to exist if we're successful? That's something you get to decide as an entrepreneur.

Building Platforms

Patrick: [00:45:11] I have two quick closing questions for you. I know we've got to go. The first is, any parting advice for people that are not building platform companies but that might be able to borrow some of the wisdom that you've learned from building a platform company? Any portable concepts that you would encourage people to think about in a more linear business let's say.

Jeff: [00:45:29] Start with why. Always be looking for ways to ask customers the reasons behind the actions they're taking. Don't let a salesperson qualify out a customer whose needs are slightly different than your product provides. Why? Because you might learn something by understanding why they need something different than what you built. The machine might wind up grind through customers and reject those ones but you imagine what you're missing if you do that. Let's start with why. Even the customers who aren't implementing your platform. A lot of people are content to say, "Great, you're going to buy my product? Fantastic." Why? Remember to always ask that. Get in there with customers who truly understand what they're there to do. That's why I think of it as the wearing the customer’s shoes. What's life like in their shoes? Why are they building? Then build systems, mechanisms in your company to continually capture why customers are using your product and why some of them aren't using your product.

The more you can institutionalize and build closed-loop feedback systems to learn from that continually, the more able you are to really hear your customers. I think that's the key thing and I think also giving proximity. Decreasing the proximity between your decision-makers and your customers. So much exists. Think about product managers. A lot of them see themselves as the defenders of the engineers to keep the customers away from the engineers. Then you've got the customer support team. They're the defenders of the product managers. How do I keep customers away from the product managers so that they can all focus on the work. You're like, "Let me get this straight. All of these people are designed to separate the people who are making decisions from the customers so that they can make better decisions? Or they can make worse decisions more quickly? I guess that's what that is there to do. You're like, "No, no, no. Create systems to actually create that proximity between your products teams, and your developers, and their customers."

For us that means small teams. If you're a small cog in a giant machine, you feel really disconnected from serving your customers and you're going to do it until someone asks you to go home at 5:00 PM. Whereas if you feel like you have agency over the outcome you're building for your customers and you feel the empathy for what those customers need from you. That's the thing that creates that intrinsic drive to do your best work and to go beyond and solve big problems. The more you can do as a leader to create that proximity between your teams and your customers, don't let the machine separate them. The machine wants to separate them. It wants to say we're here to protect people from customers and distractions, all this stuff but once you decide that customers are a distraction, you're done.

Patrick: [00:48:10] Yeah. My closing question for everybody is to ask for the kindest thing that anyone's ever done for you.

Jeff: [00:48:15] To answer that question I will point to a mentor that I had early in my career. A guy named Kevin O'Connor who was the founder of DoubleClick, which was the darling of Web 1.0, invented the banner ad and really the first monetization system of the internet. He was an investor in my first company, an angel investor. After the.com implosion happened and sadly my company didn't end up making any return for my investors. Kevin said, "What are you thinking of doing next?" And I said, "I don't really know." And he said, "Why don't you come out to my summer home in the Hamptons in the middle of winter and pull yourself up there and find one of your co-founders from the last company. Just go and basically in isolation without a lot of distractions, let's go figure out our next company." And I said, "Seriously?" He's like, "Yeah, I'll put some money in and let's go to idea number two." And so I did that. I spent about nine months in the Hamptons in the middle of the winter. It was desolate. They didn't even plow the roads out there because the Hamptons no one lives up there.

Patrick: [00:49:14] It's empty yeah.

Jeff: [00:49:14] It's empty in the winter. Most of the stores aren't even open. Luckily there was one grocery store that stayed open in the winter. They didn't plow the roads. I remember we would order stuff on Amazon just so the UPS truck would come plow the road for us. Once a week we'd be like, "We got to go restock." But Kevin was an early mentor and he'd come out periodically and we do brainstorming together. We researched. We wrote a lot of business plans. I ended up starting all things of bricks and mortar business as result of all that work but I was always very appreciative that Kevin, A, invested in my first company, which of course he didn't have to do but that was an investment decision. But then even after that investment didn't work out, he believed in myself and my other co-founders as entrepreneurs. And he said, "Great, company one didn't work out. No worries. Let's figure out the next thing." And he helped us to think about, A, getting back in the saddle and not worrying too much about the.com company that didn't work out but then in particular had a lot of faith and also taught us a lot.

I learned a lot from him about being an entrepreneur, about being pretty resilient as an entrepreneur and focusing on customers and focusing on the building that needs to get done. That was incredibly generous of him. Now, unfortunately, I've never made Kevin a dime. He invested in my first company, which was.com got caught the whole.com implosion. He didn't make anything there. My second company, I was the first CTO of StubHub and there Kevin ended up not investing in Stubhub. Then my third company that we started as a result of that Hampton's brainstorming was Bricks and Mortar retail where Kevin was actually basically a partner of ours in building that company. That ended up not working out. Bricks and Mortar retail it's a horrible business. When I started Twilio, he was the first person I went to and he said, "Eight developers?"

Patrick: [00:50:49] APIs.

Jeff: [00:50:52] APIs. Unfortunately, I've never made Kevin a dime. Kevin I'm sorry and I really appreciate all that you've done for me as an entrepreneur and to anyone else out there who has the opportunity to mentor and help entrepreneurs to really unlock their visions with your money but more importantly with your time, and with your knowledge, and your expertise, I think that is a fantastic thing to do. That's the paying of the entrepreneurial industry here.

Patrick: [00:51:11] Wonderful place to close. I've learned a lot from reading about Twilio and now hear from you today. I appreciate your time.

Jeff: [00:51:16] Thank you, Patrick. It's great to be here.

Transcript by @ScarrottKalani