Developers as Creatives

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 CFI 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.

Show Notes

How software has become an essential part of the supply chain [1:40]

Discussion of whether companies should build their own software or buy it [4:10]

Including developers in the sales process [8:10], seeing them as influencers within a company [14:08], and having a culture of asking developers for input [17:13]

Defining the “developer way,” or the culture of work that developers prefer [20:00]

The importance of small teams [23:47] and how to keep teams small as a company grows [28:37]

Lessons from Twilio’s IPO and expanding the role of sales [31:17]

Transcript

The new software supply chain

Sonal: Since I hate starting with the “why’d you write the book” question, I’d love to instead start with the big picture. We’ve seen 3 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 the new supply chain. So, I’d love to hear more about how you think about that to start us off.

Jeff: Yeah, thank you for asking, Sonal. I mean, it’s interesting, I come from Detroit, it’s the automotive capital of the world. I grew up around cars, and so many people that I knew, 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 that allowed them to manufacture a complex thing like an automobile: General Motors doesn’t have to manufacture every little 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 forum 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 could pull in some open source stuff here and there. But building software has gotten easier and easier and easier, because of 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 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 this 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.

Sonal: 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’s the differentiation?

Jeff: 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.

David: The remote control in our pocket — it’s how we interface with the companies we do business with!

Jeff: You know what I called my iPhone for a while, I called it my “summoner”.

David: Yeah, exactly.

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. -Jeff Lawson

Jeff: Think about your bank. Twenty years ago, your bank was a storefront 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 to 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, should 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 in 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 — this Darwinian evolution is 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.

David: That is great.

So, you know, 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?

It seems like AWS is creating an equal API for every startup that’s out there… how do you talk to business executives about those decisions?

Jeff: 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 their areas of strength, their 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 it 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 a developer, documentation is the ultimate marketing. 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. And you don’t have to believe a salesperson, you don’t have to look at a slide deck; which is like faster than in the old world, you couldn’t even get a meeting with the salesperson, right?

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.

David: 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 — it must really radically transform the way you think about what an enterprise go-to-market organization looks like in an API world.

Seeing developers as customers

Jeff: I’ll tell you a true story; WhatsApp is a very large customer of Twilio and has been for a long time. And like, 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-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 our revenue. You’re never going to pull the rug out from under them, because you are dependent on them for the health of your company. And that’s a very different world than other companies where the customer is an advertiser or somebody else; for the API economy, you have to treat the developer as your customer.

David: 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 don’t have to track: Did they build a prototype? Are they going into 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 engage them, 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 go-to-market HAS shifted. What used to be a whole bunch of 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-glove 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.

And I think that creates lots of other opportunities for startups to actually support this new kind of a go-to-market motion.

For a developer, documentation is the ultimate marketing. -Jeff Lawson

Sonal: 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), 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, you know, reports?

Like, what does it actually mean to keep your developers close to customers; and, how should this happen (or not happen)?

Jeff: That’s a great question, Sonal. I think the answer 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; and, 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 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 the spec — you know, 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 the 20 minutes which it takes today. NOW you unlock the ability for that developer to use the full creative energy they have.

David: You and I both self-identify still as software developers; I still write code and I’m sure you write code as well. The reality is, as you said, these 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.

Jeff: 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 — and 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, ‘cause you’re essentially blinding the developers to why they’re writing the software in the first place.

And so you need to intentionally poke holes in those walls, and I think product managers are actually the key to this. At 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, well so many other ways of solving problems arise, and so many other ways of thinking.

Developers as internal influencers

Sonal: 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. Like they give you this specs doc, and I’m just bring ‘em more upstream, like, embed into your flow… ‘cause we’re going to hear things that you don’t know to ask us or tell us.

Jeff: Sonal, 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 GarageBand, 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 film production or video, right, like you used to have gatekeepers, who were studios, and you needed millions of dollars of equipment to make a movie; now, anyone with an SLR 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 that exact same way that musicians or video artists, or storytellers do. And that’s an amazing thing that’s happened.

Sonal: Combining that with what David said about open source, it does create this sort of composability — build on top of each others’ 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 a 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?

Jeff: 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, highest-paid- person’s-ideas wins, and all that kind of stuff.

David: You know Jeff, so many companies have not embraced 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, 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 those business executives, how should they think about hackathons? And then how can they take that catalyst of sort of an event inside the organization and actually institutionalize that into their culture and workflow and process?

Jeff: 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 what are the things — but I like hackathons because they are a practice that actually encodes Ask Your Developer.

‘Cause 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, 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 solutions. And a hackathon is a way to simulate that, for a short period of time, and at small scale.

I like hackathons, not necessarily because every hackathon results in the next giant innovation or whatever it is... but I like hackathons because they are a practice that actually encodes Ask Your Developer. -Jeff Lawson

Sonal: 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.

David: 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 (at 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, you know, 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.

Jeff: 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 these folks to come up with 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 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 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. #1.

#2: here is a list of the 10 biggest problems I hear from our customers; or here are the 10 biggest problems that we face as a company — and I’d 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 to run a hackathon.

Sonal: I love that. You’ve made peace.

Developers’ unique workflow

Sonal: We’ve been talking about the developer mindset quite a bit. But we haven’t actually defined what is the 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? You use the word “mindset” throughout your book; and David has used the word “way” throughout his work.

I would love to hear your guys thoughts, kind of define what makes a developer.

David: 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 could be revision-control systems, things like GitHub, or GitLab, which allow people to collaborate. It can be ways of memorializing decisions: developers have change logs, they have issue tracking, they have pull requests — and so it’s often very easy to figure out how did this line of code get into the codebase; who signed off on that decision; who else reviewed it? And these are things that other organizations (outside the developer part of the organization), no one knows how the decisions get made; who made those decisions; when were they made; why were they made?

And then, of course, there 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 palettes; 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.

Sonal: How do you define it? Curious for your thoughts on this.

Jeff: You know, I’m a little more hesitant to define like, 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 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, you know it’s interesting, because like I, as a CEO (and a software developer), bring 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 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, 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, to taps on the shoulders, or meetings, and things like that.

And the other thing I would say is, if a developer is poking holes in the logic of your idea or your plan, they’re not being a jerk; it’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 and 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, you know, code monkeys.

The importance of small teams

Sonal: 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 a dozen bagel team — 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”!

Jeff: Yes, “Ask Your Developer: Small Teams Are Right for You.” <Sonal laughs>

So, back to, we were starting Twilio — at the very beginning, in this very small team that you are, you kind of do everything; everything from like having talked to customers that day, to handled support tickets, to writing code, to understanding the architecture of everything that’s going on. Like, 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’s Dave Schappell (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 5000 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 TeachStreet, that was acqui-hired back into Amazon about seven years later. So, Dave found himself back at Amazon, but now the company was 75000 people.

So, Dave saw Amazon at 100 people, 5000 people, and then again at 75000 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 5000 people, Amazon at 75000 people?” And he said, “Hunh, 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 the 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 would have 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’s someone five levels up; usually you don’t even know the person, or it’d be 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 vs. them, you get this sense of: okay, you know we’re all on the same team here; you know let’s go, let’s do this.

And what small teams do is they keep a small group of people who are very tight, and focused on... a customer they're serving, a problem they're solving for that customer, and then metrics of success. -Jeff Lawson

David: 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 loooong, 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 this fast, close-to-the-customer kind of teams; and 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.

Jeff: 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, is reminding everybody: Like, if a team exists and has no customer, internal or external, then, man, I’d wonder why they exist.

Managing growth and team size

Sonal: 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, that split as you grow. And I thought that was a really interesting idea.

Jeff: Yes. So for us — I’ll give [an] example — our first product was Twilio Voice, the ability to make and receive phone calls with Twilio. And you know 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. And 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 like 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 sat out and we 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 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 that’s basically the process that Twilio has used to grow from, you know 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 SIP trunking — 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.

Sonal: 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 — where when you have too many small teams, how do you coordinate and collaborate? And it’s a wonderful, wonderful chapter.

Lessons from Twilio’s IPO

Sonal: 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.

Jeff: For me, it has been — the biggest evolution has been — really thinking more holistically about the intersection of product and go-to-market.

You know, we went public, and we had about 12 sales people in the company. And we really loved our developer-first approach, our self-service model; developers sign up and start building. And… you know, we were very happy with that, and as such, like really had under-invested in sales. You know like 12 sales reps to manage a quarter billion in revenue, that’s an underinvestment, right?

Sonal: Wow… yeah!

Jeff: 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?” like “I don’t know, I… ” I mean, you know, that someone else’s job, right? And so we now we 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 who the stakeholders are; and they really build deep relationships with the customer (the customer, meaning the company, not just the individual.)

You know 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.

Sonal: 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, 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!

Jeff: Thank you, Sonal, it’s been a pleasure.