In this episode of Industry Focus: Tech, Twilio (TWLO 0.96%) CEO Jeff Lawson joins David Gardner and Tim Beyers to talk through building good organizations, what a developer-first culture looks like, and other insights from his recent book Ask Your Developer.
To catch full episodes of all The Motley Fool's free podcasts, check out our podcast center. To get started investing, check out our quick-start guide to investing in stocks . A full transcript follows the video.
This video was recorded on Jan. 12, 2021.
Dylan Lewis: It's Friday, February 5th, and we're doing something a little different on today's episode. I'm your host, Dylan Lewis, and today, rather than have a conversation with one of our analysts, we're going to air an interview with Twilio CEO Jeff Lawson from our member live stream Motley Fool Live. Earlier this month, Motley Fool Co-Founder David Gardner and Senior Analyst Tim Beyers spoke with Jeff about the company he started building effective organizations and his recent book, Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century. If you don't know Twilio, you can think of it as a cloud-based platform as a service company that provides developers with the building blocks to add communication tools like messaging and phone calls to applications. The business is a Fool favorite and it's been an incredible performer since its IPO in 2016. With that, I'll turn things over to David, Tim, and Jeff.
David Gardner: Jeff, it's such a good time here, let's have fun the next half hour, welcome!
Jeff Lawson: Thanks, David, great to be here!
Gardner: Thank you and congratulations on all your success. Twilio was first picked at Motley Fool Rule Breakers this month, four years ago, we're still holding. So $29.05, thanks to our colleague Rick Munarriz, who pitched it to the team and it's been a spectacular, I guess it's a 13-bagger now. Jeff, I think your cost basis is a little lower than ours.
Lawson: [laughs] Well, it does help when you start the company.
Gardner: [laughs] Absolutely. Well, Tim Beyers is standing by. Tim, welcome, good to see you.
Tim Beyers: Yeah. Good to see you too, David. Great to meet you, Jeff. I have to say straight up here, I loved the book. I finished it last night. Let me just put this in context here. I'm an Audible learner, so I've watched a lot of your interviews. I watched you, I watched [...] interview you. Patrick O'Shaughnessy, one of our favorites, I've listened to you on that podcast. If you've caught my attention in a book, you have done something amazing. [laughs] You did. A lot of it I think just has to go with a little bit of blast from the past, because you put in from your own experience, writing that Hello World program. I did the same thing, I think in 1982, Hillside Junior High School on a TRS 80. [laughs]
Lawson: Print Hello World 20 go to 10?
Beyers: Yes, exactly. It was great. But I want to kick off with something that you write as the central thesis of the book, which is build or die or build versus die, I guess is a better way to put it. I want you to put that in context for us, because build versus die, as you're arguing that software development is a core competency for organizations. Can we talk a little bit more about that?
Lawson: Absolutely. If you think about the interface that most companies now have with their customers, it's become a digital one. Think about your bank. 20 years ago, you walked into your bank and if it was well decorated and well lit, and the teller was friendly and they gave your kid a lollipop, you said, "Wow, I really like my bank." Today, your bank is an app on your phone. If the app is fast, if it's easy to use, if it doesn't crash, and if it gets better all the time, adding new features and functionality to make your life better, you say, "I like my bank". This transformation is happening in industry after industry, where the people who are able to build great digital experiences and great digital products, well, they're the ones who are winning the hearts, minds, and wallet of their customers.
Every industry is becoming a software industry. It is almost literally a Darwinian evolution, where the companies who are best able to adapt to the changing needs of their customers and to build that software and answer their customers needs, those are the ones who win. I liken it to 20 years ago, IT was considered a cost center. It was about the laptops for the employees or maybe the financial software that the CFO used. They were great. Let's just try to keep the cost down as much as possible. Let's outsource all that, it's not a source of competitive differentiation. But now, because of the prevalence of mobile apps and web and everything else, customers actually experience all that software. Now it is a source of competitive differentiation. In the old world of IT, you would often have this question of, should I build the financial system or should I just buy a solution off the shelf? Usually, it made sense to just buy a solution off the shelf, but you always have this old build versus buy question. I would say, because of that Darwinian evolution that's going on, where the great builders of software can differentiate in the eyes of customers, now, it's not build versus buy, it's build versus die. That's the nature of that expression.
Beyers: It's interesting to me. Let's just talk a little bit briefly about what Twilio is. You're a company that makes tools that developers use to build software. I'm not going to say it's a self-serving cure, but you're in a pretty good place if the companies out there have to build software and you're creating tools that help companies build software, particularly communication software. That puts you in a pretty good position. But there was another story you have in the book that I like a lot, where you co-founded with a friend of yours, I think it's Matt Levenson. Do I have that name right?
Lawson: Yeah, you do.
Beyers: Okay. You founded this extreme sport -- a sporting goods store. You write about all of the visuals of you in the backroom, the headphones on, classic coder, and you're writing software to improve the operations of this store. Talk about build or die. You're using software to improve the experience of the store. I want you to talk a little bit about that. Have you done anything like that at Twilio now, this experience of, "Look, we've got to build software and put this out on a constant basis?"
Lawson: It's basically the story of my life as a software developer. The amazing thing about software is that you can continually iterate on it. You're never done. You can always listen to your customers and hear something better that you could be doing, get a new feature request or even if it's something simple like making it faster or whatever, there are always ways in which you can improve the software. That creates a cycle of continuous improvement, but in the market there is also competition between companies who are your business. That pace of software, you hear, "Oh, the business world is getting faster and faster." A lot of that is because of software. Because software invites you to continually iterate, make it better and better. Think about all those apps on your phone. They are downloading updates, now silent, and you don't even know it. You're getting new versions of those apps, pretty much every week. They're fixing bugs, they're getting better, and they're adding new features and functionality that are going to make your use of that app even better. That's really the superpower of the world of software. That's one of the reasons why it's so important for companies to really embrace that. Because if your competitors are really embracing that and iterating quickly and running a lot of experiments to figure out what customers want and they don't want, and you're not, you're relatively static. You wrote the software a few years ago and you just let it sit there. Well, guess who customers are going to actually find to be a better option? The company that's always testing and iterating and getting better and better. That becomes a little self-fulfilling.
You mentioned that Twilio provides the infrastructure for developers and companies to be able to do that. You're right. We arose because software developers and the companies who employ them saw the need to work more iteratively and to move faster. Therefore, infrastructure like Twilio or Amazon Web Services or Stripe arose to serve those customers, to enable them to meet the cadence of software and to serve their customers at Internet scale and Internet speed. But then, because we exist, now more companies can get on that bandwagon, more companies can execute with that iterative spirit. Then that makes the importance of it even more for every company. It really is folding into this whole build versus die thing, because just the nature of business and the speed of iteration and the speed of competition has just accelerated in recent years because of that power of software. It's built in.
Gardner: Really well put, Jeff. I used to say around the halls of Fool HQ, whoever has the most tech-ies wins. I'm very much, I guess, sympathetical with you on this. That's been part of how I think about every industry when I pick stocks, I ask the developer who has the developers. Many of our users who have not yet gotten to see your wonderful book, don't know that the title comes directly from, well, basically a billboard that you put outside of Silicon Valley public drive by and you were working with the marketing team and nobody came up with a good idea and you probably just said, "Let's ask the developer," which is a brilliant stroke. This is actually one of the few books that I could think of. It started with a billboard as the title, eventually, of the book. I want to just to shift briefly to Amazon. You speak highly of Amazon, Jeff, both of your time there and where it is today of course. That's been another long-term hold for us, it's a great company. Specifically though, Jeff, you credit Amazon for the inspiration for organizing in small teams. I'm curious if you'd like to just lay that out a little bit for our members so they can hear and understand what that means. Then, maybe, was there another best practice that you've learned from Amazon?
Lawson: Absolutely. Most companies, there's a tendency as they get bigger and bigger, they slow down, they get more bureaucratic, decision-making gets obfuscated and the employee base just loses its energy that it might have had when it was a start-up. That's the natural tendency of companies. Here is an interesting thing about Amazon. I got hired there in 2004, my friend Dave Chappell hired me. He had started at Amazon when there were about 100 people. I got hired as the company was about 5,000 people. Dave, promptly, he was like, "I've been here long enough." He left shortly after I got there. He went and started a start-up. That start-up later got acquired back by Amazon. When Dave went back to Amazon, the company was 75,000 [laughs]. Here's this guy, my friend Dave, who's like, "You've been at this company. You saw it at 100 people, you saw it at 5,000 people and now you see it at 75,000 people." I called him up one day, this is about 2011. Because I was starting to scale Twilio and I'm like, "How do I make some decisions here?" I said, "Dave, can you compare and contrast those three versions of Amazon: 100 people, 5,000 people, 75,000 people? Because it must be totally different." He thought about it for a minute and he said, "You know what? It's exactly the same." The same energy, the same drive, the same bounce in people's steps, the same intellect of the employee base. It's the same company. It's just that I work with 100 people who are closest to me. I would just have no idea that there are 75,000 other groups of those people all around the company, because it feels like that same start-up I joined in 1997.
I thought that is astounding. The secret to that is keeping it small, small teams. When you build a company, when you're growing the company, the goal is to try to keep that energy, that intrinsic drive that every employee has in the early days of a start-up and replicate it many times over as you get bigger. The way to do that is to continually divide the company and divide the mission of the company into small teams, teams of no more than, say, 10 people, and organize those teams around three things: No. 1, a customer; No. 2, the mission for what they are trying to solve for that customer; and No. 3, the metrics of success to tell you if they're actually succeeding in that endeavor. With those three things, now what you've done is you've unleashed that team's ability to go sprint for that customer everyday and to go innovate and try to be as autonomous and independent as possible. In that small group setting, every member is really connected to the customer and really connected to the mission, because it's small, again.
You think about a small team of, say, 10 people, if there's a low performer on that team or someone who's checked out, you're not going to get by for long in that type of environment, whereas if you're one of 500 people on a team, you're like, yeah, it's easy to get lost in the shuffle. But when you're one of 10 people with a strong sense of ownership over what you're trying to accomplish, somebody who's checked out won't make it very long. Everybody is very close to the decision-making and very close to the customer they're serving. I think that's the magic of how you scale a company while keeping everybody really motivated, really driven, and coming from a position of really understanding why they're there and what success looks like at the local level, at their team level.
Gardner: Jeff, have you just described how Twilio's organized?
Lawson: Yes. That's how we've done it as well. I talk in the book, it sounds easier said than done because you're like, if you are a small company or start-up, "I got 10 people." Or if you're a big company, you have a new initiative, maybe it's got the 10 people. But then it's succeeding, and it starts growing, so it becomes 20 people or 30 people. You're like, "What do I do now? My team that was nice and small just got big." Well, the answer is you have to keep -- it's like a mitosis process, you keep dividing the team, and you divide the missions, and you divide actually the technology or the code behind it, so that you can continually divide back into small teams that tackle various parts of the business. But every team in that story is connected to a mission and has a lot of drive to do that thing really well. I talk in the book about how you can scale something, whether it's a start-up or whether it's an initiative inside of a bigger company and continually divide it to keep that entrepreneurial spirit, even as the company or the initiatives continue to grow.
Beyers: Jeff, do you think that's indicative of the way -- you talk a little bit in the book about how you try to make the values very actionable. If you look at it, I encourage anybody, if you're an investor or thinking about investing in Twilio, definitely take a look at the site and the list of values that Twilio has. One of them is to wear the customer's shoes. You talk about this in the book. It seems like what you're talking about just there, about dividing into small teams, is a way to actionably wear the customer's shoes, because if you have a huge team, most of the people can't be near the customer. But how do you make it where, say, like the accountants are near to the customer. There's only so many people that can be near to the customer. But can you talk a little bit about this value and how you get everybody a little bit closer to the customer?
Lawson: Well, it's interesting. When you think about it, in the early days of a company, I'll talk about the early days of Twilio; on any given day, I might be writing some code, talking to a customer who's a sales prospect, supporting a customer with customer support, and paying some bills. You're doing everything. As companies grow, the tendency, of course, is for there to be silos, because people get more functional. You hire experts to do each of those things. There's a lot of great things about hiring an amazing customer support team, so that the developers who are building the product don't have to answer every support ticket. Obviously, that is beneficial, but the problem is, if you let it go too far, you end up putting these walls up that separate all the functions. You're going to have a sales team who's doing sales, their job would be to not have to bring the developers into every conversation with a customer. You've got sales engineers to do that. Or the customer support team, whose job is to answer the support tickets, as opposed to having the engineers have to do it all. If you do it perfectly, what you've done is, with all good intentions, you have accidentally siloed the people building your product from the very customers they're building it for. Again, it all came from good intentions, including product managers. Many product managers see their job as protecting their team from the distraction of customers. I think the best product managers are those who see their job as facilitating interactions between their team and their customers. It's not every interaction, but if you don't poke holes in those walled silos that arise in the company, then yes, you will isolate your team from the very customers you're trying to serve.
I love the story of one of the product leaders at Twilio, his name is Ben. His first job out of college was as a developer at Bloomberg, writing software for the Terminals. He got there, bright-eyed and bushy-tailed, showed up and he said to his manager, like, "Hey, when do we get to go to a training floor to talk to traders who are using our software?" The manager laughed and said, "That's a funny idea. We've never actually done that." Ben was a little dumbfounded. He was like, "You mean you've never met a customer that uses the software that we everyday [...] and build?" [laughs] The manager was like, "Well, not really." Ben actually just found his own path. He went and found a friend of his who was a trader. He said, "Do you mind if I stop by? I just want to see." Ben showed up at the trading floor. They had always assumed that their widget that they were building, they spent everyday building this widget, they assumed it was the full 27-inch screen, that was their beautiful widget. Well, it turns out that the trader had it in some tiny little 16x16 box in the corner of their screen. It wasn't even legible, you couldn't read the fonts, it was completely different from how they imagined their software was used. It wasn't until they actually went and interacted with a customer that they actually found out. That changed their roadmap entirely. We got to make fonts that work on a small scale, all these things happened. I share that example in the book because it's a really good example of what happens when those walls between you and the customer are so tall that you actually have no idea how your customer's actually using your product. As leaders, I think it's our job to intentionally poke holes in those walls that separate our teams from the customers they're serving.
Gardner: Love it. Jeff, when we were first researching your stock in, I think it was late 2016, Uber was such an important proof-positive in our minds, such a scaled, important company. You were doing incredibly important work for them. I'm sure you've leveraged that relationship and that brand to benefit you in lots of ways. I now am aware of many of the companies, how could I know all the companies that you work with, but I'm curious in particular, this is a new angle here, China. I'm curious, how much experience does Twilio have with Chinese companies or partners? In the build versus die narrative, the size of China and the amount of developers that they have, I'm curious about your take on U.S.-China next century.
Lawson: Well, it's a great question. Twilio doesn't do business in China. We don't put any of our technology there. We don't have a go-to market team there. We don't have development teams there. It's complicated doing business in China. Our take has generally been, look, we're operating in an enormous market outside of China. We can build an amazing business without having to deal with the complexity of doing business in China. That's where we're going to focus our efforts, and that's what we've done today.
Gardner: Thank you. Tim?
Beyers: Jeff, something else I wanted to just follow up on here. Let me see if I have this right. Is it true that everybody who gets a job at Twilio is required to at least try to develop something, write a little app? Maybe even it's the Hello World app. But is that true? [laughs]
Lawson: That is true. It's one of the mechanisms that we use to try to keep our company close to customers. Going back to your question earlier about, how do the accountants stay close to customers? Well, we have everybody build an app using Twilio. They get help, there's a class that they go through that teaches them the basics of coding and how Twilio works. They graduate from that one-week course, having built a small app with Twilio. What that does is it builds empathy so that all of our employees know what Twilio does. They don't just read about it on the website, they've actually built something with Twilio, as well as have empathy for our customers and know what customers go through when they are signing up and building something with Twilio and deploying it, and the joy that they get when they see it working. That's one of the mechanisms that we use to help keep that connection between all of our employees, not just the developers, but the accountants, and the attorneys, and the sales reps, and everybody, so they get the opportunity to use Twilio.
Beyers: I love that. I know, David, you're going to ask about Agile, but I want to make a plug for something that you've built. It's called TwilioQuest. It's this game for -- if you've never developed anything before, I really think it's awesome, Jeff. Well, I mean, we have limited time, maybe if you come back, we could talk more about it. But checkout TwilioQuest if you want to learn how to develop. But David, let me kick it to you here.
Gardner: Sure. It was likely developed with the agile process, which people in the software world recognize as a long-standing approach to innovation and development. It's often used these days by scrum masters to do things that have nothing to do with software. It's really a process, and a big one, Jeff. We know it works for creating software, but you also argue it can be effective for the entire company. You organize around small teams, as we talked about earlier. What is an example of a project that was not led by developers that has benefited from the Agile process?
Lawson: Well, there's so many parts of Agile to think about. The essence of agility is being able to respond quickly to changing conditions or new information. That's not just developer teams who are trying to iterate quickly on their software products, but what part of your company don't you want to be able to respond quickly to changing conditions? If 2020 and the onset of a global pandemic didn't prove to everybody how important it is to be able to respond quickly, I'm not sure what will. One of the favorite examples I have in the book is of the bank that has taken on agility as the mandate for its entire enterprise. That's ING Bank. If you look at it, there's a lot of content out there about how ING Bank has adopted Agile across the company, even into the bricks-and-mortar branches that they operate. They operate in agile ways. You might say, "What does that mean for a bank branch to be agile?" Well, it means that, first of all, you think of the staff of that bank branch as a small team. You think about them having ownership over the results of their branch. You think about them operating in two-week sprints, just like developers might, of saying, stand up, Monday morning, what is it we need to get done over the next few weeks? Well, here's the list of things we have on our agenda. Great. Then the team sprints, and every two weeks have a new sprint and get the team together and say this is what we're doing. It's about pushing autonomy and ownership down to the local level as much as possible. It's about empowering them with short cycle times to think about what it is they need to accomplish. Instead of saying, what is our annual plan for our bank branch, say, what is the plan for the next week or two weeks? Get the whole team on the same page and operate that cadence. That's an example of adopting agile practices across an entire company.
Beyers: I want to bring this home a little bit, because the way you talk about the ask your developer process, and you call it a process, and at the end of a lot of chapters you'll give five or six questions. You'll say: ask your developer about this, ask your developer about this, which I think is great, that's a practical way to do it. You tell me if I've defined this right, Jeff, I think of it as you've operationalized this old process you had with your friend Matt Levenson, who's saying, "Hey, I have a business problem. Can you solve this for me?" You, as the developer, are saying, "I think I can solve that for you." Yet Matt not prescribing to you like, here are the five things I want you to do. It's like, I have a problem, can you solve it? You're saying, "Yes, let me write some code to solve it." Have I described it properly?
Lawson: You did. Ask Your Developer is a book for business people, for people who are not technologists, who are not developers, because I get asked a lot, like, hey, it can be intimidating. I don't speak the same language as those developers, I don't know all the technical jargon. I don't want to look like a bozo. There's all things that people worry about when they are trying to work with developers. My answer is, that's fine. Don't try to pretend to be a technologist if you're not. But what you need to do is to turn to your technical talent and instead of giving them solutions, don't just hand them a specification document saying, "Hey, I want you to build this thing to the spec." Go to your technical team with the business problems you're trying to solve and unlock the creative problem-solving ability in that technical talent. Because developers are creative problem solvers. That skill comes to bear in writing code and solving technical problems, but it can also come to bear in solving business problems. I first learned this when I was working with my co-founder at that retail store, Matt Levenson.
The reason why I share the story of Matt is he was basically a technophobe when I first met him. He didn't even use the Internet, he was just like an old school, like, I don't even know this new fangled technology, I don't need it. What we learned though, because he wasn't a technical person, it actually really ended up making our collaborations really work well. Because he would just come to me and say, "I don't know all this computer stuff you do, but here's the problem I'm trying to solve." He would explain to me a problem. In our retail store, he was working on the incentive system for our store managers. He had this idea, he said, "if I could incentivize the store managers to convert people who walk in the door into buyers," that's what we want for the business, people walking through the door to end up buying something. He said, "Jeff, can you think of a way that I could track and then report to that store manager how good their conversion ratio is of shoppers and the buyers?" I said, "That's really interesting." We could probably put one of those like white counters at the door that counts some people walk in and out, and then we could correlate that with the data that's in the point-of-sale system, how many unique customers did we serve that day, and give on an hourly or daily basis an update to the manager what their conversion ratio is. I was like, "Let me work on that." A few days later I had the prototype up and running in our first store and that collaboration where he shared the problem with me, how do we figure out the conversion ratio as opposed to the solution? Jeff, I need you to put a door counters and the blah, blah, blah and all the stuff. First of all, he wouldn't have necessarily known how to solve the problem, but that benefited him. He didn't have to know how to solve them, that was my job. I'm the creative problem solver in that room. He shared the business problem with me.
That's one of the key takeaways from the book that encourage business people to share hard business problems, or customer problems that you need solved and let the developers and your technical teams come up with a variety of ways to figure out how to best solve that problem. You'll be amazed at what happens. Software gets built better, software gets built faster. You'll come up with solutions that you didn't even think about when you initially set out to do it. That's the nature and that's what I see the companies you typically think of as great digital companies like Google [Alphabet] or Amazon or Facebook, that mentality is much more prevalent in those kinds of companies than I think elsewhere in the world. That's part of why I wrote the book, which is to share, hey, this is how to unlock this talent. Developers are hard to hire. They're hard to retain. If you treat them like factory workers, it's going to get even harder. Hire these people with this technical talent that are hard to find and hard to retain, and then empower them. Let them use their full brains and guess what, you'll be amazed at what happens.
Lewis: The book is Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century. The company is Twilio, led by Jeff Lawson. Listeners, that is going to do it for this episode of Industry Focus. If you have any questions, you want to reach out and say, "Hey," shoot us an email at [email protected] or tweet us @MFIndustryFocus. If you're a Motley Fool member and you're interested in checking out our live stream, all you have to do is go to live.fool.com. If you're interested in becoming a member, head over to getlive.fool.com.
As always, people on the program may own companies discussed on the show, and The Motley Fool may have formal recommendations for or against stocks mentioned, so don't buy or sell anything based solely on what you hear. Thanks to Tim Sparks for all his work behind glass today, and thank you for listening. Until next time, Fool on!
