Amazon has an adage: If you can’t feed the team with two pizzas, the team is too big. At Twilio, a commitment to small teams is a cornerstone of how we operate. As we’ve grown from tens to thousands, our teams have remained independent units of no more than 10 people.
At the center of our philosophy is autonomy. No matter how big the company, we trust builders to have full ownership and responsibility over their software, allowing them to serve as the functional CEOs of their own teams. This organizational structure has allowed us to scale rapidly and to continuously ship communications solutions that put customer needs front and center.
From a few to 40
When Twilio first started, in 2008, its engineering team was made up of just a few developers experimenting and shipping solutions. At that point, everyone at the company reported directly to three cofounders. All developers were aware of what their teammates were working on, and the horizontal structure helped early employees feel heard and empowered.
We came to a crossroads when we reached about 40 employees. With fewer than 40 people, we were able to move quickly: Almost all communication between teams happened verbally and in real time. At that size, it was possible to keep everyone in the loop with weekly all-hands meetings and good in-person communication. Projects and actions were handled without much being written down. And if the work was documented, the record tended to be brief and focused on the specifics of the task, rather than on best practices that would translate to future productivity.
But with new people joining every week, we soon discovered that some teams interpreted company knowledge, and educated and trained employees, in one way, while other teams approached the same tasks slightly differently. As a result, teams shipped code that had to be rewritten, multiple teams worked on distinct solutions to the same problem, and (exactly the opposite) certain components were never written because each team assumed that another team had it handled. This meant that processes were slower, less efficient, and sometimes less reliable.
We realized that we needed more structure. We had to start writing things down: describing the context, the task, and what to know for next time. We also needed to establish team standards and parameters that worked in tandem with experimentation. So we sat down and codified our beliefs. The ideal team size for tackling challenging problems is no fewer than five people and no more than 10: large enough to have critical mass and small enough to maintain consistent, streamlined communication.
From 40 to hundreds
We scaled quickly with the small-teams model. Then, in 2016, when our product-development organization comprised of hundreds of people, we reached another tipping point. At that time, we were using a functional structure, with teams grouped based on specific expertise and skills. This provided clear accountability, but a major downside was the constant context-switching required of engineering and product-management leadership, who were facing a large, horizontal product portfolio. Imagine the stress of moving between 10 or more meetings in a day, all on completely different products and projects! The drain on productivity and creativity was significant.
Another challenge was that accountability for product performance was shared across multiple managers. We learned that shared accountability leads to a lack of accountability. Given the breadth of Twilio’s product portfolio, we had simply outgrown our original functional structure. So the year of our IPO, we restructured. We kept the small-teams model, which continues to enable our dexterity and speed, but we moved to a business unit–based system, which mirrored our product portfolio. This built on our existing agility, while clarifying accountability and giving everyone a clear mandate and focus.
Going forward, each team (made up of no more than 10 people) had full ownership over their solutions and projects. Instead of following the traditional model, in which engineers wash their hands of a product once it’s shipped, we aligned product managers and engineers in order to create cohesive ownership. When teams got too large, or someone had an idea that they wanted to pursue, new teams could split off. Anchored by these small teams, our business unit–based structure allowed Twilio to become a collection of startups working symbiotically within a large company.
From hundreds to thousands
Today, Twilio’s structure prioritizes agility alongside resilience. In the manner of a startup, new teams get a seed investment from the company, which includes budget, resources, and head count. Like any startup, our teams evolve through various levels of maturity—starting with an idea yet to be proven, a business plan, and room for experimentation and freedom. As the product idea is proven and the solution matures, the level of standardization increases. An example is the team working on our Programmable Wireless platform, which allows companies to connect IoT devices to global cellular networks. One of our early employees pitched the idea, the platform launched in 2018, and the team now runs as a company within Twilio. It has its own operating budget and go-to-market road map, as well as its own general manager, head of business, and a team of engineers.
We want everyone to feel ownership over their product throughout this process, and we accomplish that through balanced leadership roles. The product manager plays the role of the CEO within the small team and answers the “what” and “why” questions about the product. The engineering leader is the COO, a counterbalance to the CEO, and focuses on the “how” and “when.” The architect concentrates on what the team is building today, as well as how that fits into the wider business and Twilio’s future plans. We strive to empower every team member to make decisions based on customer needs.
When roles are balanced and accountability is clear, a strong small team can accomplish things that bigger teams can’t—and ship multiple times a day. Because there’s nothing else in the way of their goal, they can stay laser-focused, executing tasks at the drop of a hat without an onerous approval process. And clarity of ownership means clear accountability—which keeps everyone honest.
Today, over 6 million developers have clear expectations of our product and rely on our technology to support their businesses at scale. Those developers build for companies ranging from startups to enterprise-level organizations. We can’t afford to break something that is foundational to their business: Structure and predictability are nonnegotiable. But contrary to popular belief, we’ve seen that you don’t have to sacrifice internal flexibility and innovation to operate at scale.
Without standards and guardrails, our more than 150 small teams would have to reinvent the wheel for each project. Instead, our architects and technologists constantly look for standardization opportunities: places where they can build consistent self-service platforms to enable Twilio’s engineering teams to move fast without having to waste time on the basics. Self-service is important because it implies a low number of dependencies. We want teams to be able to innovate at their own pace, while standardized platform solutions keep quality consistent and collect joint learnings.
Small teams aren’t the answer for every company, but for high-growth businesses that value both nimbleness and resilience, this model can be a game changer. Small teams enable independent execution, which means faster innovation. Meanwhile, a business-unit structure and codified processes give that execution a consistent vision and accountability. Our self-service platforms continue to serve as Twilio’s foundation, allowing our teams to move quickly with confidence (and without breaking things). This combination guarantees the durability of our platform.
Often in tech, management structure and process are cast as the enemy of innovation. At Twilio, however, we’ve seen that structure and process can support and boost innovation when paired with small teams, even while expanding to a global enterprise. We’re going to need more pizza.