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

All right. Hey, everyone in the Saster community here with one of our favorite and Most iconic cloud CEOs and founders, Jeff Lawson. Jeff has done great things with the Saster community going back to joining us just after Twilio IPO'd, I think, at the 2017 annual. He was actually, I think, gonna 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, you know, when Covid started and we all got locked in our homes, I was like, okay, well, at least I'm gonna read a lot. And I feel like I've read half of many books, half of many books during COVID and. But nonetheless, you usually get. You 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 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 and I want to. 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'll 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 ship, 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, 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, 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 great projects, 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, 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 skillsets 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 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 going to ship and when we're going to ship it? You know, like what features it's going to have and the date we're going to launch it. Because like, 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 going to launch it or not and the developers will give you as well. You know, I can tell you when we're going to launch it, but I can't tell you what it's going to have in it, or I can tell you what it's going to have in it, but I can't tell you when we're going to launch it. And it's like infuriating. You want to 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 there's a lot of these conversations or these other ones. As a manager, the basic tool that managers have is budget. And so if a project is late and it's 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 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. And so 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. And 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 apocalyptic.

Or it can just be outsourced. It can just be outsourced. Mat yeah.

Or 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, you know, I just have these like, you know, administering laptops and maybe I've got some like big software like to run my financials or my, my ERP or my hr. Okay, great. Like 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. And pretty soon every company in an industry has to adopt that mindset too. And 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? And 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 and the companies 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. And 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. And that in the modern economy, in the digital era, the 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, 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 Saster. It's not a 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 up front. But rather than talking about all the other badges 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 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. 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 a lot of money put towards 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. And 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 there's business people, they're the ones who decide what we're going to build, and they go out and talk to customers and they go out and Write specifications, documents, PRDs, product requirements documents, things like that, and they throw it over the wall to develop developers. And then developers just write code that matches that specification and then everyone's happy. And the reality is that doesn't work out very well. But 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 be 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, for like, oh, I'm writing a thing that's gonna 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, every company's got a slightly different 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 like the developers spend like all their time or like 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, for their walls to come up, functional silos to come up that are designed to quote, unquote, protect those developers from customers. That is like there's, you know, customer support has processes to prevent escalations to engineers.

Yes.

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 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, you know, ways to do that. There have been times at Twilio where we have all of our engineers take turns doing support, you know, like two days a year. Not huge. 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. You know, I did that, you know, a few years ago and I remember about three quarters of the tickets I handled in that day were the Same.

Problem, same 10, same 10 questions.

There was a back end process that was not yet customer facing that. Three quarters 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, two days for it to get solved for them. And the first thing I did after I finished my shift was I asked how come we haven't built this as a customer facing workflow. It just seems to make sense if three quarters of our tickets, at least that I handled that day were about this. 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 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, like 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 one minute, because our current thing that requires 10 minutes or an hour or three days or whatever it is is slowing down our business and frustrating customers, then the developer can get to work saying, 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. That's it. Now, you asked earlier, Jason, an interesting question. What if you can't get the best developers? 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 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, like, you know, top 1%, you know, 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 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 like, Google or Facebook or just big tech companies, and we couldn't match their salaries, we couldn't match their equity. Like, we couldn't match a whole lot of what those companies are 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. And we're going to trust you to make some big decisions. And by the way, you're going to be really important to the future of our company. And that is something that, say, a 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. And that's compelling, for sure. And that's a really compelling proposition. And 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. If you've got an executive at a company 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. And I tell the story of how the CEO of Domino's, the CEO Patrick Doyle, recruited the head of technology. And Domino's is this total sleeper success story. I don't know if you followed this. The stock, the Domino's stock since in the last decade has outperformed Google and Amazon and Facebook.

Doordash figured out before we realized this was a market segment.

Right. But not only that, it's not like, oh, they had it figured out in the 90s, but then tech took it over. 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 infrastructure they have. They have thousands of stores all around the world. They have a great brand and they figured out, 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, the CEO Patrick Doyle was recruiting and he talked to this guy Kevin, 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. And 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. And 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 is headquartered, where I went to school and built this amazing story of technology. And so this idea that 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.

Same story. It's 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? And he just sort of said, sure, I guess they said, okay, show up at this hotel at this time. And he shows up and there's a lot of security and, you know, background checks and all this kind of stuff. And they take him up to the suite on the top floor and lo and behold, they see Marine One fly by. And then five minutes later, President Obama walks in the door, says, I need you to help me build technical competency in the federal government. You know, the healthcare.gov thing was a fiasco. Like, I can't believe we got all this landmark legislation passed to write health care to every American and it's gonna 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.

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, if you approach it from the perspective of it's not exciting, then, you know, you'll probably inspire that sense in the talent as well. The two things I would say is, number one, if you, 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 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 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 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 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. Efficient. And so understanding the types of talents, 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 at their sales teams, maybe more so than they figured out how to work with their technical talent. And, you know, 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. And 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. And those are just two different skills that you need on a sales team in order to win and the same thing goes for developers. You've got the developers 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. And 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 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. It can build that first V1 out of nothing. Right. That creativity has high overlap with a 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 a 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.

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'm going to 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 preventing 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 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 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.

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.

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 a thousand widgets everywhere. Well, his team owned one of those widgets and 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? And the manager said, oh, that's a really interesting idea. We've never done that. And Ben, he's like bright eyed, bushy tail, 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 sort of like, well, we just don't really do that. So Ben just found a friend of his that was a trader and said, hey, do you mind if I swing by the trading desk? And he did that. And the friend showed him, oh yeah, here's the Bloomberg terminal. Oh yeah, here's your widget right here. And 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. And instead it was like this tiny little thing in the corner of the screen and that was like 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 build it. And 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 is 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 the majority of their 100k deals the developer makes a 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 developers 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, I mean 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 you think about the auto industry and the mature supply chain they have there. And 20 years ago the software industry was a very small number of companies, anything, Microsoft, Oracle, whatever. And so they kind of built everything themselves. But now that every company is becoming a software company, well, you need a robust supply chain to power that. And 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. And 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 in the 90s and you needed some software, you needed an ERP system, right? Like that was a multimillion 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'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 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 four runs. And in business though, when you take a swing, the best you can do, 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 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, 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, you know, if you're an executive and you know, 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, 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 and D budget on those platforms because those investments are multiplying the investments that you're making in the other 50% of your R and 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. Can 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 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 or cheap, and out of the gates, Google makes sure that that core infrastructure is secure. And 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 going to do to it? That's where you want to 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 going to do anything, it's got to 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, 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, 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.

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, 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 and probably the office to some extent? 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? You know, 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 really the operating system of your company to be. I won't use the word culture there, but the operating system. Do you. And everybody's got different beliefs. They have beliefs that people sitting in the same room are better than people who are distributed. And like 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 three time zones of each other so you've got a maximum amount of overlap in the workday so that they can clash 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 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 the 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 reinvented 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 assume 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, I think we may find there's more like the three time zone point you made, right? More than three time zones and stuff. I've invested in a lot of euro US SaaS, companies where that three time zone thing was very visceral, right. And it was brutal on companies. I've invested in five Parisian companies in US but you know what I've learned since COVID they're all cool with it now that three 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 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 culture 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 barrier? 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 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 hired a chief of staff who's in New York. So we have already have a fairly distributed executive team. And I think that works. Again, I would stick to probably the three time zone thing. The challenge. I think what's nice about, you know, kind of small teams, like thinking about your teams. Teams are the core unit of execution in a company. So a team should be within three 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 to be. 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 interactions that get trying and people grind. People just wear out from it.

All right, 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 supporting organizations who are educating folks like veterans. There's an organization, npower Europe, who helps young adults, particularly from Black and Latinx communities, to enter the technology field, smash, which helps high school students enter the 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 could riff on topics if you want, and we'll talk to you soon. Thank you.

Thank you. J.

It.