The “dozen-bagel” secret to preserving startup spirit as your company grows

In 1998, my friend Dave Schappell (no, not comedian Dave Chappelle) joined fledgling Amazon.com as (roughly) employee 100. He helped launch Amazon Marketplace, Amazon Associates, Amazon Auctions, and some of their other platforms. He was also the person who recruited me to join AWS in 2004. By that time, the company had grown to approximately 5,000 employees, and Dave left Amazon to found a startup called TeachStreet. Eight years later, in 2012, Amazon acquired that startup and Dave again found himself employed by Amazon, which by that time employed more than 75,000 people.

Shortly after he rejoined Amazon in 2012, I called him up with a simple question: How would you compare and contrast those three companies—Amazon at 100 people, 5,000 people, and now 75,000 people? He thought for a few moments, and then said this: “You know, it’s the same company. The same sense of urgency. The same bounce in people’s step. The same intelligence. It’s awesome.” In 1998, there was a single floor full of employees in its Seattle office, full of startup hustle and drive. In 2012, it was the same picture, only there were nearly a thousand such floors full of Amazon startups scattered all around the world. It’s truly amazing to think about how Amazon scaled its culture so many times over.

As a leader, we’re constantly trying to instill a sense of importance and urgency to the work our teams undertake. Yet as a company gets larger, it seems almost like an unwritten rule that things will slow down, people will lose a connection to the work, politics take over, and urgency will diminish—short of some existential threat. However, at least according to my friend Dave, Amazon didn’t suffer that fate. Whether you’re already a big company, looking to bring back agility, or if you’re a small company with aspirations of growing while keeping your edge, what can we learn from the successful scaling that Dave described? At the heart of Amazon’s scale are small teams with empowered, mission-driven leaders. In essence, a collection of startups.

It’s exactly the same for small teams within a large company, which is why they’re crucial. Amazon’s structure built on teams of no more than ten people is a testament to how to scale up a company without losing the urgency, focus, and quality of talent that characterizes a startup by building a large company out of what are essentially many startups. Among other things, it eliminates complexity of collaboration, which grows rapidly with the size of a company. That means it’s (almost) exponentially more difficult to coordinate a company as it grows. If you’ve experienced this in your company, it’s not just you, it’s math.

Coordinating a ten-person team requires forty-five relations between people, but coordinating a hundred-person team results in nearly 5,000 relationships, and coordinating a 1,000-person company requires nearly 500,000 relationships to work. Amazon at 75,000 people in 2012 could have necessitated 2.8 billion relationships, making it 500,000 times as confusing and soul-crushing to navigate as the 100-person company it was at the start. Yet that wasn’t the case. It felt like the same company—a modern miracle built on small teams.

Two-Pizza Origins

Around the turn of the millennium, Amazon was a fast-growing startup yet innovation was starting to slow. According to then Amazon CIO (and now Twilio board member) Rick Dalzell, the codebase was a monolithic hairball and the product development was organized into a few big divisions, like browse and search, fulfillment, shopping cart, etc. It was getting slower, and harder for people to ship code because so many people had their hands in the same code. Aside from code, there were too many decision makers poking into everybody’s work, because everybody’s work was so utterly intertwined. As you can imagine, it was frustrating for engineers and product managers who struggled to build their ideas, and it was especially frustrating for CEO Jeff Bezos.

Most years, Jeff would spend a week offline, devoted to deep thought on the business. These annual “brain-benders” gave him time to rethink first principles and write down these ideas, usually resulting in a series of one-page documents with new ideas he brings back to his leadership team. Rick recounts how in 2001, Jeff went on his retreat with the slowing pace of innovation on his mind. So he came back with a simple idea: if teams were organized into startup-like sizes, if they owned their road maps and they owned their code so they could move quickly, they could act like startups again, just like they had in the early days of Amazon, when Jeff remembered they could feed the whole team with two pizzas. But in order to work together, they’d need to build a bunch of APIs so they could interface with each other. This would enable them to move independently, with the relationship between teams formalized in technology. With this one pager, the “two-pizza team” was born. Rick went back to his leaders and within a week, had turned Jeff’s initial idea into a six-page workable plan that Amazon quickly adopted.

Dozen-Bagel Teams

At Twilio, we had already started organizing Twilio into small teams. But that 2012 conversation with Dave Schappell confirmed for me that this was the best way to scale the company while keeping our edge.

At the beginning of Twilio, it was just Evan, John, and I—three developer-founders. At that size, we could hold the entire business in our heads. On any given day, we might ideate some new idea, write some code, support customers on email or phone, pay the bills, and even make a Costco run to stock the office. We were constantly building demo applications on top of our APIs, so we knew the kind of experience our customers were having. When we did customer support, we gained an instinctual understanding of what customers were trying to accomplish, where we were falling short, and where we needed to keep investing.

In one instance, I remember a customer reported a bug on Twitter and I wrote the fix within five minutes—but actually held off deploying it for a day because I didn’t want us to look like such a small company. That was just a bug fix, but I recall times when we took customer insights and turned them into whole products in a matter of days. One such product is our “sub-account” system that enables developers to segment their usage of Twilio into multiple buckets—it’s useful for software companies building on Twilio who they, themselves, have many customers using their apps. We had a realization that such a feature would be useful, and I built it one night and deployed it the next day.

That’s the magic that makes startups so special and so productive. There’s so little overhead to manage, the coordination energy is negligible, and people tend to have a tremendous intrinsic drive because they’re so close to the customers, and therefore, the mission. Startups can succeed or fail based on many factors, but motivation and speed are not usually the fatal flaw. Who wouldn’t want that kind of energy in their business? I’ve never met a business leader who doesn’t want employees to feel that kind of intrinsic motivation and drive to succeed, yet the way we usually structure our companies deprives employees of the raw ingredients. Our organizational charts separate employees from customers, our decision-making processes leave employees feeling unempowered, and success becomes navigating the organization as opposed to serving customers. Nearly all companies succumb to varying degrees of this fate as they scale.

In those early days, the three of us met every Monday midmorning to start the week, and somewhere along the way I began stopping on my commute to pick up bagels—three bagels to be exact. As the company grew, so did our Monday mid-morning meeting, and so did my bagel order. I soon was buying a half-dozen bagels. Then a dozen bagels. Then two dozen bagels. Then three dozen. And as the bagel orders grew, I found it was getting harder and harder to hold the whole business in our heads. (It was also harder and harder to carry the bagels.) In particular, I also noticed that the way we’d been running the company wasn’t working well anymore. People couldn’t see the whole picture anymore, so they didn’t intuit the plan the way we had done as a small team. Employees started to silo. Engineers didn’t talk to customers anymore; only the support team did. Some people were working on our first product, Twilio Voice, while others had started building our second product, Twilio SMS, and others were working on building infrastructure. Each knew what they were working on, but didn’t have the whole picture anymore. I also realized that new employees weren’t having the same experience we had—many of the new engineers weren’t handling support requests, and our new support people hadn’t built an app on Twilio to understand the product inside and out.

With about thirty people on the team, I was growing frustrated and so was everybody else on the team. It wasn’t clear why people couldn’t see the whole picture the way Evan, John, and I could back in the early days. One day I was at a meeting of CEOs that one of my early investors, Albert Wenger of Union Square Ventures (USV), had organized. Asked how things were going, I replied honestly (as I tend to do): “Well things feel pretty shitty, nothing is working on the team anymore.” Fred Wilson, a cofounder of the firm, asked me to draw the org chart, something I’d actually never done before.

I picked up a marker and I drew this:

“There’s your problem,” Albert declared, correctly. I had never thought about the org chart before. We’d just kept hiring people and, as with all people before them, they reported to me. Once we’d crossed about ten people, the straight-line org chart became the source of our dysfunction—so obvious once I wrote it down. The problem was that we’d outgrown the capacity for the team to internalize the entirety of what we were doing. So I came back with a plan to divide the company into smaller teams, but how to divide things up?

One obvious solution is to divide things functionally—the support people work together, the engineers work together, the product managers work together, and so on. Thinking back to the days when Evan, John, and I all did customer support, designed products, and wrote code, I wanted to figure out how to replicate that experience for the entire team as we grew.

First, we instituted an idea that all employees would do some amount of customer support—not as their full-time job, but enough to maintain a customer connection. We asked all new employees to handle fifty support tickets in their first couple weeks to get to know our customers, our product, and how we approached service to our customers. We also started asking all new employees to build an app using Twilio—not just the developers, everybody. Obviously the sales reps and customer service agents would be well served by using our product. But we also asked the lawyers, the accountants, the analysts—everybody—to build something using Twilio so they knew what we enable customers to do. The point was to build more connections between our employees and our customers. To this day every new Twilion, no matter their role, learns the basics of coding and builds an app on our platform. When they complete their app they earn a red Twilio track jacket—a true badge of honor!

The most meaningful change was the beginning of our “small teams” approach to team structure. We went from a group of twenty-some people and divided nearly everybody into three teams: Twilio Voice (our existing product), Twilio SMS (our upcoming product), and Twilio Infrastructure (our internal platforms)—each small enough to be fed by a dozen bagels (to continue with Twilio’s food item of choice).

On the surface, this seems like an obvious way to structure the company at that moment, but as those teams grew, we repeated the process, continually dividing the teams back into small startups. When you have two products and some infrastructure, it’s easy. But dividing the team up repeatedly over the years is harder than it sounds because there are a thousand ways to execute on this idea.

Here’s what we’ve learned over the last ten years, expanding from those three initial teams to now over 150 small teams within R&D.

Customer, Mission, and Metrics

For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving. This could be an external customer in the traditional sense, or could be an internal customer they’re serving. For a product-facing team, identifying the customer segment or persona can be useful. For example, this team is building for small businesses or that team is building for consumers. That’s a fairly obvious part of establishing a new initiative. But it’s less obvious for an internal team, which actually makes it more important to articulate and document. For example, the Infrastructure team I mentioned earlier explicitly stated that their “customers” were the other internal developers at Twilio. That helps clarify why they wake up every day. If they need direction, they need to ask their customers about their biggest problems. Lacking a customer, then the loudest voice or the highest pay grade decides what people should work on. But having a customer grounds the team’s work in discoverable truths that customers can express.

Last, to measure progress against this mission, and to know if customers are being served by the team’s existence, they need measures of success. Many companies would consider these objectives, as in a Management By Objectives (MBO) system or an Objectives and Key Results (OKR) system. Call it what you will, but I believe these should be relatively long-lived measurements that tell the story of progress toward the stated mission, versus objectives that change quarterly. For example, when our Infrastructure got started, our build system, which packages our code for deployment to servers, was horribly broken. It could take half a day to build and deploy our software, and half of the time the build would fail for unknown reasons. It was killing developer productivity. So the Infrastructure team took on a measure of “time from code check-in to deployment.” In the short term, it was clear they had some cleanup to do, but over the long term, this is a clear measure of engineering productivity that the Infrastructure team could impact. Note, it wasn’t “fix the build system” or “reduce errors from 50 percent to 5 percent” because those represent short-term projects, rather than long-term measures of progress toward achieving the mission.

The other benefit of a small, driven team: nobody can hide. If you’re a cog in a machine, or one of dozens or hundreds of people on a project, it’s easy to feel like your contribution doesn’t matter, which is bad for morale and does not make the most of every employee’s skills and talents. It also makes it easy for a low performer, or somebody who’s checked out, to coast along. But on a small team of 5–10 people, neither of those things is possible. Everybody has an important role, and there’s little room for somebody who isn’t giving it their all (and trust me—this becomes very apparent).

Defining customer, mission, and metrics is the foundation of the small team.

Excerpted from the book Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century. Copyright © 2021 by Jeff Lawson. The book will be published on January 12, 2021, by Harper Business, an imprint of HarperCollins Publishers. Reprinted by permission.