Throughout his business career, Twilio CEO Jeff Lawson has relied on his broad perspective as a serial entrepreneur and trained software developer. So from his early days helping to launch StubHub to his current work building Twilio into a leading communications-platform provider, he has been keenly aware that the people who lead companies often don’t know how to communicate with the developers writing the code—and what gets lost in translation is a major opportunity cost. To help all kinds of enterprises bridge that gap, he recently published a book, Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century (Harper Business, January 2021).
Earlier this year, Lawson spoke with McKinsey’s Paul Roche, a senior partner who leads the firm’s Software Practice, and Shivam Srivastava, a partner in the Silicon Valley office. They discussed the keys to tapping software developers’ creativity, what nontech companies can do to attract top tech talent, why infrastructure is so critical to productivity, and how the idea for Twilio’s “Ask Your Developer” billboard campaign started with prescription-drug commercials. The interview, condensed and edited, appears below.
Developers as creative problem solvers
McKinsey: What do you think are still the biggest misconceptions about developers that business and tech leaders have, and what motivated you to write the book?
Jeff Lawson: In today’s digital economy, it’s the companies that figure out how to build great software that are able to win the hearts, minds, and wallets of customers. And so that means unleashing the talent who builds software.
But when I talk to customers in so many different companies, I find that businesspeople and software developers struggle to speak the same language. And I find myself in a unique position as a CEO who was a developer, where I’ve got one foot in both worlds. So I wrote the book to really create that bridge to enable businesspeople to bring those developers in as partners in building great digital businesses.
McKinsey: You write in the book about code as being creative and development as a craft. How does a large, traditional organization that is not a tech player create an environment that fosters developer creativity?
Jeff Lawson: Developers are creative problem solvers. Taking something from nothing and turning it into products and experiences that customers love is all about creativity. And so, no matter what the company is, I think the key to unlocking that developer talent is to share problems not solutions with your developers.
At a lot of companies, they hand product requirements to developers to go implement them. That is what I call sharing a solution. The better way to do it, as the best companies do, is share problems with those developers. They say, “Hey, technical team. Hey, developers. Here’s this business problem we’re trying to solve.”
McKinsey: Why is that so critical?
Jeff Lawson: Because now you’re allowing developers to really apply their creative problem-solving skills, as well as their understanding of the technology that you have in place at your company, and to take all that understanding of the problem domain and apply it. And when you do, you get better solutions built faster. That’s what every business executive I’ve ever talked to wants. And it’s also what every developer wants to do, to make more impact faster.
And the amazing thing about sharing problems, not solutions, with your technical teams is that you don’t have to pretend to know answers. You just have to know the business problem you’re trying to solve. And that is something that businesspeople think about a lot.
McKinsey: Can you give us an example of a traditional company that has succeeded with this approach?
Jeff Lawson: Well, look at Domino’s Pizza. It is this sleeper success story of the last decade. That’s because they have transformed themselves from a pizza chain to a technology company.
At one point, the CEO went to the CIO [chief information officer] and said, “I have a problem. I think that customers, parents on their way home from work, often don’t know what they’re going to feed their kids for dinner. I bet if we let them order a pizza from a stoplight in like 20 seconds, it would open up a whole new market of parents for us.” Answering that single question sent the technology team on a decade’s worth of innovation.
So they had to build a CRM [customer-relationship-management] system. They didn’t know who the customers were. They didn’t know your last order, your preferences, your address. Then they built mobile apps, they built Alexa integration, and they built [a system to] order a pizza with a text message. And it all started from sharing a problem with the technical team.
McKinsey: Making developers real partners naturally raises the bar on talent, the technical talent you pull in—including both leadership and individual developers. If you’re the CIO or CTO [chief technology officer] of any Fortune 100 nontech company, how do you attract that talent? How do you compete with tech giants? And how do you create a culture that actually keeps that talent and keeps them happy?
Jeff Lawson: I think there is actually a very simple, very compelling pitch. I think at any major tech company, while they are great places to work, you’re going to be one of thousands of software developers. Whether you’re a leader or a line developer, you’re just one of many. And so, if you’re recruiting technical talent at a company that’s not primarily a software company, the pitch is that you get to come in and be part of this key transformation into a digital company. It’s basically that you’re going to be a big fish in a small pond versus being a small fish in a giant pond.
I know I used it a lot. When Twilio was a much smaller company and we were recruiting, we’d have offers out against some of those tech giants. And we weren’t paying nearly as much as those other people could. But we’d say, “Look, you’re going to have a huge impact on this company.”
Balancing standardization and flexibility for developers
McKinsey: Along with talent, the other big challenge that we often see tech leaders grapple with is balancing flexibility and autonomy against consistency for developers and teams. And this particularly shows up in the choice of tools and cloud services. Any advice for executives grappling with that?
Jeff Lawson: I think the right thing to do is to focus on the outcomes that you want and then build the combination of practices or mechanisms that’ll help you achieve them. Most leaders want innovation; they want better teams to serve customers, to move fast, and to beat the competition. But they also want a certain bar of quality, reliability, and security.
I believe the way you do that is you create the team structure, small teams of no more than, say, ten people, and you give them a customer, a mission of how they’re going to serve that customer, and the metrics of success. And with that, you let them loose, and you give them a ton of autonomy.
But here’s where the guardrails come in. You say, “You’ve got a ton of autonomy, but you do have to meet the bar of security, reliability, et cetera. And the way you’re going to do that is with infrastructure.” And the company invests in infrastructure to enable those teams to not only move quickly but also move confidently.
However, you do not require them to use the infrastructure. And that’s the key part. Because once you start piling all these requirements on, you start to lose the autonomy part.
Would you like to learn more about our Technology, Media & Telecommunications Practice?
McKinsey: But only a certain degree of autonomy?
Jeff Lawson: I liken it to a tax. When you work at the company, you get a lot of great things. You get a marketing machine, a big customer base. But to take advantage of those things, you pay a tax. And that tax says, “Well, you have to meet the bar of security or reliability or whatever it is.”
If your tax rate is too high, well, then people rebel. Or they lose their motivation to work hard. But if the tax rate is too low, you actually can’t provide services, and society falls apart.
So getting that tax rate right is important, and the key is balancing autonomy with that tax.
At Twilio, we do it by offering what we call the paved path. These are mature services that you can just pull off the shelf, adopt, and get up and running super quickly.
But if a team wants to diverge from that path—like, if they’ve got to use a different language or need to host it somewhere else or need something that’s never been used before at Twilio—they can make that decision. You just still have to pass the same rigorous bar of quality, reliability, and security that you would have gotten basically for free had you taken the paved path.
And so what you do is you create the incentive structure for teams to take the paved path. It’s a lot easier. But if they really have to go a different route, you make it possible for them to do that.
McKinsey: Do you find leaders sometimes don’t appreciate the importance of that underlying infrastructure?
Jeff Lawson: I’ve had these conversations so many times, internally at Twilio and with customers who question how much they’re spending on infrastructure—the logging infrastructure, the monitoring infrastructure, the building-deployment pipelines. It’s not uncommon for companies to spend upward of 40, even 50, percent of their R&D budget on infrastructure. And it’s easy to look at those numbers during your next budget cycle and say, “Oh, we’ve got to be able to cut that because it’s not what our customers see and use every day.”
But infrastructure makes every one of your developers more productive. It makes every one of your developers able to build those innovations quickly and confidently. And guess what would happen if you cut it? You would see the rest of that 60 percent or whatever you’re going to spend—the productivity—go through the floor.
And by productive it means, you write code, it works, it is secure, and you’re able to get it out to production and serve customers at internet scale with as little friction as possible. Because you want your developers focused on building what we call “the code that counts,” the ones your customers actually pay you for.
How Twilio was born and has grown
McKinsey: You started Twilio in 2008. What inspired you to start it?
Jeff Lawson: I’m a software developer myself, and I’m also a serial entrepreneur. I’ve started multiple companies prior to Twilio—first was a content website for college students, then I was the first CTO at StubHub, third was a brick-and-mortar retailer for extreme-sporting goods. One common thread was we used software to serve our customers better than any of our competitors. And the reason was that with software, you’re able to iterate incredibly quickly.
The other common thread, though, between all three of those companies is that we needed to communicate with our customers at various points in the customer journey. And every time we had these ideas to do that, we’d say, “Oh, that’s a really neat idea. Yeah, that would be fantastic. Oh, but wait a minute. I’m a software developer. What do I know about communications?”
So every time, I’d ask the people who seemed like they did know—the carriers and telecom or networking-hardware companies—if they could help us build it. And every time, I got a similar answer. It was going to be very complicated, take two to three years, and cost a few million dollars. Now we didn’t have millions of dollars to spend on this one feature. But even if we did, this idea that you would spend years building something before your customers ever gave you feedback was offensive to me. And so we started Twilio to bring communications, which is so fundamental to how almost every company engages with its customers, into the era of software.
We wanted to make it so that the software developers of the world, who are building all the websites and the mobile apps and all these innovation experiences, were actually able to build out the customer-engagement touchpoints that are part of those very same products and experiences. And in doing so, we wanted to unleash a lot of innovation to allow companies to finally build those use cases they have long wanted to be able to give their customers but had considered too hard, too expensive, too risky.
If you’re recruiting technical talent at a company that’s not primarily a software company, the pitch is that you get to come in and be part of this key transformation into a digital company.
McKinsey: As you rolled out Twilio, how did you build the developer ecosystem and do the platform evangelization, which is a little different from just building your own developers?
Jeff Lawson: We just started getting out into the communities of developers, where they hang out online and offline—going to hackathons and meetups, meeting developers online. In the early days, we would promote lots of the amazing things that our customers built with this new tool.
We basically said, “Here’s another tool to put in your tool belt. And if you’re anything like us, at some point in the building of companies or products, you’ve needed communications as a part of that solution.” And the way you get that in every developer’s tool belt is not by a hard sale. It’s by essentially showing “here’s what you could do if you had this tool in your tool belt” and enabling that. That means great documentation, easy sign-up, published transparent pricing. All those things that cause a developer to say, “I trust this. I know what I’m getting into.”
McKinsey: What are some of the things you did along the way that didn’t work?
Jeff Lawson: We invested in a sales function pretty late in the game, which I think was probably one of our biggest mistakes. Early on, I had much more of a belief that the developer and the self-service nature of developers signing up, getting started, building something, and pushing it to production was really the full extent of Twilio’s go to market. And the developer-first go to market is still the source of our strength.
But I came to realize that you then follow it up with a more traditional B2B relationship. You want to get to know the many stakeholders inside the company, and you want to talk to them about the next problems they need solving. It helps with your cross-sell, and it also helps with your relationship as the account is getting bigger and bigger. And we’ve had to really figure out this hybrid, self-service, developer-first go to market coupled with a mature sales-driven motion. It is pretty complicated, and very few folks have done that before.
McKinsey: So was that hybrid approach part of the genesis behind the “Ask Your Developer” marketing campaign? How did that come about?
Jeff Lawson: Well, it all started around 2014 or 2015, when not a lot of people, apart from developers, knew who we were. I could tell that getting more executive support and executive awareness of Twilio would be helpful for us as the size of our contracts were getting bigger and bigger. So we had rented this billboard on Highway 101 [in the San Francisco Bay Area] that runs from the Valley past the airport to the city. We hired a marketing firm to help come up with what the billboard should say. But, honestly, we thought their ideas sucked, and we went back to the drawing board.
You know those commercials for pharmaceuticals where they say, “Ask your doctor if Regurgitan”—just to make one up—“is right for you”? I had that commercial phrase stuck in my head from hearing it so many times, and I had this idea, like, “Ask your developer if Twilio is right for you.”
Developers know all the cool new tools out there. They know how to build. They know how to connect the technology to the business problems you’re solving. But, so frequently, the business doesn’t bother to ask the developers. But it also was a sort of double play for executives who might not know about Twilio yet, as in, “Well, ask your developer, because they’re the ones who know about Twilio.”
We felt it really created enough mystery in the short period a billboard has to capture someone’s attention. And it was a succinct way to tell the story of how Twilio had made its way through the developer community and was then trying to elevate to a much broader audience. At the same time, it also told the story of the importance that developers have inside every company and that they should be thought of as partners in building the business.
And I see the book as a continuation of the billboard.
McKinsey: So Twilio recently acquired Segment. Obviously, there are developers who build on Segment too, but there are also a lot of other people, marketing, analytics people, CMOs [chief marketing officers], and all of that. How does that change your value proposition—to customers and maybe even to developers—now that you’ve added CDP [customer-data platform] and data capabilities to your offerings?
Jeff Lawson: It takes the collaboration of many different functions to succeed in the digital economy. But all the functions have to think of themselves as builders. And there are a lot of different ways to build. Some builders use code. Some builders use low code or no code. And other people like marketers are builders too. At the office, I used to sit right next to our marketing team, and they’re always tinkering to figure out how to improve online campaigns, tweaking the digital assets for better performance, better conversion, and better SEO [search-engine optimization].
At Twilio, we think, of course, there are distinct roles for the data analyst, the marketer, and the developer. But, in fact, one of the biggest stories of the last ten to 15 years is that developers have started to become infused into so many of the other functions of a company—so that a marketing team will employ its own group of developers.
And Segment takes what the software developers do and plugs in all these data sources that the marketers need to run efficient and effective campaigns and improve customer engagement. They help developers build a great architecture for that flow of data and actually make the marketers more successful.
McKinsey: Do you see that logic over time applying to other functions that are increasingly automated?
Jeff Lawson: As developers come and get infused into every function in the company, they need the platform that enables them to do their job. And that’s sort of how Twilio thinks about all the different functions.
One of the amazing things about being a platform is we get to see the areas where our customers use us and, therefore, where the biggest unsolved problems are in their businesses, and it helps direct our road map.
That’s how Twilio Flex, our contact-center platform, came about. We saw companies building their own contact centers on top of Twilio’s APIs, which meant that off-the-shelf solutions hadn’t cut it for that function.
But there are only certain companies that are just crazy enough to go build their own; it’s a big lift. The rest of them can’t justify it, and that’s what encouraged us to say, “OK, great. We’re going to go build Flex.”
The next era of enterprise software
McKinsey: In your book, you write about the digital supply chain. What do you mean by that?
Jeff Lawson: You know, back 20 to 30 years ago, there was basically a very small group of software companies in the world—Oracle, Microsoft, SAP—which tended to write all the software that they produced. But now, pretty much every company is becoming a software company, and they need the infrastructure upon which to do that. The companies who can’t build software, who are just stuck with something off the shelf while the rest of the world is getting better, well, they start to lose customers.
But the good news is that so many companies have sprung up with the infrastructure that enables them to become really effective builders. That’s Twilio, that’s Stripe, that’s AWS. You buy the infrastructure that enables you to build the last mile, the things that differentiate you in the eyes of your customer and that they really care about. And I call that whole notion the software supply chain.
McKinsey: What do you think that means for the remaining software-industry providers who are not at the API or at the platform level?
Jeff Lawson: Think about IT 20 years ago, which meant mostly provisioning laptops and printers and maybe the financial software that ran the company. It was generally a cost center, and you were trying to look to outsource it. You would typically have this build-versus-buy question, and really the right answer was to buy it.
But now, because customers actually care about the software that companies use, it matters that you are not using the same software as your next competitor. It’s gone from a build-versus-buy decision of yesteryear to now a build-versus-die decision. Ultimately, the product has to free you to own your road map and, ideally, let you easily and inexpensively implement the things that you don’t care as much about, so you can get to build the things you care about the most.
Any software that results in a company having to tell its customers it can’t do what they are asking for will ultimately get thrown out by companies who want to survive and thrive.
Building remote teamwork and doing good
McKinsey: Given the shift to remote work over the past year of the pandemic, has your thinking shifted on how important offices and in-person collaboration are for innovation and success?
Jeff Lawson: I don’t think there is any one model that is better for innovation. You can look at great innovation that happens remotely. No one in the world of open source has ever sat in the same room as anyone else, right?
The only thing that I think I would say as an absolute is that teams have to have a working style that works for the majority of or the entire team. And I’m talking about the small team—the ten people who work together every day.
Developer Velocity at work: Key lessons from industry digital leaders
Encourage that flexibility to allow people to decide how to do their best work in whatever style that they choose, and transfer teams if necessary. What matters is that people find other people with the same and compatible working styles to become a team.
But if you come down with a draconian approach declaring, “Everybody has to work in the office” or “Nobody can work in the office,” you’re just going to exclude part of the workforce that could be really additive to your company.
And we’re planning for that future with something we call Open Work. To us, that means essentially you recognize that teams have different working styles; and you configure the office to enable some teams to be there all the time, some teams to hotel there, and some teams to never be there, except for periodically—it may be quarterly, for a face-to-face meetup.
And you plan for more agility in your workforce.
McKinsey: You created Twilio.org, the company’s social-impact arm, in 2013. What motivated you to do that back then, before corporations’ serious focus on their role and impact in society had started to become the norm?
Jeff Lawson: Well, two things. One, I saw the way nonprofits were innovating by using our product, and we wanted to support that. When you think about it, we offer communications. And so many of the world’s and so many of society’s problems are caused by the lack of communication and are solved by the right communication at the right moment with the right person.
But the other thing is that I believe as a corporation, we exist at the pleasure of society. And as a result, I believe that companies have an obligation to do good around them to make society stronger. That gives a higher sense of purpose to the company, and it also makes sure that we’re ultimately fulfilling the promise of why corporations exist in the first place.
And corporate social responsibility is just one aspect of that. Using our resources to make our community stronger is another part of that. And helping other organizations that are helping those most in need in our society, that’s another way we do it, especially with our product.
