Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century – A Management Playbook for Tech Industry Leadership and Digital Transformation

by Jeff Lawson

Twilio is what allows you to text your Uber driver or order a pizza online. It’s built into Hulu and Twitter and Salesforce to help with communication and information sharing. It plays roles in the real estate industry and health care, as well as numerous nonprofits and relief organizations. It’s helping businesses that never imagined themselves as digital companies make extraordinary transformations and grow under intense pressure to evolve or face their own demise.

That would at least address our biggest challenge, which was that we were a successful business that nobody had heard of.

We didn’t do a ton of marketing, and we employed only a handful of sales reps. Most of our employees at the time were engineers. If someone wanted to find out what Twilio did, the best way to do that really would be to ask a developer.

The message worked because we didn’t try to explain what we do. Instead, we provoked a conversation.

Part I Why Developers Matter More Than Ever

.h1

Chapter 1 Build vs. Die

.h2

The key to Amazon’s success is that Jeff Bezos understood way sooner than everyone else that he was actually in the software business.

Instead of just automating back-office chores, software became the face that a company presents to the world. Instead of walking into your bank, you used an app. You didn’t walk into a store, you shopped online instead. This had two critical implications for the world of software: First, customers suddenly did care about the software that companies used because the customers directly interfaced with it. If you had a better website or mobile app than your competition, it would be a good reason for customers to pick you. Second, it meant that new competition could enter the market more easily. To become a bank or a retailer, you didn’t need to open up a branch or store on every street corner. You just needed an app and a warehouse somewhere.

That’s why I call this a Darwinian evolution of every industry. It’s no longer a question of Build vs. Buy. Rather, it’s the existential question of Build vs. Die.

As Jeff Immelt, the former CEO of GE and a member of our Twilio board of directors, once told his executive team at GE: “If we don’t become the best technology company in the world, we’re doomed. We’re dead. There’s no Plan B.”

To truly thrive in the digital era—either as a disruptor or those fending off the disruptors—you need to think like a Software Person. Now, a Software Person is not necessarily a developer—it’s anybody who, when faced with a problem, asks the question: “How can software solve this problem?” That’s because being a Software Person is a mindset, not a skill set.

Developers can’t iterate on things that are fixed in plastic and metal—once the gizmo leaves the factory, its functionality is set for life.

The worst thing is that everything takes too long. The purchase process itself takes forever, beginning with a “request for proposal,” or RFP. You will spend months reviewing proposals and listening to sales pitches from software vendors who hope to win your business. You’ll run “bake-offs” to compare the products. Meetings are held. Opinions are solicited. Presentations are given.

In 2015, an ING engineering manager named Theo Frieswijk reached out to us looking for help building a new contact center system.

Theo pitched management a different idea. Instead of buying yet another monolithic system and hoping for a better outcome this time, why not let his team build their own contact center system from scratch, which would allow them to build as needed to solve each incremental problem or try each new idea.

These dynamics are playing out in every industry, all around the world: in Munich, at Allianz, the world’s biggest insurer; in the United States, at Domino’s, Target, and U-Haul. Whether they are cooking pizzas or writing insurance policies, renting trucks or delivering tulips—no matter what their business, they’re all becoming software companies.

Chapter 2 The New Software Supply Chain

.h2

But now every company is becoming a software company, and most companies can’t build everything from scratch. They need a supply chain—just like Ford and Toyota—that divides the industry into areas of expertise and allows each company in the ecosystem to specialize on its core competency.

These are Application Programming Interfaces (APIs). Each API supplier provides only a piece of the solution. Amazon Web Services delivers the data center. Twilio provides communications. Stripe and PayPal enable payments. Modern apps integrate dozens of these small components into a unique value proposition for the customer.

I call it the Third Great Era of Software.

At first, companies ran mainframes. Many still do—more than you might imagine, in fact. Then came minicomputers, Unix workstations, and finally the PC. Anyone under the age of thirty might not remember this, but when the personal computer came out, the software programs literally came on floppy disks. Later they shipped on CDs. Software literally came in boxes!

From mainframes to PCs, the computers kept getting smaller, the operating systems changed, but the software industry pretty much used the same business model. A software maker would invest R&D dollars to create an application, then sell it to individual users or to huge enterprises.

But for these business customers, the whole scheme was a huge pain in the neck. Each company had to have its own IT department, which would rack and stack servers, and install and maintain this infrastructure. Most of the software programs were ones that ran back-end office chores, like financials and ERP. These big enterprise software projects were notoriously prone to failure—at one point, more than 70 percent of these big installations were never actually completed successfully. These projects took so long to implement that oftentimes multiple generations of company leaders would come and go before they were completed.

And importantly, companies weren’t using all this software to deliver better experiences to customers or differentiate themselves in the market. They just used software to run their internal operations—accounting, enterprise resource planning, and the like.

This problem got solved when the second era of software—Software as a Service (SaaS)—began, about twenty years ago. The company that pioneered this model is Salesforce.

With SaaS, line-of-business owners who needed a new software program didn’t need to send a request to the IT department and then get in line and wait for them to undertake a huge multimillion-dollar, multiyear initiative. Instead, the head of sales could just go to Salesforce, fill out some online forms—and almost instantly have their whole department up and running on a best-in-class

Over time, SaaS companies sprang up to serve every line-of-business owner. The chief financial officer (CFO) reached out to NetSuite, provider of SaaS financials software. The chief marketing officer signed up for Marketo, provider of SaaS marketing automation. The chief human resources (HR) officer signed up for Workday, provider of SaaS HR information software.

The model also came to be known as cloud computing, which became possible because of high-speed Internet connections and what’s called “multi-tenant” software. Once we had superfast Internet backbones, people realized you could zip bits from a server located thousands of miles just as quickly as you could from a server down the hall or across campus in the company’s own data center.

Another change involved the business model. Instead of paying to license a program based on how many servers you deployed—including a big initial payment up front and then paying annual maintenance fees—you just subscribed.

Amazon was going to build enormous data centers and rent compute-power and storage capacity not as applications, but as building blocks that developers and other companies can use to build their apps. This would enable any developer and every company to leverage Amazon’s mastery of web-scale infrastructure.

The pay-for-what-you-use model was a huge breakthrough—maybe as significant as the technology itself.

For decades companies bought way more capacity than they needed and were vastly overprovisioned. CPUs sat idle.

Switching to AWS meant not only that you no longer had to buy expensive hardware—you also didn’t have to hire a huge 24-7 IT department to manage all that hardware.

Other implications of AWS were not immediately apparent. One was that AWS would drive down the cost of launching a new company—to almost zero.

the most interesting implication of AWS was that it changed not just the way computing power was bought, but who was buying it. In the traditional world, IT decisions were made by people near the top of the organization—the CIO or the CFO. That’s because these were high-stakes decisions, with years of work and millions of dollars being decided. At AWS, however, a lot of customers were just ordinary developers. Individual engineers or department managers could spin up a server and storage capacity at AWS just by entering a credit card number.

In 2000 Amazon had a giant monolithic mess of engineers and code powering the fast-growing retail business. Engineers were stepping all over each other, and the coordination energy to get anything done was massive. Things were slowing down, so Bezos wrote the “two-pizza team” memo proposing that they divide the company into small teams in order to move faster.

How can you organize a company into a bunch of small, independent teams when their work is all intrinsically tied together in the code they write? They can’t truly perform independently when the changes one team made to the code broke the code other teams were working on. It just wouldn’t function. The answer turned out to be keeping the code and the teams together. As Amazon split the organization up into small teams, they also kept carving up the code into small pieces so the teams could “take it with them” and operate it independently. These teams and their respective code needed a way to talk to each other, and “web services” turned out to be the answer.

Over time, these became known as “microservices” because each individual service typically did one thing, and did it well.

These microservices were delivered not as a pile of code, nor as a website, but as a web-based API. APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date. So at Amazon, an internal culture of API documentation arose.

Small teams are accountable for the efficiency of their service, because they have to effectively publish a “price” for internal customers, and those internal customers have to pay the costs out of their P&Ls.

But here’s where it gets even more interesting. Once you’ve divided and subdivided the business into small teams that specialize in particular areas, offering microservices for each other to use, with well-documented interfaces and pricing that represents the true costs of delivering those services—well, why develop all of those microservices internally? Why devote your own developers to microservices that you could instead buy from other companies?

Soon people started figuring out that you could make a business out of building microservices and selling them to others.

Stripe developed payment processing services. Twilio developed a cloud communications platform.

Part II Understand and Motivate Your Developers

.h1

Chapter 3 Hi, I’m Jeff, and I’m a Developer

.h2

First, we needed a name. I’m a big believer in having a unique proper noun for the company that can be owned completely. We started making sounds with our mouths—literally just expressing syllables that sounded remotely like telephone. “Teliph.” “Telefoo.” “Telapia.” Nope, that’s a fish. We kept making sounds. It must have been hilarious to listen to, but we didn’t care. After about twenty minutes, I said: “Twili. Tweli. Twilio.” The last one had a ring to it. Amazingly, Twilio.com was available for seven dollars, so I bought it. That was that. We’d named our company.

Writing software that could interact with the telecom system turned out to be an insanely difficult challenge.

First, having built four startups, I’ve learned that building software is actually pretty easy but building the right thing is hard.

So rapid iteration, experimentation, and close contact with customers are the prerequisites to innovation.

That working style exposes a truth that seems simple but is actually rather profound and surprisingly rare: the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions.