How To Build High Performing Software Teams, with Jeff Lawson, Twilio

If I were to try to solve this problem, a much faster path would be to go this route. But if I'm told by the spec I have to take this route, the developer comes back and says, oh, that'll take nine months. And the executive is like, well, that shouldn't. That shouldn't take nine months. Well, if he tied my hands and said I have to write it exactly like this, I spec'd it out. It takes nine months. But if you share the problem with me and let me come up with a better solution, knowing what I know about the code, maybe I can get it done in two weeks.

I need some traction. You need some traction. Let's get some traction.

Hey, what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over 100,000 people just like yourself, on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more, this episode is brought to you by Boast AI. Each year, the US and Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast AI software to maximize cashback. Check out B Oast AI. This episode is also brought to you by Launch Academy and an international tech hub that provides mentorship, resources, network and the environment for entrepreneurs to launch, fund and grow their startups. Since 2012, Launch Academy has incubated over 6,000 entrepreneurs, of which 300 have grown their startups past seed and Series A and have collectively raised over $1.2 billion in funding. To learn more about Launch Academy's programs, check out link launchacademy ca hey everyone, Lloyd Lobo here.

Super excited here today. In a tech driven economy, you would argue that developers rule the world and Twilio is at the forefront enabling that army, helping more than 200,000 companies from startups to enterprises and millions of developers to embed phones, VoIP messaging and email into their applications. So open over a billion in ARR. Over 60 billion market cap. Lots to learn from Twilio and your journey, Jeff. And you started your entrepreneurial journey at 12, right? I mean, you DJed your way through college. You had this startup before we dive in. I'm super excited. You were at our traction in Banff in 2014, and you were phenomenal. You said software is eating the world was the talk. And then in 2015, you came to traction. We were at that dingy nightclub in Vancouver, and you give this amazing talk on conviction. Have conviction about the customer you're serving and the product, and let that be your primary guide. So you've been an idol for me through my journey. One of the most inspirational entrepreneurs. Give us your backstory in, like, maybe a few minutes here. Like, you know, from college to varsity to StubHub and all the way to figuring out Twilio.

Well, you know, thanks, Laid. I think the key thing is I'm a software developer. You know, I started really learning how to write code when I was in college, which I started college in 1995. And one of the really interesting things was I happened to start college right at the birth of, like, the Internet. You know, as most of us knew, it sure existed in a form prior to them. But, like, when I showed up for college in the fall of 1995, it was like, weeks after the Netscape IPO. And, like, the thing I was most excited about when I showed up in my dorm room was. Was not like, beer or parties. It was the Ethernet jack. Like, having a 10 megabit connection was, like, so interesting to me. So I FTP down my first copy of Netscape Navigator 1.0 and I was off and running. And the interesting thing about the Internet and learning to code in that time was you could create something and instead of, like, software that just ran on your computer, which, like, I had an Apple Iie when I was a kid, and, like, sure, you can make some toys, but you really couldn't do anything all that interesting with it. Nobody would ever appreciate it except your parents. With the Internet, suddenly you could write some code, put it out there. And at the time in 1995, like, oh, millions of people could see that thing that you built. And now, of course, it's not millions, it's billions of people can see that thing that you built. And so I really got this bug of saying, what can we do with this thing called the Internet and this thing called code, where you can type magic code into a text editor? And if you build something that's of interest, millions or billions of people can actually become users or customers of the thing that you built. And so I created an excuse for my to start my first company, which was during the dot com days was a company called versity.com, we did lecture notes for college students. That was the first company I did. And we created it not necessarily because we thought the world needed that thing, but mostly because we said, we want an excuse to play around with this new thing called the Internet and let's go figure out an interesting business idea. And because we're college students, we kind of settled down. Let's create an academic resource for college students like us. And that's where I started my entrepreneurial career. That was a very typical dot com story, but really I got the bug for entrepreneurship, for Internet scale entrepreneurship, because when the world is your audience, which is a new concept really for entrepreneurs, there's just no shortage of ideas, no shortage of things that you can do to really serve customers and if you're lucky, actually change the world for the positive. And so that's really where it started. So my.com rollercoaster ride kind of ended, as a lot of them did, which was with nothing really achieved in the world other than learning a lot. But the company we. We got acquired for stock, and the company that acquired us hit the wall when the market crashed. So they went bankrupt. Then I was brought on board by my friend who's one of the founders of StubHub, who they were just getting the company off the ground, needed people to actually build the execution. They had an idea. And so I came on board as the first CTO and said, okay, let's build this thing. And we built the first version of the site and built the first version of the team and got StubHub off the ground. True story. I called StubHub customer service at some point many years ago, and the customer service agent was very confounded. They just sounded very confused. And I was like, well, what's going? They said, for some reason, the system's broken. It says your customer ID is number one. I was like, actually, that's true. I am customer ID one. Because at the time, you used auto incrementing integers as the customer id. And I pushed the code to prod and signed up and said it works. That was how StubHub got launched.

That was a 30x exit, if I remember correctly.

Right?

That was a massive exit at that time.

I was actually long gone by the time they exited. I wanted to start something new and ended up starting a bricks and mortar retailer, Extreme Sporting Goods. It was interesting as a technologist, I got to build all the systems that were needed to run a modern retail experience, but ultimately realized that extreme Sports like skateboarding, snowboarding, surfing weren't really the reason why I wanted to wake up every day. And that was when I went to Amazon. It was one of the first PMs at Amazon Web Services back in 2004, 2005, 2006. Like that timeframe, really interesting, opened my eyes to a lot of opportunity of what was out there to serve developers. Infrastructure as a service was really getting born. It was totally fascinating. And when I left Amazon, it's because I wanted to start my next thing. And I didn't know what I wanted to do actually, but I just knew I wanted to be an entrepreneur again and start something. I learned a ton at Amazon and I knew I wanted to apply it to building the next company that I did. And I realized that as a developer myself, having built three companies prior, there were two things that were common between all three of those businesses, even though they were really different. First was we were using the power of software to really out, execute, out, innovate in the industries. They're very different industries between all three of those companies. The power of software is the power to listen to your customers and turn their needs into a solution really quickly. I'm talking about, like weeks. You know, take an idea, build a prototype, put it out in front of some of those customers and say, are we on the right path? And get feedback and just iterate your way towards a better and better and better solution. That's the superpower of software. I'll put that into perspective. By the way, at StubHub, we went from the first line of code written to launching in about six weeks. That's the power of software. You get to learn and execute and continually improve that solution. Think about every app on your phone. They're getting updated, like on a weekly basis. You don't even know it. And web apps, they're getting updated every day behind the scenes, you know, so that's the superpower of software. But the other thing that we had needed at every one of those companies was a way to engage with our customers. And at the time, it was like really hard. Like if you wanted to have a phone call go out to your customer, or a text message, or you wanted to answer a call and provide some support or automated access to information, it was like, great. You had to go to carriers and you had to drop phone wires and you had to dig trenches in the ground and lay things down, and you had to go rack up a bunch of telco hardware in some data center somewhere, and then you had to go buy a Big software application, and then you had to go spend like millions of dollars to go integrate all this esoteric stuff together to get these little things done. And as a developer, I was like, I can't. You know, nothing we do takes years and millions of dollars. Everything is done in weeks. And it's lines of code and it's iterative. And you check your idea with customers. You know, you don't spend two years building something, only then to find out you built the wrong thing. You learn that really quickly. That's the power of software. And so started Twilio to create customer engagement infrastructure to allow every developer and every company who wants to be able to treat how they engage with their customers as a software endeavor, not as like a hardware and wires endeavor, to be able to bring it into the way that they're treating the rest of their business, which is it's agile, it's software, and it's an iterative approach. We learn from customers at every step of the way. And we thought that if we put customer engagement infrastructure into the tool belt of every developer in the world, then people like myself who are building all sorts of products and all sorts of companies and experiences would finally be able to build the things that they wanted to do to actually make really compelling customer experiences across kind of the many touch points every company has with their customers. And that was 13 years ago.

Starting Twilio back then, I mean, a phenomenal journey if you look back. But back then it was probably hard to get things off the ground because if you talk to VCs, they probably wouldn't get this. Like, you're selling to developers. Are they going to pay it? Devs don't pay. What's that journey like? Because I know you probably had a few instances there. I do remember as a part of the talk at Traction, you had said that you got married and you used all the money to put it back into Twilio. So we'd love to learn that journey before we dive into hiring and building dev teams.

Yeah, we started the company with developers in mind as the customer and the company. Twilio was founded by three software developers. Before we wrote a lot of code, we just talked to developers and we kind of described what we had in mind for Twilio. And we said, would you have an interest in it? And, you know, developers kind of said, oh, yeah, I'd love to check that out. We said, okay. We got enough conviction that we started building the prototype. And after we built the prototype, we circled back to those developers, those early people. We'd done research with. We said, hey, you know that thing I talked to you about several months ago? Well, like, here it is, here's the first version of it. We'd love for you to play around with it. Here's an API key, by the way, it's all free. Just play around with it. We want your feedback. And we got great feedback from folks. They asked for, like, oh, how do you do this? How do you do that? They give us a lot of feature ideas and direction. They started building. And so we said, okay, this is great encouragement. We set out the summer of 2008 to go raise our seed round of financing. Two things happened. First is it was the summer of 2008, see the whole financial meltdown happening, and venture capital largely closed for business during that summer. And so we had a really hard time raising money. But the other thing that happened was a lot of the people we did meet with, even though they were interested in investing, and they said, this whole developer thing doesn't make any sense. Developers are a market. Developers don't have the checkbook, all the things that you said. So why don't you come back, go build an app and then sell that to your customers, and if you're successful, you can always add an API later. And we thought about that and we went that whole summer of 2008 trying to raise money. And at the end of the summer, we didn't have a dime. We literally didn't have a dime. We'd been working just sweat equity. We didn't have a bank account because we didn't have anything to put in it. And after we got our last turndown, I remember it was August, we got our last rejection from one of the VCs. We were really hopeful this one last one was going to come through and lead the round. And they said no. And I remember the three founders, we looked each other in the eye and we said, is this just stupid? Should we just give up? A lot of smart people said we're on the wrong track here. Maybe they're right. But then we said, but our customers are telling us we're on the right track, our customers with their actions, and they're encouraging us and telling us we're on the right track. They're building, they're launching stuff, they're chomping at the bit. We just got to get this thing to launch. And so we put our heads back down and we got it to launch in November of that year. And after we launched, sure enough, developers started signing up, started paying us we got leads from big companies. Remember Sony was actually one of our first big inbound calls we got the day after our launch. Actually based on that, investors started taking an interest. And so what I would say is what we did is we followed our customers instead of following investors. And that served us well.

Since I heard it for the first time when you spoke several years ago is have that customer guidance be your primary light to start and go.

That's the lesson that I think is one of the most important ones. It's easy to focus on. The investor story gets a lot of attention. If you read TechCrunch, you'll hear all about the investors did this, the investors did that, and this got invested, and that got millions of dollars. And you can start to get this mindset where you're optimizing for the fundraise, you're optimizing for pleasing investors or having that press release. That's false progress. The real progress is by customers traction and revenue. When you have those things, by the way, investors take notice and that's what makes them want to invest, is when you have traction, when you have customers, you have revenue. That's the true thing that builds the business. And so therefore focus on the true north of customers and revenue growth. Especially if you're in a B2B market and everything else falls into place, honestly.

And then the other side of it is having conviction for that customers. Right. You talked about that in your previous companies. You just hated the customers and you didn't like there's.

Yeah, if you want me to go into that. So, you know, the reason I left StubHub fairly early on wasn't because I thought it was a bad business or anything like that. It was just I could see that I didn't like viscerally care about like tickets or you know, live events or like. It just wasn't my jam. It was a fine business. But when you're building something, you know, there's a lot of blood, sweat and tears that goes into building a company. And it's really hard to kind of get out of bed every day and put in the amount of energy that you need to do. When the product you're building or the customer you're serving just really aren't something you're viscerally passionate about. That's what I find. That's why I decided to take off from StubHub pretty early on. And the interesting thing was my next company was a bricks and mortar retailer for extreme sporting goods, which we had brainstormed. We brainstormed Like a thousand ideas of companies we could start. And for some reason, the one we all landed on was this bricks and mortar retail thing. Even though I don't do any of these sports, skateboarder, I do like skiing, but I don't do any of these things. Really, I kind of went along with it because as a technologist, it'll be interesting to go build a lot of technology that it takes to run a retail business. It's interesting because not only at this company did I realize that I didn't viscerally care about the world needed on their skateboard, but I actually got super annoyed. I think what you're referring to was like I was sitting in the back of a skate shop. Literally our first skate shop that we opened. I'm sitting in the back room writing code, headphones on, like big monitor, like doing a developer, like writing code. Meanwhile you'd have like, the employees would be running in and out, constantly reaching over me to get like boxes from the back room. The employee, like, they'd run in like, hey, dude, do you know where the size 7 shoes are? And I'm like, what? You know? And so like, if you're a developer, you know that you need concentration, you need flow. And they kept breaking the concentration. The other thing that we did was we made every surface in this store basically grindable by skateboarders. And so the skate kids were our customers. And we made like all the handrails were made of steel and all the steps had like steel. Like we actually said, you can skate in the store. And so kids were constantly skating in the store. And you always heard the noise, the slamming of decks down on everything. And it was such a racket, such a ruckus. It was loud music playing always. It was like a dream for skateboard kids, a nightmare for a developer. And I'm in the back, always getting interrupted. I remember this one moment, so one of our employees came into me and he was like, yo, dude, is the website down? And I just like kind of lost it. I was like, are you asking me or are you telling me? And he's like, slowly back away from the angry tech dude. Kind of like, I've awoken the bear. And I was like. And it's kind of in that moment I realized I am in the wrong place. I hate our customers, I hate our employees, I hate our product. That's a bad place to find yourself in. And so that was kind of when I realized I need to find myself a new environment. And so when I started Twilio, you Know, it really did make a point of saying I want to build a company where I'm really passionate about the customer, where I really feel like the work that we're doing is making some part of their life better, some part of their job better. I'm making them more successful and I can feel passionate about that. And so that's something I've been so excited about, that's driven me the idea that we're a platform that enables millions of developers around the world and 220,000 companies around the world to better serve their customers because they unlock the ability to build, unlock the ability to serve their customers and build amazing experiences. Like that's just something that's driven me now for 13 years that I love. And so the idea of serving builders is one that has been really exciting for me.

And that passion for your customer and your mission has turned into a movement. You wrote this amazing book. Ask your developer, everyone check it out. Askyourdeveloper.com all proceeds are going to charity. Why did you write that book? I can sense why you write everything is like coming from your passion for your customer and that mission and then your sort of actions display that right. So I kind of know. But tell us what made you write it and why now?

Absolutely right. You know, like at Twilio we work with, you know, 220,000 customers with 10 million developers in our ecosystem. And a conversation that I've had so many times with especially business leaders is like, how do I go about hiring developers? Or how do I go about building an environment where they're going to be able to innovate and do their best work? Like I've had that one off conversation sometimes that I realized nobody has really talked a lot about. How do you bridge the world of business and the world of developers? And you see this come up all the time in both sides actually. You see developers having this idea of the business people, you know, the Dilbert, pointy haired boss, all those jokers, they don't get it right. And then you've got the business people who are like, what's up with those developers? They give us, they give us all these weird answers like, well, I can tell you when the product is going to ship, but I can't tell you what features it's going to have. Like, what do you mean you can't tell me when what feature? I can tell you what features it's going to have, but I can't tell you when it's going to ship. You're like, it's infuriating or like a project is running late. This is a favorite of mine. There's some project that's running late. And so what business people? One of the main levers that business people have is budget. So, okay, well I'm going to give you a bunch more budget now. It's going to be on time, right? And the engineers say, sorry, that's not how it works. You can't solve this with budget. And the business people are like, ah, what's going on here? Why are you people such idiots? And so what I find is there's a communication gap and an understanding gap between technical talent and business people. What's weird is that I have a foot in both worlds. I'm a software developer and I am a executive. I'm a CEO of a public company. Now I can see both of those worlds and I see both and I see both sides being infuriating. I understand actually both sides and the needs that both sides have. And so I wrote the book to take my unique point of view as both the CEO of a public company and a software developer and try to bridge that gap. And I actually wrote the book more for the business executives. Let me tell you what happens in the world of engineering. Let me tell you about the culture that actually unlocks that talent. And let me tell you about the things that we executives do, usually unintentionally, that actually hurts innovation, that punishes people who take risks and really harms our ability to actually do the thing that both sides really want to do. The same goal from the business people and the developers build digital products and experiences that millions or even billions of people love and that make the company money. Guess what? That's the outcome we all want. So why is it that we can't agree oftentimes on how we're going to do that? And so I wrote the book to try to bridge that gap and create something that developers could actually hand to the business people they work with, whether it's product managers or engineering management or on the business side. But also that the business folks could read to get a better handle on how they contribute to either unlocking a real, you know, innovation oriented company and unlocking the best contributions from their technical talent or how they can, you know, accidentally do the opposite.

And so what is that first step like? I guess you've, you've seen it all, right? From building a small three person company all the way to a multi billion dollar public company. Where do business people start? Like, where do we start here in trying to fix this collaboration what are some common things you see that are broken? Like maybe two or three. And where do we start? So we're on a good relationship going in.

I think the biggest insight that I would say, the biggest message I would say in the book starts with the acknowledgement that writing code is actually a creative endeavor. There's a popular myth, propelled by pop culture actually, that developers are math geeks who are more comfortable with a quadratic equation than they are with a human conversation. And you think about Steve Urkel from Family Matters or my favorite, Dennis Nedry from Jurassic park, the guy who's rolling around in the mud, who's always fighting with everybody. That's the popular conception of developers. But in reality, the developers that I've had the pleasure to work with are really creative problem solvers. You think about the act of writing code as a creative problem solving endeavor. But the developer who is a creative problem solver, they can apply that skill to writing code, figuring out how to, like, actually write code, but they can also apply that skill to the reason they're writing code. Like, what's the business problem we're trying to solve? What's the customer problem we're trying to solve? And when they actually know and care about the business or customer problem they're trying to solve, developers can do much better work because they're part of the creative, the bigger creative problem solving process. In fact, the one you actually care about, which is what's the outcome of how we're going to affect the business or the customer because of this code that we're writing. And so the biggest piece of advice that I give is share problems, not solutions with developers. And when you do that, you'll get better software written faster that solves the customer problem more quickly. And who doesn't want that? If you think about how this works at a lot of companies, the idea is it's thought of as like, oh, the business people are there to understand the customer and to understand the business problem and write a specifications like a prd, the product requirements document. And then you kind of throw it over the wall to the engineers. The engineers write code that implements that requirement and throws it back over the wall to the business. And in that world, it's like almost an assembly line view of the world where developers are just like factory workers who arrange bits. There's this idea that, oh, if you just feed product requirements documents and Mountain Dew into one side of this machine, you get code out the other and everything is fine. But the reality is that if developers don't know what they're building or why they're building it. They can't add value to that process other than sure they can grind out some code. What I've seen is that when developers are brought into the problem they're solving, that is here's the customer problem we're solving, here's the business problem we're solving. Instead of saying we need a form written that has a field that's 40 characters long, that's called first name and the blah blah, tell the developer, hey, we're actually trying to make it so customers can sign up for our service in 30 seconds and not 30 minutes like it takes currently. That's a business problem to go solve. That's a customer problem to go solve. The developer might have a lot of ideas about how to do that, but if you tell them I need a field written that's 40 characters long, well, I guess they could do that, but they may not do a very good job of it. Or if it doesn't actually make any sense to them, like, well, it seems like there's a much better way to do it. But this is what spec says, so I guess I'll write it. You can see how that pointy haired boss idea comes about. Or another one is if you tell the developer, I need it written exactly this way, well, the developers actually know. Here's how the code currently works, here's how the architecture works. If I were to try to solve this problem, a much faster path would be to go this route. But if I'm told by the spec I have to take this route, the developer comes back and says, oh, that'll take nine months. And the executive is like, well that shouldn't take nine months. Well, if he tied my hands and said I have to write it exactly like this, I spec'd it out. It takes nine months. But if you share the problem with me and let me come up with a better solution, knowing what I know about the code, maybe I can get it done in two weeks. And so it's a matter of actually bringing developers into the problem and making them a part of coming up with the solution as opposed to believing that developers are basically just digital factory workers.

That is a great point, right? People don't do that enough. They just take PRDs, throw it over the wall. So I'm curious and this is some great advice here, how is you went from three people, founders who are all developers, to probably an engineering team of what, a thousand people? At least. And how is your team structured today? Like the engineering team do you have like ePods? What does that look like?

So we're big believers in small teams led by single threaded leaders is the way we organize our R and D group. So the value of small teams is that you create a small group of people that work like a startup and not work like a startup, like exactly in the way startups work. But you, you unlock the same kind of energy, the same kind of spirit, the same kind of intrinsic motivation because you're close to the problem you're solving. And this is best evidenced by when we first started scaling the company, we were probably maybe 20, 30 people. I don't remember exactly how many we were. So we started getting into conversations about how we were going to grow, how we can divide the work and all that kind of stuff. I had a friend named Dave Chappelle, was someone who actually hired me when I went to Amazon. And Dave had been about employee 100 at Amazon. So he was there in the early days of the company. I think he joined in 1997. When I joined in 2004, the company was, I don't know, maybe 5,000 people. And he actually left shortly after I arrived because he just, great run. And he decided to leave and he started. No, not the comedian Dave Chappelle, Different Dave Chappelle. He went and started a startup. The other startup did okay, ended up getting acquired back into Amazon several years later. He rejoined Amazon when the company was about 70,000 people. So I called Dave and I was like, hey, you've got a pretty unique vantage point. You've seen Amazon at 100 people, you've seen it at 5,000 people, and now you're looking at it at 70,000 people. How are those three companies different? Can you compare and contrast those for me? He thought about it for a second. He's like, no one's ever asked me that before, huh? You know what? It's exactly the same company. The same intelligence in my coworkers, the same bounce in people's step, the same sense of urgency. You would have no idea. Like there's 100 people that I'm like near in the office that I interact with maybe. But you'd have no idea that there were just floors and floors and floors full of people like that all around the world now, making up Amazon. And I was like, that's amazing. And the way Amazon has scaled that entrepreneurial startup culture is by continually reorganizing itself back into small teams to recapture that energy, that drive, that sense of purpose that you have when you're a small team. All working together to focus on a customer, when you can all internalize the problem you're solving and how you're going to solve it and the architecture and all the details. And so instead of feeling like, oh, I'm just a cog in the machine, it's someone else's job to go figure out why we're building this thing. I own the back button on Chrome or something. It's like someone else's job to figure out why anyone cares about this. It's like, no, you're part of the small team where the decisions are made, where you own your destiny, you own the choices you make, and you're accountable for the outcomes. And so we define teams by really three things. Number one, a mission. A mission for what they're here to do for a customer, which is the second thing. And the third thing are the metrics that tell you if you're actually succeeding in serving that mission for that customer. So with a customer, a mission and metrics, you have the basically the foundational elements of what this team is here to do every day. And now they get to sprint and serve those customers. And so that's the basis of how we've scaled our R and D group.

What does that team look like when you say small team? Is that like a team of 10, like, who are on that team and 10 people?

It's a little different. Isn't one formula for what the team looks like, but give or take, 10 people is what we found is the upper limit of where people can actually all feel like they're part of the team. And there's a bunch of benefits of small teams. One, like I talked about, is that feeling of intrinsic motivation of being a part of a team and knowing that what you do matters on that team. The second thing is low performers. They can't really hide. On a small team, you're only 10 people, and someone's not pulling their weight. It's pretty obvious. But if you're like a hundred people, like a big soup of talent and, like, it's easy for someone to hide out and be kind of checked out and for no one to kind of realize that. But on a small team, there's really no room for anyone like that to exist because everyone's got to pull their weight, and everybody stays really connected with the purpose. And so about 10 people is where we find. And the hard question comes here should be your next question, Lloyd. So what happens when your team is 10 people and you have to add the 11th or the 12th or the 13th because, you know, the challenges are growing, the scope is growing and the customer base is growing. You know, the hard thing to do is how do you keep small teams as you're growing as a company? And the answer is it's like a mitosis type process where you keep dividing the teams back into small teams. And you'd say, okay, well, it sounds easy enough, but it's actually a little. It's actually sort of hard because you have to take the problem domain that that team was solving, like the mission, the customer, the metrics, right. And you have to somehow divide it and you have to divide the people and you have to divide the code base and the problem domain in a way that makes sense. So I'll give you an example. In the early days of Twilio, our first product was Twilio Voice. This is the product that allows you to use our API to make and receive phone calls and program like what you do during those phone calls. So you could say, call this phone number and when they answer, play back this message and read this text and then connect them up to another caller. And the whole business logic of what might happen during that phone call. When that team grew to be more like 15 people, we realized that it was like there's a lot of friction and people were, we needed to divide it. And so what we did is we said, okay, this product is really actually two main things. It is a layer of connectivity into the carriers of the world that allow you to make that phone call or receive that phone call. And then on top of it, there's a bunch of APIs let you do the interesting things that you can do. And so we divided the world that way and then we built internal APIs between the two. By the way, this also enforces some really good architectural hygiene into teams because like the code base was kind of all intermingled between the two. It was kind of a mess, right? So we took the opportunity. So, okay, great, we're going to extract these two things, we're going to build a clean layer which is all about connectivity, and we're going to build a clean layer which is all about the programmability and then what we end up doing. So it took six months at least to actually do the work on the code, to be able to separate the two concerns, separate the teams out, and then continue to staff and grow those teams independently. But once we did that, we realized, hey, this connectivity product, this is its own product. We launched that as our Elastics of trunking product, which is just connectivity as a Service in addition to. Then we all said this product. And so you oftentimes find that when you separate those concerns, you might find, oh, there's an independent customer value proposition had to define the customer, the mission, the metrics. You know, the team that owned the connectivity layer, they took on my customer is not just the internal customers of this team, but also our external customers who want great connectivity at a competitive rate that works everywhere in the world. And when you see the world that way, you're like, actually there's independent customers for that. It's called SIP trunking. It's a whole product category. And so they went and launched that product.

And where does product managers and engineering managers and UX fit into this team? Or is it part of that 10 or is it 13 kind of thing?

Yeah, there's no strict formula. Generally speaking, they're part of that team. The thing that I would say that is the most important is the leadership of that team. And so a lot of companies do a two in a box kind of thing or three in a box. Sometimes it's like, oh, product management and engineering management and sometimes even like BD or someone like Allison. It's like, oh, you're all in charge of this thing. Well, you know what happens when everyone's in charge, no one's in charge. There's no one to break ties and no one is ultimately accountable because it's like if everyone's accountable, no one is. And so one of the things that we feel strongly is that the teams are led by what we call a single threaded leader. That's a person who owns the outcome and leads that team. There's so many different facets to what a company does that ultimately you want all those things owned by someone who wakes up every day and makes sure that they happen. And when you kind of break down the important things that companies do, you as a leader you go, okay, there's all these things that have to all be done right. You don't want to have to think about all them every day, but you want somebody in your company to wake up every day and that's all they care about, making sure that they succeed. And that's what single threaded leaders do. And so what you think about a single threaded leader is often, sometimes the title of general manager is applied to it, which is they're accountable for the outcome, they have the resources in order to actually achieve that. All the people report to them. With that team structure, the single threaded leader is ultimately accountable for the outcome that they're building. And I Think that's the most important thing because that's how you get ownership. That feeling like buck stops here and you build that all the way up. A lot of companies only have the buck stops here mentality at the very top of the org. Maybe there's some business unit leader who's a general manager and they oversee thousands of people or lots of revenue or whatever. But I believe that you actually want to keep replicating that model all the way down the org chart for a few reasons. Even a small part of the company, the thing that a 10 person team is working on, like you want an owner for that, you want that person to feel accountable for that smaller part of the outcome, that's how the person at the top is going to actually be successful, is by empowering and having ownership of all those things underneath. But the other thing that's important is that you create a training ground. You know, I often imagine in my head, I don't know if it's true or not, I imagine Amazon has like a tire store. You buy tires on Amazon? I don't know, you probably can, right? And at Amazon there's probably a person therefore is the general manager of the tire store at Amazon, maybe a recent mba. They left college and they're like, hey, you get to come and be the GM of tires at Amazon. And here's the interesting thing. Would that person be hired to be the CEO of I don't know, Pep Boys or some big automotive chain? No, probably not. You wouldn't be hired straight out of an mba. But at Amazon it's like, it's a tiny part, it's one of many stores they have and it's like it's a training ground. You get to run the tire store and if you're successful at that, you're going to be able to move up and run bigger and bigger and more impactful parts of Amazon. And the same thing goes at Twilio or I think any company, take smaller parts of your company where if you don't succeed, actually it won't kill the company, but hand complete ownership to somebody. And if they succeed, then they get to continually grow and take on bigger and bigger roles where the outcomes matter more and more and more, where the numbers get bigger and bigger. But you only get that if you give them complete ownership, where they learn actually how to be an owner. And I think that at a lot of companies where you only have a few, three, four general managers at the top of the company, what happens, nobody's been trained to be that owner along the way someone was a functional leader, most likely they were the head of product, the head of engineering, the head of sales, someone from finance. They stepped into this role of now being a functional leader into owning the whole thing. And they have no idea how to do that because they've never done it before before. It's a big risk for the company and for that person. But in a model where you have single threaded leaders all the way up the organization, what you've done is continually trained your bench of talent so that you've always got a new leader. Whether it's to take on some new initiative, some new goal you have, or whether it's take on a major part of the company as a succession plan, you're training talent all along the way. And I think that's a really important concept to think about.

Definitely. And this is one of the, probably the best management advice anyone could get now in terms of finding people and spotting that sort of talent. What are some hacks ideas that you guys use and you've used from the early days to find talent? Engineering talent particularly?

Well, you know, one of the things obviously we're helped by the fact that our product is a developer focused product. So a lot of developers have heard of us and they're exciting to build products that serve fellow developers. They have an intrinsic understanding of the problem domain. I'll talk more actually about one of the things we don't do to find talent, which is we are not in it to win the perk war. This is an interesting thing because being in Silicon Valley, there's a lot of companies who really go overboard in providing perks to their employees. There's one company I talk about in the book, I won't name the company, but it's a well known Silicon Valley startup who has a dozen beers on tap. Locally brewed beers in the kitchen of the headquarters. The first time I visited this company, someone gave me a tour and they were really proud of here's the dozen locally brewed beers on tap. I was like, oh, that's really interesting. But in my head I'm thinking like, yeah, sure there's going to be some employees that are attracted to the dozen beers on tap. But what happens when the startup next door adds 13 beers on tap? It's like, oh, we're screwed. And so I've always thought that you want employees joining the company for the true reasons that drive intrinsic motivation. It's because they love the people they work with, they love the customer they're serving, they love the actual work they do every day. Not the side benefits of being there. So we very intentionally don't try to win the perk war because in some ways you kind of weed out people who are joining companies because of those things as opposed to companies employees who really want to join for I think the true reasons why we get joy out of the work that we do. And so there's a selection bias in like people who aren't swayed by that because I'm sure those people they interview at those companies for the ones who decide not to pick that, by the way, there aren't some employees for whom those things are the most important things, which is like, okay, great, there's a company for those people, but the company for people who aren't as interested in those things because they are more interested in the work they do every day. Well, Twilio is the company for them.

You have a massive brand right now and you're a very inspirational leader. Twilio is an inspirational company. I'm sure everyone on this call would want to leave their companies and join Twilio, but it probably wasn't that brand in the early days. Right. How do you find people who are intrinsically motivated?

Well, I think the small teams and owner operator model actually does self select a little bit. Right. So for example, at Twilio, teams who build, who write code, actually operate it in production. They carry the pager. This is more common. Actually, when we first started Twilio, I think it was a little less common. So what you get there is people who are going to own end to end the outcome of what they're building. You know, I remember particularly early on in Twilio, like we would hire people who had offers from say a Google or an Amazon or a Facebook and you know, we couldn't match their comp. But what we told them is like, look, you're going to work on a small team and have big impact and the things you're going to do matter because you're part of a small team. You're not just one cog in this giant machine. The small team that you work on, you're going to be a full collaborator. You're going to be really owning the mission and the successful outcome of that team. And that mattered to a certain segment of the population. Apparently not to everybody. Obviously we didn't hire everybody who we could have. There are people who turned us down. But for the people who said, yeah, you know what, that's what I want. I want to be a big impact on a team that I'm A major part of, as opposed to being a cog in the machine and making more money honestly, but having less impact. So that's how you kind of self select for people with that intrinsic drive who want to be owners, who want to be part of the team and are willing to carry the pager and even make less money because they want a sense of purpose. And so I think that's how you do it. And so you sell with a sense of purpose. In the book I talk about for business executives, how do you actually get technical talent to join the company? Especially if you're like a traditional enterprise who has a lot of transformation to do and maybe not a company that's thought of as a software company and you're trying to attract talent that might go to Google or Facebook or Amazon and you're like some old school company. How do you attract talent? And honestly, the answer is, first of all, you show support from the top. The executives have to be involved in recruiting those early engineers. The story you tell is one of impact. And so I tell a couple of stories in the book. I tell one of Domino's Pizza. Domino's Pizza is this sleeper success story. Go look at their stock. They have outperformed all the tech companies over the last decade. And part of that is because they have become a tech company. The way Patrick Doyle was the CEO back in about 2010, the way he did that, he recruited this guy Kevin to lead technology for them. And this guy Kevin I talked to in the book, and they were a customer of Twilio's. And so I was talking to him about it, and he says, look, when I took the interview, I was mostly doing a favor for a friend. I did not think that I was going to go work at a pizza company as a technologist. But I got hooked by Patrick's pitch, the CEO's pitch that Domino's had to transform into a tech company. Otherwise their lunch was going to get eaten figuratively and literally by doordash and all these delivery companies and they had to become a tech company in order to survive. And Kevin, the pitch to you is you're going to lead the transformation of this company. You're going to save Domino's. This company has been in business for 50 years. You're going to save us, and you're going to be a key part of our transition to the future. And he got hooked. He was like, I wasn't expecting that. But when you're told you're going to lead the charge and you're going to be A big fish in this small pond. Like, you can be a big fish in the small pond, or you can be a small fish in the big pond of, like, Google, Amazon, whatever. That's a really exciting pitch. I also told the story of Barack Obama. So my co founder, Evan, was one of the first people recruited to the US Digital Service. And that was the group of developers that came largely from Silicon Valley out to go help the federal government modernize and actually adopt, like, Agile software and like all the practices that we use out here to go build great software to bring it in the federal government. And here's how it came about. Here's how he got recruited. Healthcare.gov, barack Obama had spent so much political capital to get health care revised with the Affordable Care act in America, only to see it potentially fail because the website they built wasn't staying up, wasn't stable. Can you imagine getting healthcare overhauled through Congress? Only have the website be the nail in this thing? And I've heard from folks that say they've never seen Barack Obama as angry as he was when he was dealing with healthcare.gov, a website. So my friend Evan and co founder Evan got an email. He had recently left Twilio, and he got an email from someone with a whitehouse.gov email address who said, evan, are you available for a meeting next week? And he was like, oh, somebody in the chat says, I wrote an article about Evan. He got an email from some of the WhiteHouse.gov email address, are you available for a meeting next week? And everyone was like, I guess, like, WhiteHouse.gov email address, like, seems legit. Okay, great. So he shows up at this hotel and he doesn't even really know what the meeting's about. He shows up. He do a whole background, like, background check, all this kind of stuff shows up. There's all the security, there's the metal detectors, there's like, you know, black cars everywhere. And he takes an elevator up to the top, to the, like, suite at the top. There's three other people in there, and they're all like, do you know why we're here? I don't know. Why are we here? And all of a sudden, they hear a helicopter flying by. It's Marine One. And a few minutes later, the door opens to this room and Barack Obama is standing there in person. He says, your federal government needs you. We don't know how to build software, and it's killing us. We got to modernize how the federal government and your peers in Silicon Valley have said you are some of the best and brightest. So I want you to come serve a tour duty for your country and help us to actually make technology and software strength of the federal government and serve your 350 million fellow Americans. He says, which of you can't come and serve your country? He goes, each of them. He points them, tell me why you can't do this. One person was like, I work at Apple and I'm shipping a product next month. And Obama was like, I'm talking to Tim Cook tonight, I'll get you out of it next. And it's like, think about this pitch. He said, your country needs you, why can't you come serve anyway? So the point is by recruiting people, showing them that you care, showing them they can have impact, and showing them they have support from the top, I mean, that's how you attract the best talent.

What are some things that demotivate developers? Right, and how do you manage that?

I mean, I think the things that demotivate developers are roughly the places where their expertise is not consulted. So think about how often we say things like, here's the prd, just write it. And we're like, well, this is stupid. I can write it, but you have to write it anyway. One of the things I've seen, and we've fallen into this at Twilio in the past, where it's like, okay, we've got our big conference coming up and we got to launch the thing. And the developers are like, look, we can't tell you if we're going to be able to launch it on time because Agile is often like that. Agile kind of says, you won't necessarily know. You can measure kind of week over week progress, you can measure velocity, but you can't necessarily with precision measure the milestones. And so you get these somewhat infuriating answers back sometimes from developers. One of the dynamics I've seen is where a mature business conversation between the technical talent and the business side doesn't happen. The business side says, we got our conference, we got to launch the thing. And the technical team says, well, I can tell you the time frame, I can tell you the feature set, or I can tell you the quality is the hidden third thing. And if the business says, I demand like, you know, we've got our conference, we got to launch it, it's got to have these features. Guess what often gets sacrificed without being actually discussed or decided upon. Quality. That's the thing that gets sacrificed, but it's not discussed. And then later down the line, you launch the thing. With the features at the conference. But then there's like, problems. There's outages, there's bad infrastructure, and it's like the developers like, well, I told you we couldn't launch it. No, you didn't say that you were going to cut all the corners and make it crappy. Like, well, what do you think was going to happen? So having a mature conversation between developers and the business about there's really three things. There's features, there's timelines, and there's quality. Now, there may be very legitimate business reasons to say, actually quality is less important. It's just a prototype or whatever, but, like, have a mature conversation. But this whole idea that, like, developers aren't consulted or not listened to, or you're not having a mature conversation about the real factors, the real decisions that are getting made on the ground, I think that's something that infuriates developers quite a bit.

How do you train the organization to make better decisions and keep the passion alive when you're not in the room?

That comes down to principles. As a company, you're going to outline values and you're going to outline principles. Some overlap and there's some differences, but basically, principles are how to make decisions and what you've learned as an organization and as a leader, that helps you make the right decisions more often than not. And as you learn new things about yourself, about the organization, or just truths about the world, documenting those as principles is a key thing to do. And so that's something we focus on. At Twilio, we've got what we call the Twilio magic, and they're kind of like 10 principles that we use to make decisions, and sometimes they border on values. And, like, values are a little harder to put your hand on. But principles are like, how do we make decisions? The more we learn and the more we define the Twilio way to make decisions, the more we can help people to make good decisions, even though we're not always.

I want to take this question because it's one several people wrestle with. My engineer goes way too long with his presentations and goes too technical getting into the weeds. How can we guide him to just get the essentials of his ideas?

Format has a lot to do with these conversations. I'm looking for a book. I don't see it on my shelf right next to me. Made to Stick is a really good book, by the way, about how to communicate in business. I'd recommend it to anybody, and you can hand it to your technical folks. I'd also Say format has a lot to do with it. We spend a lot of time actually at Twilio thinking about the format of how we engage with each other and how we make decisions. I'm a big believer in the written word. So we don't do PowerPoint presentations at Twilio. We do the written word because the written word, the narrative format, encourages people to explain their thinking in a way that PowerPoint doesn't. When you force people to write down their thinking a, it forces them to have more clarity. You actually have to write. Anyone can make up a slide and BS their way through a presentation. When you actually have to write it down in a narrative format and explain your thinking, it's really clarifying. And oftentimes you can't get to the end. You're like, actually, my thinking is all convoluted and I can't figure out why. Okay, nevermind. I guess I'm not passionate about this idea or whatever I'm trying to relay here. But usually what happens is it forces you to clarify your thinking, to get it down, and then you have the ability to control that conversation a little bit by one simple tool, the length of the document you allow into the meeting. So we often do six pagers for big things like annual plans. But I often find that six pages can actually be too long. And actually people complain about six pages being too short. I can't summarize all. I can't explain this whole concept in six pages. You're like, seriously, I can explain all of Twilio in six pages. So you can't explain this one part of Twilio in six pages. That's BS but even better than that is get it down to one page for certain things so you can say that engineer, hey, we're trying to make this decision. Can you explain for me in one page why you feel we should make the choice that we're going to make? And the chances are they'll say, oh my God, I can't do it in one page. Well, guess what? I need you to take all of your expertise, all of your learnings, and distill it into something that we can all understand in one page. And if you don't have that clarity to be able to say it in one page, then you may lack the clarity of actually why we're making this decision. And so the format drives the outcome and the engagement.

Awesome. I'm going to recommend everybody to get the made to stick book and look into that format as well. I want to take one last question here. I Know you have to run. You are a phenomenal speaker. So when the first time we did the event in Banff, we had the CEO of VMware and CEO of Red Hat, and this was 2014, and not many folks were aware of who Jeff Lawson was. And you hit the stage and everyone was blown away. Right. And you were the top rated speaker. The same thing. 2015, we were in this dingy nightclub.

I remember that nightclub. Yeah. Weird.

The backstage looked like a bathroom. Broken down bathroom. And you asked me like, hey, can I plug my laptop to display the slides? And I'm like, you have to send the slides like an hour ago. No. And they were like, okay, I'm going to wing it. And you went on this presentation and again, you blew everyone's minds away. And some of the biggest names in tech at the time were there. How did a developer learn to be such a phenomenal speaker? And I think that has a lot to do with motivating your team. Right. Like you gave the Barack Obama example, you gave the domino example. Like, how you speak and communicate has a big impact on inspiring people.

Well, thank you, Light. I really appreciate it. What's interesting is before Twilio, I had never given a presentation in my life. Actually, the biggest thing I would say I did, I read a few things. Like I read that Made to Stick book. I thought it was really helpful. I watched a lot of the Steve Jobs keynotes. I remember at one point. And it was like, I think before I started doing some of my first investor pitches, the biggest thing I did, actually was what started out as the founding team standup. Every Monday morning, the founding team at Twilio, the three of us, we did a standup meeting. Just basically, what are we doing this week? What happened last week, whatever. And we hired our first employee, she got added to the standup, and then our second, and our third or fourth. And the standup ended up becoming our weekly all hands. What began as like 3 people, 4 people, 5 people, 10 people, 15, 20, 30, 50, 100. This morning I had an all hands meeting, 5,000 people. But at no point in time was it, like, scary. Because every time, every week that we did it was just slightly bigger than the week before. And because we did it with a regular cadence, now we don't do weekly anymore. But for a long time we did. After a while we go into bi weekly and then monthly. Now we do roughly quarterly or every six weeks. I think the repetition of the format and the audience and that audience getting a little bit bigger every time. And me Getting a little bit better every time, I think. Just gave me a lot of rehearsal time, honestly. And so for folks that are starting companies or have companies, you've got this great opportunity to be a great internal communicator because you've got an audience and people are hungry for it by the way. They do want to hear, they want to know what's going on. And then for you, it's also an opportunity for you to become a better and better communicator as you grow. And I'm still working on that course every time as well. Awesome.

If I can get half as good as you, I'll consider myself successful in public speaking. That was phenomenal, Jeff. Everyone get the book. Ask your developer. I'm going to buy it. For our whole exec team at Boast AI, we just like between December, me almost dying of COVID and Now we raised 120. We raised 123 million to automate access to government incentives and non dilutive capital for businesses. So a way to scale. I think we bootstrapped way long. A lot I learned from you and watching you. So thank you so much. I mean as soon as I get off this call, I'm buying the whole exec team. Ask your developer. So askyourdeveloper.com and all the proceeds, by.

The way, all the proceeds are going to four organizations who are helping underrepresented folks enter the world of tech. And so with every purchase you are helping, all the proceeds are going to those four organizations. So thank you.

Awesome. And yeah, that's what we've done with Traction. We built a big community, of course, learning a lot from you. Over 90,000 subscribers. We don't charge for any of the events and the in person events we do do. All the proceeds get donated. So phenomenal. Big inspiration. Def. Thank you so much.

Thank you Lloyd. Thank you everybody for joining today.

I need some traction.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast. If you enjoyed the show, please leave us a five star review and you can find more information and all the resources mentioned in today's episode at Boast AI. That's b o a ast AI forward slash blog. Special thanks to our podcast partner Content Allies from podcast production and promotion. Content allies helps B2B companies build revenue generating podcast. We recommend them to any B2B company that's looking to launch or streamline their podcast production. Learn more@content allies.com you need some traction.

Let's get some traction.