Invest Like the Best with Patrick O'Shaughnessy - Jeff Lawson – How to Build a Platform - [Invest Like the Best, EP.158]

Episode Date: March 3, 2020

My guest this week is Jeff Lawson, the Founder, and CEO of Twilio. Twilio is a 15-billion-dollar company offering a cloud communications platform to its customers.  Twilio is used by customers like 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 be a platform, and how to sculpt a company culture. This is a must-listen for anyone building a business whether it’s a tech business or not. For more episodes go to InvestorFieldGuide.com/podcast. Sign up for the book club, where you’ll get a full investor curriculum and then 3-4 suggestions every month at InvestorFieldGuide.com/bookclub. Follow Patrick on Twitter at @patrick_oshag   Show Notes 1:18 – (First Question) –  Company vowels and draw the owl 5:26 – Significance of API’s 12:14 – How non-software businesses can transition into the space          17:50 - Agile way of working at ING Belgium (video) 18:38 – How they strategize their product build 23:27 – The idea of asking your developer and why it’s so important to them 33:02 – How they codified their business culture 45:12 – Parting advice for people building platforms 48:13 – Kindest thing anyone has done for Jeff  Learn More For more episodes go to InvestorFieldGuide.com/podcast.  Sign up for the book club, where you’ll get a full investor curriculum and then 3-4 suggestions every month at InvestorFieldGuide.com/bookclub Follow Patrick on Twitter at @patrick_oshag

Hello and welcome, everyone. I'm Patrick O'Shaughnessy, and this is Invest like the Best. This show is an open-ended exploration of markets, ideas, methods, stories, and of strategies that will help you better invest both your time and your money. You can learn more and stay up to date at investorfieldguide.com. Patrick O'Shaughnessy is the CEO of O'Shaughnessy Asset Management. All opinions expressed by Patrick and podcast guests are solely their own opinions and do not reflect the opinion of O'Shaunsi Asset Management. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions. Clients of O'Shaunacy Asset Management may maintain positions and the

securities discussed in this podcast. 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 like 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. So, Jeff, it's kind of 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'd go read all the financials. I found you on Twitter. And on Twitter, you have a number that you can text. So I texted that number, and sure enough, it works. It got to you, and I invited you, and here we are. So 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 kind of surrounded by some interesting, what looked 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 just the one that I can't figure out what it means. So I'm very curious. Can you describe what draw the owl means? The best values that a company has, I actually believe, require some explanation. Because if it's like, we're like integrity. Work hard. Yeah, you're like, okay, you just kind of dismiss it out of hand.

But you're arriving at a new company and you're talking about the values. And one of them is draw the owl. You're like, 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. So draw the owl goes back to one of the early memes of the internet. And in the early days at Twilio, we couldn't get enough of it. Here's how the meme goes. Just a picture.

You can Google this. Just 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. And it's got like head circle and then like a sketched little body circle. And one says, step two, draw the rest of the owl. And it's got a beautifully drawn done owl.

It's like it's a two-step process. Just sketch some circles and then draw the rest of the owl. So it's funny. But for some reason, this meme wouldn't die in the early days of Twilio. Be printing it out, putting it up on the wall, taping it to the back of monitors. And it started creeping into our conversations. Like someone who were email was like when we were small, we were 10 people. Someone email the whole company.

Hey, does anyone know how do I do this or that? And inevitably, somebody would just reply with this meme. And we're like, why is this funny? Why does this work? We kind of 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 hundred 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.

And so 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 it for builders. Saying, look, when something is hard or ambiguous or 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 out of bed in the morning. That's why we love doing what we do, because if there was an instruction book, if we were painting by numbers here, well, guess what?

It wouldn't be interesting. And also, there wouldn't be an opportunity. I think about Twilio, like we were really the first API business. I remember when I started fundraising back in 2008, started the company, built our prototype, talked to customers, got early customers on board, and I went out to go raise money for our C-round in 2008. And 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 like a feature of a product. It's not the product. So 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 a product and developers aren't a 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. And so I always thought, you know, you think about Draw the Owls, 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. And so 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. And 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 where 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 doing. Because you're not just sort of rinse, wash, repeating some well-trod thing. You're actually figuring out hard problems. And that's what's so exciting. So that's what Draw the Owls is all about. It's an awesome mentality for builders. and you mentioned two kind of ideas, developers and APIs there that I want to spend some time on. So 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. Absolutely. APIs are building blocks that developers use to build applications with.

And so if you think about applications are a solution. They do a thing. So if you need a solution for, I don't know, your marketing, you can go buy an app. It does its thing. And 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 compute power. It's storing a bunch of data. Almost all of them, it seems like you use some kind of geolocation or maps. They all take payments. They all do communications. And if every developer and every company had to go figure out how to do those things by themselves, the world will be moving at a much slower pace. And in fact, much of what we see on our phone's state wouldn't be built if it was that hard.

If you had to go and invent everything yourselves. So 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. And 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. So if a developer needs to make a phone ring or send or receive

a text message or do a video, real-time video conversation or real-time chat conversation, those are all just APIs. So 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. And it's actually pretty crazy when you think about it. Going back to my story where 2008, everyone said, oh, This isn't a thing. This isn't a product. It's not a thing. Developers are 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 so fast? Twilio has been growing incredibly fast. We just 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 and 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. So 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. And 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, there's a very mature and sophisticated supply chain

for building a car. General motors, they don't build everything. Now, they've got a supply chain for seats and for the steering wheels and for the steel for the body panels and the seatbelts. And like, there's a very sophisticated supply chain where people specialize in doing parts of the car and then GM assembles them and chips 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. And 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 by racks of servers and have people plugging cables in.

So you had to do 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. And so 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 software,

of enterprise software, the first era was the 80s and 90s. It was the big, enterprise era where every decision costs millions, tens of millions of dollars. And so the CIO made all the buying decisions. And it was the high stakes era of software. The vendors then were Oracle and SAP and everything was a big decision and high stakes. And these things, these projects took years to implement. And they were extraordinarily complex and the high failure rate 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. And 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 and the types of stuff that only the CIO could do, well, now any line of business owner inside the company, the head of sales could go put in Salesforce and they could buy it themselves and they didn't even need an IT department to implement it. They could just essentially buy it online. And the head of finance could buy NetSuite and the head of HR could buy Workday. Everyone could just go out essentially and provision the services they needed and just pay per the seat. And most people think that software to service is the latest and greatest thing.

Like that is software. But actually, the fastest growing enterprise software company 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, 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 Fertulio communications, because these are the fundamental ingredients in every app that we use and every app that companies are building. So you sit in a very privileged seat because you get to sort of see as a platform, maybe not

knowing ahead of time how developers are going to use you, but then being able to observe sort of 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 just hear you riff a little bit about how you recommend people out there that run businesses, which are not software businesses, but understand this shift and want to orient themselves to becoming software providers or incorporating software into their business model. You've gotten to watch so many do it. What recommendations would you give somebody like that out there that's running a business? Yeah, it's fascinating. I mean, if you think about, for most of the history of software, your company would need some sort of,

let's say back office system. You need a new financial software or something like that. Any kind of functionality you might imagine, it would be really common to have a CIO, and that CIO would undergo a build versus buy decision. And the decision is really, well, should we go build this? We hire developers and build this part of our company, or should we just buy something from a vendor? And for most of the history of software, he'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 this, your marketing, whatever, like 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 just outsource all parts of their company.

And they would just 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 would get completely outsourced to a BPO's and things. things like that. And people said, you know what, all this technology we used to run our company, it's a cost center. And as such, we're 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 were how they were going to talk to their customers and how they're going to compete in the market. Think about banks. When's the last time you walked into a bank branch, your bank is now an app. And so if your bank is outsourced its 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 disruptor, some startup 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 customers feedback and implement it quickly into the product and iterate, iterate, iterate, those are the companies who are going to win. And so when suddenly that is how customers are 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 customers' needs and you're stuck with the same experience that everyone else who's 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 incoming 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 progress

laws about recording openness. And so you've got all these challenger banks. Companies like Bunk or N26 are coming in as software companies. And they describe themselves as 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 just, they look like, think about the most modern easy to use app and your consumer phone there like on Netflix or whatever you want to think of as the, it's just a great app. Well, these banking apps are that easy to use. And so 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 just 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 are 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. So one of our customers is ING bank. I-N-G is fascinating because several years ago they promoted a new CEO and he came in and the first thing he did was said, we as a bank are becoming agile. And I'm not talking about just 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. So 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. And so 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. And so you've got the digital disruptors coming in, building amazing software,

and then the incumbents realizing that if they are going to survive, well, they need to act the same way. And ING is this amazing example of truly top-down. It'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 like a startup or else we will lose. And so when you think about build versus die, that's the dynamic playing out right there. You've got great startups coming in with amazing product capability. building digital banks and then the incumbents in the space, they're evolving to fight that. And it's like 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 liver die by revenue.

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 Twilios, 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? So for those that are building software, what would you recommend as the proper sort of product mindset? 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. So if you think,

Think about a product company that has like 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. And so you build a solution, customers who have that problem can kind of hover around your solution. Customers whose problem is just a little bit different than what you imagined, well, they're probably, you're not going to intersect with them. Or if you do, salesperson will quickly qualify them out.

Say, customer, you're unqualified to be a customer. You're like, what a weird concept that is to unqualify a customer, disqualify a customer. And so what I love about being a platform is that as a set of building blocks, customers can go build just about anything. And 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, like, let's go back to that ING example, they built an entire contact center on top of Tullio. 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.

And so their team came to Tuolio and started building a contact center on top of Tuolio. And 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 so 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 could just go buy some solution and call it a day. Well, they painted this

picture force of the contact center market that was just 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 box, we can finally build the contact center we've always dreamed of. You say, 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. And so 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. So great API is that was to build anything we want on top of it. That would have been fantastic. And so based on those set of conversations, we built Toyo Flex, which is one of our most, recent products. It is a contact center application platform. And 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 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 and thousands of agents and all this kind of stuff. But the next step after you create your contact center, it says, and developer, download the SDK and start customizing it. And so really it's an API. And it's designed for. extension and integration and all this kind of stuff. And we would have never seen this opportunity in the context center market that really this structural problem, the context center market, we would have never seen it if we had just built a solution. Instead, it was having a platform where customers, by their activity, show us these hotspots on our platform of, God, there's something going on here in this context in the 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. And so that's one of the neat things about being a platform company. And so I always sort of 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 kind of hurts me, right? Like you said, we're a platform for clean teeth. You'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. I mean, 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. I love this question. Ask your developer that I've seen kind of related to Twilio. I think it was even on a billboard. Yeah. We've had that billboard up for, I don't know, six years now, I think on the 101 here in Silicon Valley. I'm in San Francisco often. I've seen that billboard. Can you describe what that means? Why is Ask Your Developer such an important idea? Well, we were taking out the billboard. It was like 2014 or 2015 around that time.

And 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. And at the end of their multi-month process, they did the big meeting with us in the board room where. Don Draper makes a pitch. Yeah, exactly. It's the madman pitch meeting. the carousel, presenting. And they literally like an easel with the slides and pull it out. And it's like, great companies use Twilio. And there's a logo of one of our customers. And they had like a different version of that. Great travel companies used Twilio. And there's like a travel logo. And like, really? That was months of work. What else you got? They're like, great hospitality companies used

to really. And we're like, okay, thank you. Thank you very much. We have a billboard to put up on Monday. And so we were like literally in this meeting. I remember it was a Friday afternoon. We couldn't leave the office on getting the artwork to the company to put it off the billboard. And a bunch of ideas were 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 frolicing in the fields and all sorts of metaphors for something. Hang out in bathtubs. Yeah, right?

And at the end of it, so ask your doctor if triflorical is right for you, whatever. And I always had this thing in the back of my head. You should ask your developer if Twilio was right for you. And so I just kind of blurted it out in this meeting. I was like, what about just ask your developer? And at first everyone was like, huh? But eventually it was just mysterious enough. Just begged the question enough.

There's always a question. Like, do you want your Billboard to be so clever that people remember it? Or is it so stupid that no one knows what the hell you do? There's like a fine line between those. And I never know. Billboard's been up there for like six years. But I still don't know whether most people are like, oh, that's so clever, Twilio, or they're like, what hell is Twilio?

What a stupid billwork. But it worked because it created enough mystery and it kind of works in two levels. One, it's sort of 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. And 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, oh, yeah, of course.

These are all things we need to do. And then you say, okay, so how do you work with your software developers? You're like, well, okay, so 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, PRDs, and then only after everything is completely figured out, do we throw it over the wall to a developer and we say, build this. So let me get this straight. You're taking the people, your developers who have kind of the most knowledge about what the

technology is capable of and most knowledge of the existing systems and how they work. And you're just 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 weight 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 can come up with some amazing ways of doing that. But businesses don't think to ask them. And so ask your developer is sort of 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. And think about software developers are hard to recruit. They're hard to retain.

They're very expensive. And everyone bemoans. Oh, my God. It's so 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 just 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. And it's sort of 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. I mean, 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.

And 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. What you've really done is taking 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 palette here, which is everything software can do and use it to solve big problems? And you've taken this creative problem and turned 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 falling into this. No, no, no, developers, you sit in your cubicle, you sit in your lane, and you just 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 and put it 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, okay, so how could software solve this? And 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, and putting the stuff together. And that's how most great software projects get started. And here's the fascinating thing. I assume, have you heard of hackathons? Yeah, of course. So 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. And think about what that means. It means essentially that this is a creative energy. And the 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 then developers will be okay for another year. Let me get this straight. So you're saying we recognize our developers are creative problem solvers and for one day, we're willing to let them do that. And then 364 other days of the year. Back in the coal mine. Stop, yeah, stop being creative.

Stop actually solving problems. Get back in the coal mine. You're like, 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. 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 test.

now go do it. The other fascinating thing I think about that whole hackathon thing is a lot of developers will do like hackathons on the weekend. This isn't as big, but 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 like 100 developers, sometimes hundreds of developers get together for a weekend and build an idea. And sometimes they would even turn into companies. But they would just mostly be like thinking about, I wonder if we could solve a problem like this. For a weekend, would just go at it. And then Monday morning, they go back to their day job. And you think about it. What does that mean? How many professions do you, on your weekend? That latent energy. Yeah, I don't know,

but the lawyers on the weekend, after a long week at the firm going, I'm going to go do some amateur lawyering on the side now. No, usually you're like, okay, I don't have to work now for a few days. Developers, they love doing that act, that creative act of solving a problem with software. They love it so much that so many developers will actually do this as a hobby on the weekends. And you're 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. So figure out how to unlock that energy.

That's what ask your developer 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 to go do.

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 kind of 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 sort of 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 just from the cheap seats, 10 minutes in here, to be so important to what you're doing. I always think that human beings were tribal creatures. I mean, 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. And so 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 that we actually ascribed to 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. And so as a company, it's incumbent upon us to figure out how to make it to our employees understand what we stand for. What is this tribe? We call Twilio or employees, 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. Just think about the behaviors that human beings do. The reason we group together, there's religions and there's nationalities and there's school identities 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. And so 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. And so for a company really defining your hero, 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. And so you think about that. First of all, you know, 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 is really important in a culture? What's a hero of yours?

I think we talk about customers all the time. And we talk about the amazing things customers have built. And so 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 an 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 context center 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 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. So think about the rituals that companies do or any group of human beings. I mean, obviously think about nations have all sorts of rituals.

Religions have all sorts of rituals. Well, companies do too. Well, 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 just go buy a bagel on the way into work. If you stop bringing the bagels in, it's not the 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. Oh, we've got bagels on Thursday morning for our all hands meeting. And remember, like, we actually do this. I started in the very early days, actually our all hands meetings. were Mondays, and it started as the stand-up, actually, between the founders. At some point, I started bringing bagels in. It was a half-dozen bagels for like six people in the company at the time, and then it was a dozen, and then 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. And so, and 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. It could be any meal. It could be any night of the week. It could be anything. But at Twilio, we have W&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. And so that's the rituals aspect of it. And then there's the symbols. And the symbols are the things that represent what matter to the tribe. And so 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. So culture is what you feel when you walk into work every day. And you don't have to write anything down. It just is. And 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.

And it can be a good feeling. It can be a bad feeling, whatever it is. But that's what the culture is, 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. So without those handles, without those words, you really have no way of describe it. Think about what do you feel when you get into, I don't know, the subway.

I feel something, but there's no words for it 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 like handles to guide it. And so you can start to build them into, okay, how do we implement these in a fair, an 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 why 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. I said, 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 like shenanigans.

And so we went with A. It's like, okay, good. Our values are doing the job. What does shenanigans specifically mean to you? Well, shenanigans is like... It's a good word. Yeah, it's like mucking around. Yeah.

It's messing around. It is foolish. It is nonsense. One of those words, I'm not conjuring exactly the right word I'm looking for, but here's the important thing 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 just create your values. You can't just invent values out of the air. I'm like, I think it sounds good to say this.

That'll just 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. And 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 like dinner conversations for several months to think of what the words are to describe the culture and debate it and all that. And eventually we were able to articulate, yeah, these are the words that are 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 just sort of 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. Like, oh yeah, integrity. That sounds good. Yeah, 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 ask yourself. It's not something you can even answer. You're like, well, I know what integrity means in the dictionary. But am I, do I have integrity right now? Does this decision, is it integrity full? I don't even know what the adverb version of that is. But it's a word like shenanigans. You kind of know it when you see it.

You know it when you see it. You're like, I have an idea. Yeah, we can come up with a pricing model so complicated. No one can never figure it out. And someone can easily be like, you know what? That's shenanigans. You're like, oh, yeah, you're right. I get it.

And so you know it 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 are short and they're memorable and you can throw them out easily. And if we want these things to be used in everyday decision making, you want someone being able to throw this out into a meeting.

You know, throw this out in the room as part of a conversation. You want somebody saying, we could, no shenanigans. One of our other ones is be an owner. And we hear that a lot. Hey, we're having a hard time figuring this thing out or hot potato. It's not us. Somebody just say, look, somebody needs to be an owner here. Who owns this?

And that, be an owner, you know it's serious. That's one of our values. And that means that we have to figure this out. And so you see that in a lot of our values. They're short. They're memorable. No shenanigans. Be an owner.

Wear the customer shoes. A lot of them we also try to make memorable. Like a lot of companies have a value around customer centricity. We're a customer obsessed, customer focus. Like, whatever. They all sound good, but a lot of those types of values are actually not quite opinionated and 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. Okay. Whereas Atulio, what we've decided to do is to phrase it is wear the customer shoes. Because to us, the way in which you are a customer-centric company is by looking, 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 on their shoes. And so 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. And 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 it 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 like 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. And the reason why we hang them on the wall is to cause people to ask the question,

what's with the shoes? And it's a constant visual reminder of that value of ours. And so the way you can think about the symbols and the rituals and the heroes and kind of combining those things together to create a cohesive experience. And 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 just 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? And that's something you get to decide as an entrepreneur.

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. So any portable concepts that you would encourage people to think about in a more linear business, let's say. 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 platform

than your product provides. Why? Because you might learn something by understanding why they need something different than what you built. So the machine might want to grind through customers and reject those ones, but you imagine what you're missing if you do that. So I always start with why. And even the customers who are 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 to truly understand what they're there to do. That's why I think of as wearing the customer shoes. What's life like in their shoes?

Why are they building? And then build systems and mechanisms in your company to continually capture why customers are using your product and why some of them aren't using a product. And 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.

And 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 they can all focus on the work? You're like, let me get this straight. all 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. So for us, that means small teams. If you're small cog and a giant machine, you feel really disconnected from serving your customers and you're just going to do it. Someone asks you to do and go home at 5 p.m. 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.

So 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 kind of stuff. But once you decide that customers are a distraction, you're done. Yeah. So my closing question for everybody is to ask for the kindest thing that anyone's ever done for you. 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. And after the dot-com implosion happened and sadly my company didn't end up making any return for my investors, Kevin said, what are you thinking to do it 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 the winter and just pull yourself up there and find one of your co-founders from the last company, just go. And with 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 do idea number two. And so did that. I spent about nine months in the Hamptons, the middle of the winter. It was desolate. They didn't even plow the roads out there because the Hamptons, no one lives out there. It's empty in the winter. Most of the stores aren't even open. I mean, luckily there was like 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, well, we've got to go restock. But Kevin was an early mentor. and he'd come out periodically and we do brainstorming together and we research. We wrote a lot of business plans. I ended up starting all things of bricks and water business as a 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 dot com company that didn't work out, but then in particular had a lot of faith and also

taught us a lot. And 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. And so that was incredibly generous of him. Now, unfortunately, I've never made Kevin a dime. He invested in my first company, which was dot com, got caught in the whole dot com implosion, so 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 Water Retail, where the Kevin, he was actually basically a partner of ours and

building that company. That ended up not working out, you know, bricks from water retail. It's a horrible business. And then when I started Twilio, he was the first person I went to and he said, yeah, eight developers. API. API. And so unfortunately, I've never made Kevin a dime.

So Kevin, I'm sorry. And I really appreciate all that you've done for me is not. entrepreneur. And so anyone else out there who was 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. That is a fantastic thing to do. That's the pain of the entrepreneurial industry here. Wonderful place to close. I've learned a lot from reading about Twilio and now hear from you today. So I appreciate your time. Thank you, Patrick. It's great to be here. Hey, everyone. Patrick here again. To find more episodes of Invest like the Best,

go to investorfieldguide.com forward slash podcast. If you're a book lover, you can also sign up for my book club at investorfieldguide.com forward slash book club. After you sign up, you'll receive a full investor curriculum right away, and then three to four suggestions of new books every month. You can also follow me on Twitter at Patrick underscore Oshag, OSHAG. If you enjoy the show, please leave a quick review for us on iTunes, which will help more people discover Invest like the Best.

Thanks so much for listening.