a16z Podcast - Developers as Creatives

Episode Date: January 13, 2021

The rise of developers -- as buyers, as influencers, as a creative class -- is a direct result of "software eating the world", and of key shifts in IT from on-prem to cloud & SaaS to the API economy, where application programming interfaces are essentially building blocks for innovation. Developers therefore not only play an outsized role in high-performing tech companies -- but managing and motivating them is actually critical in ALL companies, since every company is a tech company (whether they know it or not).As every industry turns digital, and a company's interface to their customers IS software, "asking" one's developer is the key to solving business problems and to thriving not just surviving, argues Jeff Lawson, CEO and co-founder of cloud communications platform-as-a-service company Twilio, in his new book, Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century. So in this episode of the a16z Podcast in conversation with Sonal Chokshi and David Ulevitch (who previously argued "the developer's way" is the future of work), Lawson shares hard-earned lessons learned, mindsets, strategies, and tactics -- from "build vs. buy" to "build vs. die", to the art and science of small teams ("mitosis") -- for leaders and companies of all sizes.But what does it mean to truly treat developers as creatives within an organization? What does it mean to be "developer first"? And how does this affect customers, product, go-to-market? All this and more in this episode.

Hi everyone. Welcome to the A6 and Z podcast. I'm Sonal and we're here with our first new episode recorded this year. And it's with Jeff Lawson, the CEO and co-founder of Cloud Communications Platform as a Service Company, Twilio. He's the author of the new book just out today called Ask Your Developer, How to Harness the Power of Software Developers and Win in the 21st Century. It's super relevant, obviously, since developers play an outsized role in high-performing tech companies, but are also actually in all companies, given software has eaten the world. And as we've seen with the pandemic, education and health care, and pretty much every organization is now reliant on tech. In fact, every company is a tech company whether they know it or not. And so the book and our discussion is really more broadly about what it means for companies of all sizes and types to innovate. Also joining us is A6NC General Partner David Ullovich, former CEO who's seen both sides of small startups and big companies, and who has talked about, quote, the developer way as a future of work for everyone, not just developers. And so I asked him to jump in and join me before he had to

leave a bit early. We cover the rise of developers as a creative class and what it means to organize that plus influence within a company, briefly touch on techniques like hackathons for doing so, and then wrap up on organizational best practices around team size, scaling, and more. Throughout, we, of course, thread the trend of APIs or application programming interfaces and the API Economy, which we've talked a lot about here, and you can find those pieces, explainer videos, presentations, podcasts at A6NC.com slash API Economy. Okay, so that's the intro. Since I hate starting off with the Why'd You Write the Book question, Jeff, I'd love to instead start with the big picture, which is that we've seen three eras of software, from on-prem to cloud

and SaaS to the API economy, you not only outline these shifts in the book, but you go further and argue that software is a new supply chain. So I'd love to hear more about how you think about that to start us off. Yeah, thank you for asking so on all. I mean, it's interesting. I come from Detroit, the automotive capital of the world. And so I grew up around cars and so many people that I knew, you know, if they didn't work directly for the automaker, they worked for a company that supplied the automakers. And it was very easy to understand the very sophisticated supply chain. And it was very supply chain that allowed them to manufacture a complex thing like an automobile. General Motors doesn't have to manufacture every little bit and piece of that car. There's companies who specialize

in speedometers and headlights and seats and all this kind of stuff. They just pick the vendors that are going to help them get to market as quickly as possible with the best product. And that's what finally the software industry is developing. Software's obviously been around in some form or another for 50 years and in its modern internet-enabled form for close to 30 years. I was a developer starting in the 90s, writing code. Back then, you basically had to write it all yourself, and you can pull in some open source stuff here and there, but building software has gotten easier and easier and easier

because sophisticated APIs and abstractions and all this kind of stuff. However, the scale of the Internet and building applications at Internet scale has gotten so much harder. And so if you think about the progress that's happened over the last decade or so of APIs that run in the cloud, if you need a piece of a functionality, whether it is compute, storage, payments, communications, maps, you name it. All you need to do is sign up, put in a credit card, and plug in the few lines of code, and now your app is supercharged with these powers. What that really is is the development

of a supply chain for building software. That's great. And so, I mean, you're basically saying software is innovation in that context, and we totally agree, obviously. The obvious next question that begs is what do you build versus buy? In your book, you had a really neat rule of thumb, which is that software that faces your customers you should build. Anything where your customers will be saying, why doesn't it do X? And your answer is, well, the thing we bought doesn't do X, et cetera, et cetera. You basically argue that you can't buy differentiation. You can only build it. So talk to me a little bit more about that and really where do people then compete? Because if everyone has access to the same APIs, like where is the differentiation?

Absolutely. You know, something happened over the last 15 years, which was software went from the back office to the front office. It went from being something customers don't care about to something they experience every day. The remote control in our pocket. It's how we interface with the companies we do business with. You know what I called my iPhone for a while? I called it my summoner. Yeah, exactly. Think about your bank. 20 years ago, your bank was a storefronts that you walked into. It was clean. The teller was friendly and they gave your kid a lollipop. Okay, I like my bank. And now your bank, of course, is a mobile app. Suddenly, the interface you put in front of that customer is the perception of your product

and of your value as a company. You like your bank if the mobile app is fast, if it is bug-free, and if it has a lot of features and functionality and make your life a little bit easier, back in the days when it was back office, it would be common for IT departments to say, okay, let's we build versus buy. And a vendor would inevitably come in and say, don't reinvent the wheel and you just bought something off the shelf. But now in a world where the software you use is your source of competitive differentiation. The act of building is the act of listening to your customer. And so now the question

has gone from build versus buy to build versus die. Because one participant in that market starts listening to customers and using the agility of software to innovate faster and faster and faster. And then the incumbents that industry start listening. And they say, oh, wow, we've got to do the same thing. And so they start becoming builders of software as well. It's this Darwinian evolution that's going on in every industry. And so the Buy Act is one enabling you to be the best builder in your industry. That's how I think about it. That is great. So if you are a company, you're thinking about, hey, I do want to start building out developers? I want to have teams. But do I just use all the AWS kind of APIs? Do I go to Microsoft and use Azure? There's all these new startups that have

APIs. How do I think about those things? How do I make those decisions? And it seems like AWS is creating a equal API for every startup that's out there. How do you talk to business executives about those decisions? Well, it's like any competitive dynamic in any supply chain, which is you want to pick the vendors and the partners who are going to enable you to go build as fast as you can. Every company has the areas of strength, the areas of expansion. And APIs offer you the ability to pick the services that are going to serve you best. And one of the things I talk about in the book is actually trusting your developers to help you navigate the vendor choices that you have.

I remember back to the early days when I was a developer, I would do a Google search, oh, this looks good, okay, how do I get started? And you click and would say, contact sales. And, you know, if you sign an NDA, you can read the documentation. You'd be like, okay, back, never mind. I don't want that. Because for developer, documentation is the ultimate marketing. You know, yes, every company has a marketing website that's pretty and hand wavy. But at the end of the day, the documentation of an API is the perfect description of what that product does.

It literally describes every in and out of what the product does. You don't have to believe a salesperson. You don't have to look at a slide deck, which is faster than in the old world you can even get a meeting with the salesperson, right? And that's why they are becoming so influential in adoption cycles and sales cycles because a developer can, for free, read the documentation, make an evaluation of what they think the product is. And then for literally dollars, build the prototype and test those hypotheses and put it in front of customers and actually do a beta. And that is a completely revolutionary way to de-risk these projects and take them from a bunch of hypotheticals with a lot of budget and energy put into signing contracts with vendors and taking meetings to actually just getting hands on a keyboard, building the thing and putting it in front of customers. That empowered developer really transforms the go to market for API companies, right? I mean, it changes the way you do customer success and the way you do onboarding.

If they're going to build that prototype before they maybe even talk to you, they must really radically transform the way you think about what an enterprise, go-to-market organization looks like in an API world. I'll tell you a true story. WhatsApp is a very large customer of Twilios and has been for a long time. And literally, that is a Yahoo email address of Jan signing up for a Twilio account back in 2011 or 12 or whenever it was. And this is one of the big differences between API account.

economy companies and other companies who say they serve developers. At other companies who regularly launch APIs and say, hey, we've got a platform. The developers are a strategy. At API economy companies, developers aren't a strategy. They're our customer. They are a revenue. You're never going to pull the rug out from one of them because you are dependent on them for the health of your company. And that's a very different world than like other companies where the customer is an advertiser or somebody else, for the API economy, you have to treat the developer as your customer. Yeah. The example of the WhatsApp story of having an individual developer sign up means that you really rethink marketing, communications, how you engage with those customers,

how you measure the metrics, how they're using the product. Lots of companies don't have great visibility into how their customers are using their product, but by definition, an API company has incredible visibility into how their product's being used. And that has never been possible before. You know, the nice thing about an API company is you search to track, did they build a prototype? Are they going to production? Are they making one or two calls a week? Are they now making thousands of calls a week? Maybe we should reach out, see what they need, what features are missing. Have a product manager engaged then. And, you know, keep those people close to the customer, whether it's developers or product managers. And so the order

of operations of the traditional enterprise gooder market has shifted. What used to be a whole bunch of like, you know, pre-sales marketing material and brochures and websites. Now, as Jeff said, it's the documentation. But then after that, you do want to come in with that white gloves kind of a service and really embrace your customer, understand what their needs are, understand what the opportunities are, you know, maybe rethink your roadmap and all these things based off of how people are using the products. But I think that creates lots of other opportunities for startups to actually support this new kind of a go-to-market motion. I think the most under-discussed, but most important aspects of this conversation is this

notion of keeping developers close to customers. That's a really novel idea for a lot of traditional companies. It's actually probably even a novel idea for a lot of established software companies, frankly. You both mentioned the documentation. But what really struck me is it forces developers to be better communicators because you're essentially having to explain, even if you don't write all your own documentation, like, what is this value? What is this thing you're doing? And that is another segue to this topic of how does one keep developers close to customers? Does that mean you literally, tactically put them in front of the customer? Are they now the front interface to customers? Are they taking the customer success calls? Are they taking, like, you know,

reports? Like, what does it actually mean to keep your developers close to customers? And how should this happen or not happen? That's a great question so on all. I think the answer is to start. I think the answer is starts with my assertion that being a developer is fundamentally a creative exercise. It's not merely a technical exercise. And I think that's something that is really misunderstood about software developers. You know, there's this pop culture myth about developers that's propagated by Hollywood. Look, there may be some truth to that. But really, developers are not just like calculus, you know, math nerds. In fact, we did a survey of software developers and we found that more than half of them played a musical instrument and it was like three quarters of them

did some sort of artistic thing on the side. And the act of writing software is creative problem solving. But that creative problem solving skill doesn't end with writing an algorithm. It really goes all the way to the types of problems that you throw at developers. And so one of my biggest statements in the book is instead of sharing solutions with developers, share problems. instead of handing a product requirements document that was written by some MBAs and throwing it over the wall and build it to this spec,

having a developer basically be a digital assembly line worker, share the problem with them. Hey, we're trying to make it so customers can sign up for our product and get productive in 30 seconds instead of 20 minutes, which it takes today. Now you unlock the ability for that developer

to use the full creative energy they have. You and I both self-identify as software developers. I still write code, and I'm sure you write code as well. the reality is, as you said, the developers are creatives. And like any real creative, they want people to use their work, their art. I actually believe that there's like a selfish reason why people are open source developers, which is that they just get a much wider audience much more

quickly. And then inside of a company, you want to know that there are people that are going to pay tens of thousands or hundreds of thousands or millions of dollars to use the code that they wrote and find that extremely satisfying. One of the greatest tropes that always bothered me was this idea that developers need to be protected from the customer? Don't get me wrong. You don't want your software developers handling every support ticket and every sales cycle.

However, if you don't poke holes in those siloed walls, you treat them like these precious things that can't be bothered by such trivial matters like customers, well, then you are doing a huge disservice because you're essentially blinding the developers to why they're writing the software in the first place.

And you need to intentionally poke holes in those walls, and I think product managers are actually the key to this. And a lot of companies, product managers, see their jobs as shielding developers. And I think the job of product managers is to figure out how do I facilitate the right interactions between the developers who I want to be able to have instinctive understandings of my customers and their problems and the jobs to be done by those customers and the development team who's there to solve problems. Because when you have an instinctive understanding of the customer, while so many other

ways of solving problems arise and so many other ways of thinking. it's super important to treat your creative class that way. And it's so funny because we also talk about the rise of design a lot. And this is a similar shift that's happening with designers when it comes to designing technology products as well. I've noticed that people often do the same thing with writers and editors. They give you this like specs doc and I'm just bringing more upstream like embed into your flow because we're going to hear things that you don't know to ask us or tell us. So no, one thing that comes to mind is the parallel between the shift that's happened because of personal computers and the internet for other creative classes. We're all

aware of the fact that you can use garage band or pro tools and a musician in their own home can record a song with basically the same tooling that the professionals use. And if your music is any good, you can develop an audience of millions of people as a creative. The same thing for like film production or video, right? Like used to have gatekeepers where studios and you needed millions of dollars of equipment to make a movie. Now anyone with an SLO can make a movie, can edit it on Final Cut Pro, the same software that they use in Hollywood, and upload it to YouTube. And so people well understand what's happened to those creative disciplines, but really the same exact thing has happened for software developers, which is a

software developer can take the same infrastructure that's used by the largest companies in the world, can build a software app on the internet, and get distribution with Google AdWords or Facebook ads or any of the stuff. And a developer with the right idea is also liberated to be able to build just about anything they need in the exact same way that musicians or, you know, video artists or storytellers. And that's an amazing thing that's happened. Combining that with what David said about open source, it does create this sort of composability, build on top of each other's building blocks. I mean, the best thing about TikTok is remix culture. Like the fact that you can remix all these bits. And that's exactly the same thing you're talking about, you know, this notion

of developers want an audience, developers are creative class. What does it mean for developers to become influencers more broadly within a company, with the question being how to make developers more influencers across the company? Well, to me, really that comes down to giving developers a voice and an environment where you embrace experimentation. Experimentation is the prerequisite to all innovation. You enable that as opposed to more hierarchical, top-down, you know, highest paid person's ideas, wins, and all that kind of stuff. You know, Jeff, so many companies have not embrace the Ask Your Developer mindset. Sometimes what they do is they sort of find their way into the shallow end of the pool

by sort of having hackathons. And then magically they find out that really good ideas come out of these hackathons. And hey, wait, maybe we should involve the developers earlier in that product roadmap process. You know, they have these good ideas, but they never get prioritized. They never get surfaced. Like you said, they come from elsewhere in the organization, but maybe they shouldn't. How do you think about hackathons, you know, when you're talking to this business executives, how should they think about hackathons

and then how can they take that catalyst of sort of an event inside their organization and actually institutionalize it into their culture and workflow and process? You know, I like hackathons, not necessarily because every hackathon results in the next giant innovation or whatever it is. You're right, it often does end up proving the hypothesis

that, oh, wow, there are some things that we could do relatively quickly that are very impactful if we let our teams kind of go wild thinking about whether the things. But I like hackathons because they are a practice that actually encodes ask your developer. Because if you think about it, inherent in a hackathon is this idea of letting developers essentially spend a period of time

self-organizing and building the things that they think are interesting and important and using that opportunity to prove out and to test out their ideas. In an ideal world, like companies would operate more normally in more hackathon-oriented ways, i.e., small teams working iteratively and being agile and being tasked with problems, not solution. And a hackathon is a way to simulate that for a short period of time, then at small scale. I mean, I hear what you're saying, but I feel like hackathons are a bit performative

because I've seen too many times, like a lot of companies do what you describe in the book as that silicon safari effect. Like animals in a cage, we must follow the same practices and perform them essentially. I don't think they're performative. I think that they're like, you have pressure building up in a system and it's like the steam valve. You reconfigure the machinery so that that steam valve doesn't need the release. I don't think there's ever been an organization, the least that I've ever heard of, that's done a hackathon and been like, wow, that was totally useless. We're never going to do that again. They may not get that great new product that sends up their revenue for the next five years, but there's always learnings.

And those learnings are not just in the code that gets written, but in the processes that get created. So I think hackathons are great. I would certainly not describe them as performative. I will play the role of peacemaker here, because I think you're both partially right. I think that, look, if you go into a hackathon saying, okay, I really am waiting for one of these folks to come up, but the thing that's going to save the company. It's probably not really the right expectations to walk in with. So to some extent, it is performative. But I think that the goal of the hackathon is not to solve the problem during the hackathon. The goal of the hackathon is actually to model what you want your organization to become. It's like a rehearsal

for really the organizational structure and the way of operating during like the regular course of business. And so I think that's the role that hackathons play. I actually think a better way to structure it is if you're an executive at a company, create a hackathon, two days, a week, whatever you want to do. But go in with, hey, I care about this. You're important. I'm committed to this. Number one. Number two, here is a list of the 10 biggest problems I hear from our customers. But here are the 10 biggest problems that we face as a company. And I love for you to be thinking about. Now you've directed the energy. You've shared problems with those developers. And you've told them the stakes are high. I think that is a much more effective way

run a hackathon. I love that. You've made peace. We've been talking about the developer mindset quite a bit, but we haven't actually defined what is a developer way here. It's not just a role and a function. Like, it's a mindset. And Jeff, have you seen in your work that these habits transfer across the org, if you use the word mindset throughout your book, and David has used the word way throughout his work. I would love to hear you guys thought, kind of define like what makes a developer. Look, I think developers in general, especially open source developers, have mastered a whole bunch of working methodologies that end up just turning out

to be great working methodologies, not just for developers, but for anybody. So that involves really having the tools to do asynchronous sort of communication and development. So in software development, that can be revision control systems, things like GitHub or GitLab to allow people to collaborate.

It can be ways of memorializing decisions. So developers have change logs. They have issue tracking. They have poll requests. And so it's often very easy to figure out how did this line of code get into the code base, who signed off on that decision? Who else reviewed it? And these are things that other organizations outside the developer are sort of part of the organization. No one knows how did decisions

get made. Who made those decisions? When were they made? Why were they made? And then, of course, they are power users of their own computing devices. And so, you know, developers often are much more keyboard-driven. They use shortcuts. They're much more fast to operate. And we see these things bleeding into our world today. People now use emojis as shorthand. People are now using things like a command palette and they've gone way beyond the way developers use command pallets. They're now sort of bleeding into our normal daily life. But I do think there's a lot to learn from the way developers organize, the way they communicate, the way that they memorialize decision making. And then, of course, the way they just use their computing tools as power users because, you know,

everyone's effectively a digital native these days and becoming more and more of a power user. How do you define it? I'm a little more hesitant to define the developer way. I struggle a little bit with saying, you know, here's my definition of developers because there's a lot of different ways to work. Now, that said, a lot of developers do share a lot of common traits. Like, you know, when your work involves writing Boolean logic a lot, if you tend to be drawn to that work, you probably tend to also want to have logical thinking in other areas of life.

So I do tend to see engineers as being logical thinkers. And it's interesting because I as a CEO and a software developer bringing logic to a lot of the decisions, but also to a lot of my interactions with other team members. And I actually have noticed that it can be rather infuriating. Actually, it's one of the things I've had to moderate as being a CEO from being a developer. I've actually realized some of the ways in which the ways developers think, while they may be often right, they don't necessarily serve you in interfacing with people

who don't think the same way. But I would say for if you're a business executive, a few things to think about. One is like many other arenas where you have a lot of concentration required to do your job. Flow is one of the most important things for developers.

So the ability to immerse yourself in a problem, be able to kind of fit it all into the working memory of your brain and then be able to get your work done is really important. That's why developers are really sensitive to interruptions, the taps on the shoulders or meetings and things like that.

And the other thing I would say is if a developer is hooking holes in the logic of your idea or your plan, like they're not being a jerk, that's just the way they think. They're processing whatever they're hearing through the lens of how they think. And therefore, that's the response you're getting. And so it's maybe a way for folks to understand developers and therefore be able to engage with them is to think about the ways in which developers process information make decisions. I like to propagate this idea that developers are creative problem solvers and much bigger, more influential parts of the team

when they're whole human beings, not just like code monkeys. Jeff, you've alluded to this a few times. In fact, I thought this was one of the most interesting themes in your book is you asserted throughout, it's about small teams. It's about small teams. It felt like a refrain. I've always heard the two pizza rule for Amazon. I never heard the origin story

until your book, and you describe having dozen bagel teams. So tell us a little bit about small teams, why they matter, how to grow them, how to make them work. I feel like the title of the book should also be small teams. Yes. Ask your developer if small teams are right for you. So back to, we're starting Twilio. At the very beginning, in the very small team that you are,

you kind of do everything, everything from like having talked to customers that day, to handle support tickets, to writing code, to understanding the architecture of like everything that's going on. You can hold the whole business in your head at the scale of several people. And as we started growing Twilio, one of the most momentous things that happened to me was I was talking to my friend, his name is Dave Chappelle, not the comedian, different Dave Chappelle. He was actually the person who hired me at Amazon. And he had started at Amazon in, I think, 97, so when the company was about 100 people. I joined in 2004,

Amazon was about 5,000 people. And Dave, he quit. That was my first week. He was like, I'm sorry, I couldn't tell you before. I'm out of here. He went and started a company called Teach Street that was aquired back into Amazon about seven years later. So Dave found himself back at Amazon, but now the company was 75,000 people. So Dave saw Amazon at 100 people, 5,000 people, and then again, it's 75,000 people. And so as I was starting to scale Twilio's culture and thinking about how we were going to structure ourselves, I called Dave. And I said, hey, Dave, can you compare and contrast Amazon at 100 people, Amazon at 5,000 people, Amazon at 75,000 people? And he said, huh, let me think about that for a second.

And he said, you know what? it's exactly the same. It's the same bounce in people's step, the same sense of urgency, the same intellect that everybody here has. It feels like the same company. And to me, that is the outcome of the two pizza team, as they call it at Amazon.

Because as the company is growing, there's a natural tendency for every company as they get bigger, to slow down, to insert more bureaucracy, to create walls between customers, to create politics and things like that. And what small teams do is they keep a small group of people who are very tight and focused on what my definition is, the small team is defined by a customer they're serving, a problem they're solving for that customer, and then metrics of success that say whether or not they're succeeding. And there's a lot of advantages here. First of all, on a very small team of, say, 10 people, there's no room for a low performer to hide. On a team of 10 people, everyone's got to carry their weight, and it's obvious when somebody isn't. The other thing that I think is interesting about small teams is that people's willingness to go along with decisions

is proportional to how involved they were in that decision and how close they are to decision maker. And so if you're on a small team of 10 people and there's a single-threaded leader to lead that team, then you want to push as many decisions as possible to that leader. And when you do, it's likely that they're going to be involved in that decision. And if the person's managers, the one who made a decision that maybe they disagree with, they're probably going to be more inclined to disagree and commit.

Or they're more likely to be able to question it. Hey, can you explain to me why you made this decision? Like, you can't do that when it was someone five levels up. Usually you don't even know the person or you're hard to get the meeting or you'd be afraid to express yourself. And even when there's disagreement, those disagreements get resolved. So instead of having this like us versus them, you get this sense of like, okay, we're all in the same team here.

Let's go. Let's do this. You know, one additional benefit of small teams that I've always observed is that there are some people that like to work on very small projects with rapid iteration where they sort of have the dopamine rush of shipping a release and getting something done very quickly. There's also other kinds of engineers that like really long, hard projects that take months and months and have very little to show for it for a long period of time. And by having small teams, you can actually let people sort of work in an environment that works best for them.

Like those people that want to close out a ticket to help win a deal or save a renewal. Like those people like to be on those fast, close to the customer kind of teams. Then there's those infrastructure people. And by having small teams, you allow people to end up gravitating towards the kind of work that ends up allowing them to work at their highest and best sort of potential. People can find where they fit in best. And I've always found that as an organization scales to be a really, really valuable component. The other interesting thing, by the way, about the infrastructure people you mentioned, great engineers love building for the other builders, right? But they've got to see it as I'm serving a customer with a mission and metrics. And so even internally focused teams,

it works the exact same way. And I think that's one of the beautiful things about structuring yourself that way. It's reminding everybody. Like, if a team exists and has no customer internal or external, then, man, I'd wonder why they exist. I want to probe into, like,

what happens when companies scale and grow and small teams can't really stay small. You argue for a really interesting concept called mitosis, which obviously is borrowed from cells. They split as you grow. And I thought that was a really interesting idea. So for us, I'll give the example, our first product was Tullio voice, the ability to make and receive phone calls with Tullio.

And that was built by the founding team. We built it. We started hiring people. We grew. And suddenly the team that was working on that product became like 15 people. We said, okay, this is getting too big. If we believe in small teams, we need to split this. How are we going to do that? And so what you do is you take the problem domain and you say, okay, if I want to divide this problem domain in half, so I can have two teams instead of one big team, how would I do it? And there's no one answer to it. But the best thing you can do is align. the people, the technology, the code itself, and the customers. And when you can figure out how to actually divide the problem so that the customer, the technology, and the team can actually stay together, that's the best way to do it. And so for our voice product, we realized that the voice product really consisted of two things. One was the connectivity layer into the carriers of the world.

And the second was all the programmable APIs that allowed you to do things with that connectivity. And so we divided those two teams. And initially, the code was completely intertwined. and it was like a complete mess. And we set out and said, okay, we need to decouple those two systems. And we need a technical leader for the connectivity side. We need a technical leader for the API side. And over the course of about six months, we untangled the code bases.

We untangled the teams. If we didn't have a leader like we needed for the next team, we would hire the leader. And after about six months, we were able to decouple the two and take one very big team and turn it into two small teams again. And it's basically the process that Twilio has used to grow from the three engineers that we were when we founded the company to now several thousand engineers. We just keep doing this mitosis process. In the act of that, one of the key enablers of that is itself APIs. And those APIs can be used internally, but they could also be exposed externally if we wanted. And so we actually

ended up doing that. We productized, we call it Siptrunking. That's the connectivity layer that is now its own product. And that product itself has undergone mitosis now many times, as well as our API layer, which is its own product. Do you throw away the notion of small team and say, well, that's only for the early stages once it gets big. So be it. I think that's exactly the wrong answer. That's fantastic. And I have to say people really should read your book because you say a lot more about the types of leaders that are needed. And I love that you have this line about a phrase that you've coined the fallacy of better collaboration because that's one of my pet peeves when you have too many small teams. How do you coordinate and collaborate? And it's a wonderful, wonderful chapter.

Last question. One thing that I've been dying to ask you just super quick, which is what would you say is your biggest personal evolution pre and post IPO? That's top of mind for a lot of people right now. So I'm very curious about that. For me, it has been, the biggest evolution has been really thinking more holistically about the intersection of product and go to market. We went public and we had about 12 salespeople in the company. And we really loved our developer first approach, our self-service model, developers sign up and start building. And we were very happy with that and as such, like, really had underinvested in sales, you know, like 12 sales reps to manage a quarter billion of revenue. That's an underinvestment. Yeah, right? Wow. Yeah. But what I came to

realize was empowering a developer to get started with Twilio is amazing. But once a company starts spending hundreds of thousands or millions of dollars, you can't rely on a relationship with a developer to maintain that level of spend because now you've got so many more stakeholders inside of the company. Developers want to do great work. But when the CFO is saying, hey, how come we're spending this much on Twilio? I mean, you know, that's someone else's job, right? And so we now call it the developer first approach, where developers start the relationship, but then we build a mature relationship with many stakeholders inside the

company. And that's essentially what salespeople often do is they understand the org chart of the company and they understand what the stakeholders are. And they really build deep relationships with the customer, the customer meaning the company, not just the individual. So that's probably, I think, one of the biggest things that I've come to, you know, evolve in my thinking is the holistic nature of what it takes to build a company. It's so funny. We have a whole series of podcasts called How to Go from a Technical to Product to

Sales to Go to Market CEO because it's exactly the journey. That's fantastic. Jeff Lawson, author of CEO of Twilio and author of Ask Your Developer, How to Harness the Power of Software Developers and Win in the 21st Century. Thank you so much for joining. Thank you, Sonal. It's been a pleasure.