How To Collaborate, Manage & Work With Developers With Jeff Lawson, CEO Twilio

Alright, hey everyone in the SaaS community. Here with one of our favorite and most iconic cloud CEOs and founders, Jeff Lawson. Jeff has done great things with the SaaS community going back to joining us just after Twilio IPO'd, I think at the 2017 Annual. He was actually, I think, going to come to the 2016 Annual, but the IPO got in the way and he was kind enough to come back. He's done a bunch of things with us since COVID Giving us insights into how he dealt with the last couple downturns. And this one's fun. He's got his first ever book out. It is at www.askyourdeveloper.com. And I read voraciously. Do you read a lot, Jeff Half? How much do you read on a given day or week? Do you read everything?

I try to. I really wish I was a better reader than I am. Like, I, you know, when COVID started and we all got locked in our homes, I was like, okay, well, at least I'm going to read a lot. And I feel like I've read, you know, Half of many books.

Half of many books.

During COVID But nonetheless, you usually get most of the knowledge out of the first half of the book, with the notable exception, I would say, of my book, which of course, all the way to the last page is just absolutely chock-full of useful information. If anything, read just the last page, not the first page.

Well, I will say I loved it. Thank you. I'm going to ask you next who the target audience is, but I want to recommend your book for one audience, and it's particularly on point for folks that will be listening or watching this, which is that there is a large group of folks who are, maybe let's call them business CEOs or business leaders, line of business leaders that have never put code into production or never really worked as a partner with a CTO or an engineering leader. And they tend to view engineers as weird beasts, as folks that will type on a keyboard and produce code for them, as folks measured even just by story points and nothing else. And they'll quit, right? The best ones will all quit. And I say, if you don't— engineers are some of the most— the best engineers are the most creative people on the planet, right? I mean, I haven't written code since I was in high school, but the best ones, they're the 10x ones. You want to keep them, and you don't know how to work with them if you haven't. And read your book. The stories here of how to retain, attract, inspire, what the best folks are looking for, how to challenge them, how to get them to do how not to micromanage. I mean, you can tell me, we can talk about some of these stories, but this is the insider's guide to working with a great engineering team. This is what it is. There's great stories and others, but buy the book, read it if you're that person. Would you concur with that as a target persona?

Well, Jason, that's exactly what I had in mind when I wrote the book. So I'm glad that came through. Look, I've got a pretty unique vantage point as a software developer myself, but also the CEO of a company of a public company. And so I really see both sides of this equation, right? As a developer, I understand kind of what typically might go on in a developer's head, what skill sets they bring to the table, but also how the process of building software works. And it's complicated, and it's hard, and it's failure-prone. And so it's a complicated thing, but I also am a business executive. And so I've got like kind of the business side in my head, and I'm thinking about where we need to go as a company and the things we need to build. And I, like many business executives, can get frustrated. Like, of course we want better software shipped faster for, you know, with less people needed and all sorts of things like that. And so I sought out to write a book that tries to bridge those two worlds, 'cause I find that most businesses and many business leaders don't really know how to speak the same language as developers, don't really know what happens in the process of building software. And so the result is they get very confusing answers to what they think are simple questions like, "Can't you tell me what we're gonna ship?" when we're gonna ship it. You know, like what features it's gonna have and the date we're gonna launch it, because like, and it makes sense to you, like, of course we've got a marketing event, we got a big conference, we've got, you know, we got a launch date, we've got PR lined up, whatever. You need to tell me if we're gonna launch it or not. And the developers will give you this, well, you know, I can tell you when we're gonna launch it, but I can't tell you what it's gonna have in it. Or I can tell you what it's gonna have in it, but I can't tell you when we're gonna launch it. And it's like infuriating, you wanna pull your hair out. You can see I've had this conversation a lot. For people listening to the podcast, I am bald. And so it's like, you know, there's a lot of these conversations or these other ones, right? As a manager, you know, the basic tool that managers have is budget. And so, you know, if a project is late and it's, you know, not going to finish on time, what is our tendency is to say, okay, well, I'm just going to hand you a bunch more money and now it's going to be on time because you can just, you know, put more people on it. And the answer is, well, it doesn't really work like that. You can't just throw more money or people at a late project and expect it to catch up. In fact, if anything, that will make it further delayed. And these are totally counterintuitive answers to these simple questions that are really frustrating for business people. What I sought to do is to write a book that really tried to bridge the two worlds, to give a common parlance to both the technical side and the non-technical side, to be able to talk the same language, but also to provide a bit of context. The first part of the book, I talk about why this is so important. As many business leaders, I'm sure, already have found, software is becoming the lifeblood of nearly every company in every industry, because every industry is turning into a software industry. You know, Marc Andreessen, now 15 years ago, said software is eating the world. And of course, we look back and we say, wow, that was very prescient and he was right. But he didn't really talk about how that was going to happen. Like, he didn't talk about the talent that's needed, or like, you know, you might think the software writes itself in some sort of Terminator-esque, you know, apocalyptic future.

Or it can just be outsourced. It can just be outsourced magic.

Yeah. And by the way, when he said that in like the early 2000s, outsourcing IT was pretty much all the rage. It was thought of as cheaper, you know. Cheaper. And you said, oh, like, I just have these administering laptops and maybe I've got some big software to run my financials or my ERP or my HR. Okay, great. That is not differentiating. That's not how I'm going to win. It's not a core competency. I want to outsource it. But what happened over the subsequent 15 years is that the interface that most businesses have with their customers has become a digital interface. Think about your bank, right? You know, 15 years ago, 20 years ago, your bank was a storefront in your neighborhood that you walked into and you liked your bank if it was decorated nicely and it was clean and the teller was friendly and they gave your kid a lollipop. That was what made you say, I like my bank. But now your bank is a mobile app on your phone. And so the things that make you like your bank are, is the app fast? Does it work well? Are they innovating to provide new features and functionality that make my life easier? That's what makes your bank a good bank. And so in that world, IT is no longer something to be outsourced. It is the source of competitive differentiation in the eyes of your customers. And so very quickly, as one company figures that out and starts hiring developers and building software, listening to customers, and going through that iteration cycle of building software, and then learning from customers and building some more, One company starts doing that and the other ones take notice because that one starts winning customers' hearts and minds and wallets. Pretty soon, every company in an industry has to adopt that mindset too. I like to say that it used to be in the old world of IT, you had these classic build versus buy decisions. Are we going to build something or are we going to buy it? Now, it's become build versus die, because if you aren't building software that answers your customers' needs and your competitors are, there's a Darwinian evolution that comes along. The companies that are able to adapt most quickly to the changing needs of customers and the changing competitive landscape, those are the ones that are able to survive. The companies that essentially just bought an off-the-shelf solution and are sitting there as the world is progressing, and they're like, "Well, it doesn't do the thing our customers want. Oh, well." Well, guess what? Customers are going to notice, and eventually customers are going to choose to do business with folks who are meeting their needs better. That, in the modern economy, in the digital era, that is fueled by building software that customers love. And so the stakes for deploying developer talent and putting them to work building these great products and experiences that customers love, you know, the stakes have never been higher, because I think it is literally existential in many industries and for many companies that they become good at being able to listen to customers and build the software and the experiences that customers need of them in order to compete and win in the digital economy. And that's why the stakes are so high.

Yeah, it's funny, I was just looking at switching one of our banking relationships at Saastr. It's not at Twilio scale, but it's moving $20 million a year through a specialty bank. First thing on the Zoom was, "Well, our mobile app isn't very good." First thing out of their mouths.

That's not the first thing you want to hear.

At least they disclosed it. At least they are upfront. But rather than talking about all the other advantages they have, like, "We just got to tell you, you're a tech guy, our mobile app is not very good." And we still haven't switched our business. One thing on all this, you mentioned in the book that you first learned about sort of the two-pizza box style of building software back at Amazon, right, when you were an engineer. Let's push on that a little bit. What you've learned at Twilio, right, as an engineer turned founder turned CEO, how does that scale and what does it mean if you can't attract the top tier of talent, right? Can two pizza boxes build something if you can't attract— you're not— you don't have as high-profile companies as Twilio, if you can't build that type of engineering team? How does that work in practice? And does it work if your engineering team is not top tier?

Well, I think that, you know, everybody tends to think that these digital projects, first of all, need to be big. They need to be a big initiative, big endeavor, and they think that you need to have like large teams and you need to have, you know, a lot of money put them. And actually, I think that the opposite is quite true. I think that getting started small is the way to get started.

Yeah.

And that's where this two-pizza team comes into play, this idea that the engine of progress inside of a company is a small team, less than 10 people, who are focused on a particular customer and a particular customer problem, and those define the mission of that team, as well as the metrics of their success in solving that problem for that customer. Because First of all, the best talent doesn't want to work and feel like they're just a cog in the machine. They don't want to say, "Oh, I'm one of 500 people working in this company on a vague set of problems." It's like, yeah, that's just human. You want to have impact. And so that's the first thing. The second thing is when you're on a small team, you are very close to the customer and the problem you're solving. And so the abstractions that sit between you and your customers tend to melt away because you have to have proximity to the customer problem. You have to know what problem you're solving for the customer. In order to be a productive member of such a small team. One of the core ideas in Ask Your Developer is the fact that you should share problems, not solutions, with developers. So instead of saying, "Here, developer," in many companies, the idea of like there's business people, they're the ones who decide what we're going to build. They go out and talk to customers and they go out and write specifications documents, PRDs, product requirements documents, things like that. They throw it over the wall to developers, and then developers just write code that matches that specification, and then everyone's happy. The reality is that doesn't work out very well. If a developer doesn't know why they're writing the code they're writing, doesn't understand the customer's problem, like, sure, they can dutifully write code that implements some solution, but it may very well be wrong and the developer won't know it or won't care, and everything takes 10 times as long when there's no intrinsic motivation for like, oh, I'm writing, I'm writing a thing that's going to solve a big customer problem versus I'm writing a thing that meets a specification that I have no idea why I'm writing it. And so my belief is that by bringing your developers close to the problem, so share the problem, what is the customer problem or business problem we're trying to solve? Bring the full team into that problem and have them solve it. That's the essence of what small teams are able to do. And so you've got like a product manager, a bunch of engineers, maybe a UI designer, maybe a QA engineer. Like, you know, you, every company's got a slightly different way they orchestrate these teams. But ultimately, that team exists to solve the customer problem, not just to write specs that somebody in a far-off land wrote for them.

And how do you get them to talk to customers?

Well, there's a lot of mechanisms to get proximity between the developers and the technical talent and customers. I certainly, by the way, don't advocate that the developers spend all their time or putting them on customer support all the time. That wouldn't be the best use of a developer's time. However, as companies grow, it's very common for their walls to come up, functional silos to come up that are designed to, quote unquote, protect those developers from customers. I.e., like there's, you know, customer support has processes to prevent escalations to engineers.

[Speaker:JASON M. LEMKIN] Yes.

[Speaker:BRYAN_LAWRENCE] Or sales has, you know, sales engineering to prevent the sales cycles from having to interact with engineering. And product managers often see their role as, I'm here to protect my engineers from having to talk to customers. And so my main message is recognize that companies build up these systems that are designed to prevent customer interactions from engineers. And by the way, a lot of those are helpful. Again, I would say that, you know, you don't want every sales cycle to be in front of engineers. You don't want every customer support interaction to have to reach your engineers. But if you do that really well, what you end up doing is shielding those engineers from customer problems. And so what you need to do is poke holes in those silos. Ways to do that. There have been times at Twilio where we have all of our engineers take turns doing support, like 2 days a year, not huge.

Yeah, I like it once a quarter.

A day a quarter, exactly, and spend time with customers in that context. You get a very different sense of the things that customers are struggling with. I did that a few years ago, and I remember about 3/4 of the tickets I handled in that day were the same problem.

Same 10 calls.

There was a backend process that was not yet customer-facing, that 3/4 of the tickets I did that day were me operating this backend system on behalf of our customers, that they had to write into a ticket and wait, whatever, a day, 2 days for it to get solved for them. And the first thing I did after I finished my shift was ask, how come we haven't built this as a customer-facing workflow, right? It just seems to make sense if 3/4 of our tickets, at least that I handled that day, were about this. And so you get these instinctive understandings of things that need to get get solved when you have that direct customer interaction. I also believe that developers should periodically go on sales calls, you know, and they don't have— they're not like, you know, the center of the meeting. They're just, they're just tagging along. Basically, I want to hear directly from a customer what they're doing.

Everyone loves that, don't they? Everyone that's connected to the customers loves it. Yeah.

Everybody, you know, the salespeople love it. The engineers should love it. The customer would, would love it that you've got engineers who are interested in learning about their business and their problem. Everybody would love it, and it's like, great, you can do that for one day a quarter, one day every six months. This is not like onerous, but you need to poke holes in those silos if developers are going to get access to customers. But more than anything, it's sharing the problem. So if you go to a developer and you say, hey, I need you to build this, and you just specify out it's a form with a field that says name and it's got 40 characters long and blah, blah, blah, they'll write that. But if you go to a developer and say, hey, we're trying to make it so that customers can open an account in less than 1 minute, because our current thing that requires 10 minutes or an hour or 3 days or whatever it is, is slowing down our business and frustrating customers, then the developer can get to work saying, "Hmm, how would I design a really great workflow so that we can ease customer pain in this part of our business?" And those are the kinds of things that really make a difference, because now developers have this intrinsic motivation. It's like a challenge. You issue a challenge to the developer, How easy, how great can we make this? They will stand up to that challenge. But if you tell them we need a field that is 40 characters long, that's not much of a challenge. That's just a task, right? And so that's it. Now, you asked earlier, Jason, an interesting question, like, what if you can't get the best developers?

Yeah.

Now, I think this notion— look, certainly there's some developers in the world who are more productive than others. That is certainly true. However, you can't bet on having those engineers and you can't bet on their success. And even if you have one on your team, You can't bet on them staying at your company necessarily, nor do other engineers necessarily want to work with those types of engineers. So it's not really a strategy. It's not a strategy to say, I'm only going to hire these top 1%, 10x developers, and that's how I'm going to build my company. The strategy is, how do I take a wide variety of engineers and make them work together as a team to get consistently great output that's not hinged on any one person? and that is, I think, the small team and the focus on customer problems really help you to do that. Because early in Twilio, we would hire developers who also had offers at Google or Facebook or just big tech companies, and we couldn't match their salaries, we couldn't match their equity, we couldn't match a whole lot of what those companies were offering, but we could say is this, You are going to be really close to the customer problem you're solving. You're going to have a lot of autonomy to work with your teammates to figure out how to solve those problems. We're going to trust you to make some big decisions. By the way, you're going to be really important to the future of our company. That is something that, say, at Google with 50,000 engineers, and you're part of the team that owns the back button on Chrome. Am I really having impact on Google's future? Am I really having an impact on customers? Not really. I think that whatever your business is, you can basically tell a story about being a big fish in a small pond versus a small fish in a big pond. That's compelling. That's a really compelling proposition. One of the things I talk about in the book is I think one of the things that really helps developers want to take on those types of responsibilities is when they know they have the support of executives. So if you've got an executive at a company, a CEO or one of the C-suite members, actually giving that phone call to the recruit or to the developers and say, "Hey, I really value what you're doing. This is really important for the company. I really hope you'll join." That goes a long way. It does. And I tell the story of how the CEO of Domino's, The CEO, Patrick Doyle, recruited the head of technology. Domino's is this total sleeper success story. I don't know if you followed this, the stock. Domino's stock since in the last decade has outperformed Google and Amazon and Facebook and Google.

[Speaker:JASON M. LEMKIN] They had DoorDash figured out before we realized this was a market segment.

[Speaker:TREY LOCKERBIE] Right? But not only that, it's not like, oh, they had it figured out in the '90s, but then tech took it It's like their stock has outperformed nearly every stock in the same period of time as they reinvented themselves as a technology company. And they took all the, like, infrastructure they have, they have thousands of stores all around the world, they have a great brand, and they figured out, like, okay, if we're not going to get disrupted by A, another pizza chain, or B, just the whole world of delivery, we've got to become a tech company. And they have. And what the amazing thing is, is the CEO, Patrick Doyle, went to— was recruiting, and he talked to this guy, Kevin, who was the who he was recruiting as the head of technology. The story was he took the meeting mostly out of curiosity, but never thought he'd go work at a pizza company. The CEO said, "This is the single most important thing we're going to do in the next decade, and I want you to lead it." Suddenly, he took that job offer very seriously. He ended up joining, and then he did the same thing and recruited a great tech team out of Ann Arbor, Michigan, which is where Domino's headquarters headquartered where I went to school, and built this amazing story of technology. So this idea that like the CEO is there, and I tell the story about Barack Obama recruiting the founders of the US Digital Service.

Yeah, that's a good story.

It's the same story. It's an amazing story. Actually, my co-founder Evan at Twilio had recently left Twilio and was thinking about what he wanted to do next, and he got an email from someone with a White House email address saying, hey, Are you available for a meeting next week? He just sort of said, sure, I guess. They said, okay, show up at this hotel at this time. He shows up and there's a lot of security and background checks and all this kind of stuff. They take him up to the suite on the top floor, and lo and behold, they see Marine One fly by. Then 5 minutes later, President Obama walks in the door, says, I need you to help me build technical competency in the federal government. The healthcare.gov thing was a fiasco. Like, I can't believe we got all this landmark legislation passed to provide healthcare to every American, and it's going to fail because I can't get a damn website to work. He's like, I need you to come help fix healthcare.gov, and then help make the federal government as nimble as Silicon Valley is.

[Speaker:TREY_LOCKERBIE] Yeah, that was an incredible story in the book, right? I mean, of course, you're going to do that. But let me ask you the flip side. How do you get developers to work on the less interesting products? How do you get them to work on refactoring, on rebuilding, on bug fixes, on the nitty-gritty work? The best folks want to be inspired, right? They want to be inspired either by Jeff Lawson or President Obama or to work on hard problems. So how do we do this? How do we get great people to work on the less exciting parts of software?

Well, I think if you approach it from the perspective of it's not exciting, then you'll probably—

You'll fail.

Inspire that sense in the talent as well. The two things I would say is, number one, if you see it as, "I need you to fix bugs," you're like, "Well, that doesn't sound very exciting." But if you see it as, "I need you to own this thing that our customers care about." Yes. And make it great, and every day make it better, and make customers love it even more. That's a very different way of phrasing what you need to do, because part of that is listening to customers and understanding, you know, what features and functionality we need to do. Sometimes it's making the thing faster, and sometimes, yeah, it's fixing bugs. But when you're an owner, you actually take pride in that. Like, you know, I don't know about you, but, you know, around your house, do you pick up the trash?

Yeah.

Is it exciting? No. But do you do it because you own, you know, you're like an owner, you feel responsibility for the place where you live? Yes. And so instilling that sense of ownership, I think, is how you actually get everybody to care about even, you know, the more mundane parts of whatever someone's job is. And the second thing I would say is there's certain engineers who are great at inventing the new thing. They're great at building that prototype and like, you know, pushing the boundaries out. And there's other engineers who aren't as good at that. They're not as good at inventing the new thing, but they're better at maintaining, they're better at scaling, they're better at fixing bugs, making things more efficient. And so understanding the types of talent, the fact that some developers are inventors and some are more maintainers, it's kind of like, you know, I make a lot of comparisons to sales in the book because I figure that a lot of executives have figured out how to work with their sales teams, maybe more so than they've figured out how to work with their technical talent. And one of the comparisons that I would make in sales, a lot of people have an intrinsic understanding of the fact that in sales, you've got hunters and farmers, and it's two skill sets. The hunters are really good at going out there into the world and drumming up new deals with new customers and just forging their way into a new organization and figuring out how to navigate it and get to the decision maker and make a deal happen. Then other people are really good at farmers. They're good at maintaining those relationships. They're good at doing the upsell over time, and they're good at getting the renewal and making sure customers are happy. Those are just two different skills that you need on a sales team in order to win. The same thing goes for developers. You've got the developers who are really good at forging the new thing and inventing the new thing, and they can write a ton of code in one afternoon that invents a new product. There's other developers who are really good at maintaining and scaling and ensuring the health of existing products. So getting the right people in the right seat is the way to think about that.

All right, let me talk about something related, which is the role of product and engineering together, the functions. And if I— I didn't literally use a highlighter when I read the book, but I did take notes. I would say the number one most important thing for me, my takeaway is you say again and again, we talked about before, assign problems, not tasks to your developers, right? And so to me, that's the most profound insight for business folks. You've got to assign problems, not tasks, or it will break. But to dig in on that, one is that group of developers, engineers you talked about who are very creative and can build that first V1 out of nothing, right? That creativity has high overlap with the head of product, right? In fact, sometimes they are as good or better a— they certainly don't need a PRD or a spec in many cases because they've already envisioned it in collaborating with you, right? But many engineers are not that creative, right? They do need that help. They do need that spec. So what's the role between a product and a developer engineering function, how do you as business folks understand that line and make sure that the product team isn't assigning tasks, right, or breaking things, and how do they leverage each other successfully?

You know, I think the role of the product team in many ways is to direct the focus of the rest of the team. So the product leadership, like let's say the head of product, well, Their job is to really figure out what teams do I want to have and how much budget and how much staffing do I put against the various problems and the various customers we could be serving.

Yes.

So if you say, hey, I'm in this market and I'm in that market, I want to solve this problem, that problem, I want to go experiment, I want to go figure out if there's a problem I can solve for that customer. The head of products, their job is really to decide how much budget we should put against the various things we could be going to solve. So you staff the teams and you focus them on a customer segment or a customer problem. Within the teams, then you've got a division of labor. I think the product leader's job is to try to direct the effort and instead of prevent developers from like having to interact with customers, is facilitating the understanding of the customer for the rest of the team. And that can be by bringing customers in, that can be by sharing stories that they've learned from customers, and a variety of things. But ultimately, their job is to facilitate an understanding of the customer need and the customer problem for the rest of the team, and then divvying up the problems that they're going to share with that team in order to get them working on solutions. Now, I don't think it's like purely the developer's job to, to solve every problem, right? The product leadership hopefully has great insights as well. So it's not to say that the product managers shouldn't be involved in understanding like how they're going to solve problems for customers. However, my point is mostly that it is certainly not an exclusive job of the product manager. To answer that question and then just hand the answer to the developers. It's got to be a shared— it's got to be a shared— I love the idea.

I had not— I'm embarrassed I hadn't thought of it before— of your head of product or your product team's job, their KPI is to make sure your developers are connected to your customers. It's easy to say that, but whose job is it, right? The CEO would be great. The CEO can't do everything, right? So if your head of product has a KPI, make sure all your developers have one customer interaction a quarter. That could be magical right there, right? If they own that KPI. Yeah.

I shared this great story from one of the product leaders at Twilio. His name is Ben. And he was— before he was at Twilio, he was a CTO of a startup. And before that, his first job out of college was he wrote code at a large technology service. Okay, it's Bloomberg. He worked at Bloomberg on the terminals. And he was, you know, his team had one of the little widgets you see on the screen, like, you know, you've seen the Bloomberg terminal, and there's like 1,000 widgets everywhere. Well, his team owned one of those widgets. He joined the company, and one of the first things he asked his manager is, "Hey, when do I get to actually talk to a trader who's using my software?" The manager said, "Oh, that's a really interesting idea. We've never done that." Ben, he's bright-eyed, bushy-tailed, just out of college, like, "Oh, really? I'm surprised that we've never talked to a customer. I'd love to do it." But the manager was like, "Well, we just don't really do that." Ben just found a friend of his that was a trader and said, "Hey, do you mind if I swing by the trading desk?" He did that, and the friend showed him, "Oh yeah, here's the Bloomberg terminal. Oh yeah, here's your widget right here." Ben was floored because when they were writing this thing, when they were writing this widget, he had assumed that it was the full size of the screen, like this giant 24-inch screen, his widget was the star of the show. Instead, it was like this tiny little thing in the corner of the screen, that was like, you know, 24 pixels by 24 pixels, and it was totally illegible. In fact, he was startled that the trader could even discern anything from this little chart. And Ben went back and he was like, "Wait, we have to rethink how we do fonts and how we do sizing, because the reality of how people use this is so different than how we all imagined it when we built it." And, you know, it's just a great insight that they never would have had if they didn't actually go work with a customer and talk to them. And so like that mindset has got to prevail. And the idea that your product team is there to create those sort of interactions, I think is a really healthy way to think about it.

All right, two more things I want to hit before we run out of time from the book and from you. One thing you say, which I just want to ask one because we could spend a lot of time on it, which is in the book, ask your developers what services you should be buying. Obviously Twilio is at the center of that. You have line of business buyers and developers. I was just getting caught up on Fastly. You know, Fastly is 90% enterprise, 90% deals over $100K, and they said, that the majority of their $100K deals, the developer makes the decision. Now that's a CDN, of course, right? But I guess a meta question for you, in the world of not just APIs, but low-code and no-code, is the developer's role getting even more and more important in these buying decisions? And should you empower them even more? Or where's this trend going in the next few years?

Well, I think we're still at the early stages of this trend. If you think about the fastest growing companies in the history of software, AWS, Stripe, Twilio, none of us provide solutions. We provide building blocks. We provide what is essentially the supply chain for the digital era. If you think about it, every mature industry has a mature supply chain. I'm from Detroit originally, so like the auto, you think about the auto industry and the mature supply chain they have there. 20 years ago, the software industry was a very small number of companies, anything Microsoft, Oracle, whatever. They built everything themselves, but now that every company is becoming a software company, well, you need a robust supply chain to power that. That's the industry that Twilio and Stripe and AWS are really the pioneers of, in creating this mature supply chain for every company to become good builders of software. I think this trend is at the very beginning. Now, you asked about low-code, no-code, and are developers getting more important, less important First of all, I do take a pretty broad view of builders. There are many types of builders inside of companies, and it's not just the software developers. There are a wide variety of folks who, given the right tooling, will be able to really impact companies by building. The big change here isn't like, oh, there were no developers and then we discovered software developers or anything like that. The real change here is in the cost of innovation has gone down so dramatically. That that is what is driving the change in the tool and the supply chain, right? So think about 20 years ago, you know, in the '90s, and you needed some software, you needed an ERP system, right? Like that was a multi-million dollar, multi-year implementation timeframe, huge decision. Only the CIO could make such a big decision. In fact, implementing it took so long that frequently, you know, you'd have more than one CIO involved in leading that program from its inception to its completion. And by the way, its completion was far from guaranteed. It's something like 60% of those projects failed to ever deliver value anyway. So it's like, you have this big multimillion-dollar— I call it the era of high-stakes software. And in that world, when you have essentially one buyer inside of a company, look, there's only so much, there's only so many projects that can get undertaken. But now you look at the technical advancements that have happened of multi-tenancy, and obviously the internet and the cloud and all this kind of stuff, where now a developer can get started using Twilio for a penny. And they can sign up on a website and get started within a minute. And that just changes the whole calculus of how companies adopt the vendors and the tools that they need in order to succeed because it's not a big decision. It is a very small decision to start building and to test the waters of some idea. You know, one of the other core ideas in the book is experimentation is the prerequisite to innovation.

Yep.

And every big idea starts small. And so the more things that you can try, the more experiments that you can run, the more likely a company is to run into the next big thing. And so the ability for a developer to get started with very, like, no commitment, like there's no long-term big decision that's been made when you put in your credit card and spend a dollar to start prototyping on an idea, the cost of failure is negligible. And so our job is to encourage people to start experimenting, to start building, because our chances of finding the next big thing are a direct function of how many things that we try. I love that Bezos comparison to the baseball analogy. He says, we often talk about taking swings at business opportunities. And he says, I love that analogy, but the idea, the one place where it falls apart is in baseball, every swing at the plate, the very best you can do is hit a grand slam. That's the best outcome possible in baseball. You get 4 runs. And in business though, when you take a swing, the best you can do, you can, you can hit a million-run homer in business, especially on the internet and the scale of internet businesses. If you have the right idea, you can hit a million-run homer. And so that makes it even more important to focus on more swings at the plate. And that's what APIs and the low cost and the low risk of innovation that the API ecosystem brings to every company. And so I think that it's The best leaders are the ones who aren't looking for reasons to say no to new ideas. They're looking for reasons to be able to say yes to new ideas. But the whole thing is treat them as experiments and start small and iterate your way towards better and better and bigger and bigger things. But every big idea starts small and try lots of things, and the API ecosystem allows you to do it.

Do you think that— that I've certainly seen— do you think business process change management has kept up? I mean, if I, if I'm allowed to use my credit card at Big Co and use Twilio for a dollar or nickel, right, that's great. But business process change is still tough to absorb in big companies, right? And so you can, you can experiment, but deploying things into production, uh, it's tough to do that even more than once a year sometimes, or once a decade for certain applications. How many times are you going to change your communication stack, right? Once a decade maybe.

Well, that's where there's certain process things and certain platform things that companies need to focus on if they want to be successful in this era. So the platform things are you need to build a platform that enables your developers to do that good work. And so I talk a lot in the book about the infrastructure you need to empower developers to do their best work. And again, I make the comparison to sales. Like if you're an executive and you've got a relatively good understanding of how sales works, like you know that you don't just send salespeople out into the field with a paper notebook, right? You give them CRM, there's sales enablement, there is all sorts of tools that they use to actually do their job. And you recognize how important it is for making those salespeople very expensive hires, good salespeople. You spend a ton on them. You want to make them productive. You want to help them close their deals. And by the way, you know that if you don't provide them with a good CRM system and good process and, you know, good lead management, blah, blah, blah, blah, like they're going to quit. They're going to find a company where, you know, they are going to be more successful. And so you invest in all this infrastructure. The same thing goes for developers. You need infrastructure to make developers successful. That's infrastructure to help them write code, to help them ship their code to production, help them test that code, help them make sure that it is stable, logging, alerts, notifications, blah, blah, blah, blah. And your job with that infrastructure is to make every developer on your team more productive. And it's not at all uncommon for great software companies to spend upwards of 40%, even 50% of their total R&D budget on those platforms, because those investments are multiplying the investments that you're making in the other 50% of your R&D investments. Every customer-facing team is made that much more productive and successful by having that infrastructure. And so if you are a company that can ship code once a year, I mean, I would say that you need to invest in those platforms to enable that iterative spirit of software, if you're going to keep up with the pace of innovation that's going on right now. And the second thing is process-wise. And a lot of companies have very legitimate concerns around, oh, well, we love to iterate quickly and experiment and let a developer build something quickly, but this is handling customer data. It has got the brand name of our company on it. So if it goes sideways, it could be a black eye for the company, or if we have a security vulnerability because we built something fast as a prototype, That'll obviously break customer trust. And those are very legitimate concerns. And so the things I would say is, first of all, read Eric Ries's book, The Lean Startup, on how to iterate and innovate very cheaply, quickly, and inexpensively. And a lot of the ideas that he brings forth in that book are relevant here. Like, okay, how can you test an idea without actually handling customer data? Or how can you prototype it in a tool that doesn't need you to deploy to your production environment? Could you build something— a lot of people are worried like, oh, if we try an idea and it sucks and we shut it down, then we're going to let down our customers. There's going to be a lack of customer trust there. And so one way to do it is, great, just start it as a— buy a domain name for $7 and run your experiment there. Now, look, I'm not advocating that you should— just because you bought a cheap domain name, you should mishandle customer data. No, you have to do that really well. But I would say, how do you minimize the scope of the data that you're handling? Or how do you use sort of pre-secured assets, like even just basic off-the-shelf tools like Google Spreadsheets and things like that, at small scale for that experimental phase, are easy to use, are fast, are cheap, and out of the gates, Google makes sure that that core infrastructure is secure. So there's certain things that you can do to do a rapid experiment at small scale, and then when you've proven a hypothesis and you say, "Wow, this is a great idea, instead of having a dozen customers playing with this thing, I want millions of customers," Well, that's when you go back and you say, okay, great, how do we get it into our real production environment? Or how do we apply the full gamut of testing and whatever we're gonna do to it? That's where you wanna make sure, of course, that you've buttoned it up. But a lot of people put that step first. They're like, well, if we're gonna do anything, it's gotta be in our production environment so that it's behind the firewalls and blah, blah, blah. And you think about it, that's mostly a statement about process versus, actually getting the goals you want, because the goals you want are to experiment quickly, learn quickly and inexpensively, while keeping your customer information safe. And so your policies should encourage you to achieve those goals, as opposed to say, well, you know, 20 years ago, the way we knew to keep our customer information safe was to put it all behind this one giant firewall. You're like, well, actually, a lot of ideas about that sort of security have moved on. And so Maybe it's time to revisit to allow certain low-scale, early-stage experiments to run with a different set of policies to encourage that innovation, recognizing that you need a balance of those, and that as that gets bigger, then the stakes get higher, and you can maybe apply your more traditional policies to it as it scales.

[Speaker:TREY_LOCKERBIE] Makes sense. All right, so last thing I want to hit before we're out of time— maybe we're already out of time— but you have a whole chapter in the book, which is one of my favorite parts on recruiting and hiring developers and sharing that learning for folks that haven't done it before. Now it's 2021 and we all became distributed companies. What's changed here in recruiting? How are you thinking about this, especially as a passionate advocate of San Francisco, right? And probably the office to some extent, right? How has this changed? Has the world totally flattened? Can I hire developers from Aruba and Bali? Is it a brand new world? How are you thinking about this everyone's distributed world?

Well, you know what's interesting? I am a believer in San Francisco, but it's not because I believe San Francisco or the Bay Area has a monopoly on talent or ideas or anything like that. I'm a believer in San Francisco because it's where I live. And I believe that everybody should invest in their local community, like wherever you are, and especially if you're in a position of privilege. and we in technology certainly are. I mean, most of our businesses have fared fairly well because we have a lot of knowledge workers, because our products tend to be relevant to the world. I think it's incumbent upon us to invest back in our communities because so many other parts of our communities have not fared well. Obviously, there's a catastrophe going out there for a lot of workers, a lot of industries. And so let's invest in our communities. Let's help our communities in this, the generational time of need that we are looking at currently. As opposed to bailing on those communities. So that's what I believe. I believe in San Francisco because I live here, and because I want to invest in our community, and I want others to do it too. But wherever you are, invest in your community. That's the main point. As far as talent goes, look, there's talent everywhere. And I think that reaching into pools of talent all around the world is a great thing to do, because there are talented people that can help you build your company in all sorts of places. The key thing, and you get to decide in some ways what you want the culture and how you want the operating system of your company to be. I won't use the word culture there, but the operating system. And everybody's got different beliefs. They have beliefs that people sitting in the same room are better than people who are distributed. I won't pretend to say there's one answer to that question. All of the above can work. But I think you need to decide what you want it to be and then execute that really well. I think where folks get into trouble is when they don't have a point of view and they have some people and a small team who want to be in the office and work together and other people on that small team who are 12 time zones away and can't collaborate together. It's like, those are the messes you create. And so I believe that having a team that works in a good way together is the most important thing. So if that team is distributed, that can work very well. My recommendation, keep them within 3 time zones of each other. So you've got a maximum amount of overlap in the workday so that they can collaborate. Effectively. But the nice thing about small teams is some of your small teams can be virtual, some of your small teams can be sitting in the same room together, once that's a possibility again. And so what's most important is that at the small team level, you've got a working style that is successful, and different teams can have different working styles. And that's what's nice about those small teams. And so I would say, look, you know, one is, you know, decide if you have a strong belief as a founder, as an executive, and recognize that whatever your strong belief may be will have impacts on the types of talent you can hire. And it's just a trade-off. Do you want to have a bigger talent pool, but then manage logistics of a distributed company, which aren't that hard, in a lot of ways easier than this more centralized company? Or would you rather have people who can build the camaraderie face-to-face on a regular day-to-day basis, and recognize that you will then focus on hiring in a certain locale and have an office? But I mean, these are all obvious things. There's nothing reinventing presented here. It's just made it— the only thing that's changed because of COVID in my thinking is that so many folks, I'd say myself included, who just had the default assumption that we're going to be in the same place and we're going to be in the same office as the norm, and there's always exceptions, but the norm is people sit in the office together. It got proven to us by fire here that it doesn't have to be that way, that people can work virtually, largely be successful. And that doesn't mean that there aren't a whole lot of people who do want to go back to that face-to-face interaction, but a lot of people who maybe assumed that for their career they have to be in a certain place and show up at a certain building for work every day, they've also realized, huh, you know what, like, I can be a place where I'd rather live and still get my job done. And if the company I work for doesn't recognize that, then maybe I'll find a company that does recognize that. And so I think agility and flexibility. I think like within Twilio, I suspect when we can go back to offices, there will be a bit of a team shuffling going on, because certain teams will say, "We want to be back in an office," and other teams will say, "We're really happy virtual," and people will find the teams that match their working style. And it benefits us to be flexible, to be agile, and allow those teams to reconfigure, because if we don't allow them to reconfigure that way, then people are going to say, "Oh, well, if Twilio doesn't fit the way I want to work, then I'll go find the company that does." And obviously, we want the talent to be successful at Twilio, and we want them to find the team within Twilio that will best enable that. So I think every company, if you think about agility to your workforce as opposed to one way for the entire company to operate, I think that's probably the answer to how companies are going to end up reconfiguring once the quote-unquote normal office spaces are open again.

Yeah, it's funny. I think your point of assumptions we had before may have changed, like everyone has to be together. I think we may find there's more like the 3-time zone point you made, right? More than 3 time zones and stuff. I've invested in a lot of Euro-US SaaS companies where that 3-time zone thing was very visceral, right? And it was brutal on companies. I've invested in 5 Parisian companies in the US. But you know what I've learned since COVID They're all cool with it now. That 3-time zone thing has broken apart and we've had no choice and we've gotten through it. But I love the idea that I know what you said, it's obvious, but you have to have a point of view now as we come out of this, right? You have to take these learnings and have a strong point of view and execute on whatever that cultural point of view is so that you come out of this with a, with a plan, right? And a point of view of what's going to work for you because it's going to be much broader than it was before. Would you hire if you had, if you had another C-level executive hire, would you hire someone in Paris or London or Miami now? Do they have to be in the Bay Area? Do you care as much?

Oh, we already have a distributed executive team. We have a head of product who lives in Seattle. We have a— our chief people officer spends about half her time in San Diego, and obviously these are in the same time zone, which is nice. I just hired a chief of staff who's in New York. So we already have a fairly distributed executive team, and I think that works. Again, I would stick to probably the 3-time zone thing. The challenge, you know, I think what's nice about about, you know, kind of small teams. Like think about your teams. Teams are the core unit of execution in a company. So a team should be within 3 time zones, but another team can be halfway around the world. The only thing that changes is teams, what makes teams work is they tend to be informal in their interactions. And the further away another team is or the other team members are, the more formalized those interactions tend to have to become for it to work. That's why I like a team team to be relatively close, because you can have that informality. And then if another team is halfway around the world, that's fine too. You just have to then formalize the interactions between those two teams. It's all doable. But if you have to formalize the casual interactions that team members often have, I think that's where it gets really hard and taxing and a lot more really late night or very early, you know, interactions that, you know, get right trying and people— people just wear out from it.

Alright, so www.askyourdeveloper.com. I've read it. If you have or haven't, if you're managing an engineering team, a product team, developers for the first time or the sixth time, read this book. If it's the first time, your eyes will be opened. It is different than most of us think. If it's your sixth time, you'll nod your head when you read Jeff's and other stories and you'll realize why you made some mistakes and why you're doing better. Any other last thoughts you want to leave us on the book or in general in 2021, Jeff?

Well, thank you, Jason. I appreciate you reading it. I appreciate your kind words. I also want to point out that all the proceeds from the book are going to help more people, especially those from underrepresented populations, enter the technology field. And so the proceeds are, are supporting organizations who are educating folks like veterans. There's an organization, NPower, uh, Europe, who helps young adults, uh, particularly from Black and Latinx communities, to enter the technology field. SMASH, which helps high school students enter fields of STEM, particularly Black, Latinx, and Native American populations, as well as Black Girls Code. And so a lot of really amazing organizations are out there helping folks enter the field of technology and create a more diverse and inclusive industry for us. And so we're proud to be supporting those organizations with the proceeds from the book. So if you do buy the book, know that you will be helping those organizations because all proceeds are going to help them.

All right. Well, thank you, Jeff. I look forward to the second book, hopefully sometime early 2022 or so. We can riff on topics if you want, and we'll talk to you soon. Thank you.

Thank you, Jason M. Lemkin.