Have you ever looked at the structure of your organization and wondered why some teams seem to work seamlessly while others struggle to get anything done? The answer may lie in a principle you’ve already heard of: the “Two Pizza Rule.” Popularized by Jeff Bezos, it’s the idea that a team should be small enough to be fed by two pizzas. Simple, right? But there’s a profound reason why this works, and it’s tied to something called Conway’s Law.
Let me explain.
Conway’s Law tells us that the systems you build will inevitably reflect the structure of the teams that design them. If your organization is fragmented or overly complex, your software will mirror those flaws. Conversely, if your teams are well-structured, clear, and independent, your systems will thrive. This insight is a game-changer for anyone building software—or, frankly, running any kind of team.
Why Structure Matters More Than You Think
I learned this lesson firsthand while leading the development of integrated event organizers systems suite, an event-driven micro-services architecture. The project was ambitious, with 80+ services working together seamlessly. But as I quickly realized, the success of the system wasn’t just about the technology—it was about the teams building it.
You see, micro-services thrive on autonomy. Each service has a single, clear responsibility, communicates through well-defined APIs, and operates independently. Sound familiar? That’s exactly what the Two Pizza Rule is all about. Small, cross-functional teams mirror the modularity of micro-services. They are independent, agile, and focused—exactly what you need when tackling complex challenges.
The Two Pizza Rule and Conway’s Law
Here’s where it gets really interesting: the Two Pizza Rule is a practical application of Conway’s Law. Think about it. If your organization is made up of small, nimble teams, the systems you design will naturally reflect that structure. They’ll be modular, efficient, and easy to scale.
But the opposite is also true. If your teams are too large or fragmented, your software will end up bloated, full of dependencies, and hard to maintain. I’ve seen it happen more than once—large teams produce systems that look like committee work: disjointed, slow, and overly complicated.
By keeping your teams small, you’re not just setting them up for success—you’re ensuring the systems they build are designed for success, too.
Why Small Teams Work Better
In smaller teams, communication channels are simplified. With fewer people, the number of potential interactions is drastically reduced, making it easier to align on objectives and share ideas. This efficiency accelerates decision-making, eliminates unnecessary noise, and minimizes misunderstandings. Instead of spending time clarifying roles or chasing approvals, team members can focus on meaningful, impactful conversations that drive progress.
1. They Communicate Efficiently
In a small team, every individual’s role is both visible and significant. There’s no room for ambiguity, and contributions—or the lack thereof—are immediately apparent. This clarity fosters a strong sense of ownership among team members, motivating them to deliver their best. When everyone understands their responsibility and its direct impact on the team’s success, it creates a culture of trust and accountability where excellence becomes the norm.
2. They Foster Clear Accountability
In a small team, every individual’s role is both visible and significant. There’s no room for ambiguity, and contributions—or the lack thereof—are immediately apparent. This clarity fosters a strong sense of ownership among team members, motivating them to deliver their best. When everyone understands their responsibility and its direct impact on the team’s success, it creates a culture of trust and accountability where excellence becomes the norm.
3. They Adapt Quickly to Change
Priorities shift—whether it’s due to evolving customer needs, market dynamics, or internal realignments. Small teams are inherently agile. They can pivot quickly without getting bogged down by bureaucracy or lengthy chains of command. This flexibility enables them to seize opportunities, respond to challenges in real-time, and stay ahead in fast-paced environments.
4. They Create Focused, Modular Systems
Small teams naturally align with the principles of modularity. Much like microservices in software design, they focus on specific, well-defined objectives. This reduces overlap, eliminates dependencies, and ensures that every team member is working toward a shared, clear goal. This modular approach not only enhances productivity but also makes it easier to integrate contributions across teams, ensuring seamless collaboration on larger projects.
We embraced these principles wholeheartedly. Each micro-team was given full ownership of a specific service, from initial design to final deployment. This autonomy empowered our teams to take pride in their work and deliver results that exceeded expectations. By clearly defining responsibilities and giving teams the freedom to innovate, we didn’t just improve the quality of our output—we cultivated a culture of commitment, creativity, and accountability.
Small teams aren’t just efficient—they’re transformative. They create an environment where everyone’s voice matters, adaptation is second nature, and excellence is a collective goal. In a world that demands agility and precision, small teams have a unique edge—and we harnessed that to its fullest potential.
How We Build Micro-Teams That Work
Looking back, here are a few key lessons we applied:
1. Defined Clear Roles & Goals
Just as every micro-service had a single responsibility, we ensured every team member knew exactly what they were accountable for. By clearly defining roles, we eliminated overlaps and confusion, which allowed the team to focus entirely on their objectives.
2. Minimized Dependencies
We encouraged our teams to solve problems within their domain before seeking external help. This approach kept projects moving forward without unnecessary delays. When dependencies outside the team arose, we treated them as opportunities to innovate and streamline processes, making teams more self-sufficient over time.
3. Communicated Like APIs
We treated our teams like micro-services, setting up clear communication protocols for how they interacted with one another. Internally, we aimed for communication saturation, ensuring that everyone within the team was fully informed and aligned. Whenever cross-team communication was required, we treated it as a problem statement to solve. This led us to ask questions like, “Why is this dependency here?” and “How can we reduce it in the future?”
4. Encouraged Puzzle-Like Diversity
We deliberately built teams with specific pieces of the puzzle that fit well together. By encouraging diversity in skills and expertise within teams, we reduced external dependencies while fostering autonomy. Each team became a self-contained unit, equipped to make decisions and tackle challenges independently. This diversity also sparked innovation and helped us approach problems from multiple perspectives.
5. Celebrated Autonomy
We gave our teams the freedom to make decisions within their scope. By trusting them, we saw remarkable results. Autonomy not only accelerated decision-making but also boosted morale. Team members took ownership of their work, creating a culture of accountability and pride in the outcomes.
From Micro-services to Micro-Teams
The success of the project wasn’t just about building great software—it was about building great teams. The Two Pizza Rule gave us a framework to align our team structure with the architecture we were designing. By keeping our teams small, we created a system that was agile, scalable, and resilient.
And here’s the best part: this approach doesn’t just apply to software. Whether you’re running a marketing department, managing a product launch, or leading a creative team, the principles are the same. Small, focused teams will always outperform large, unwieldy ones.
Why This Matters to You
If there’s one thing I want you to take away, it’s this: the structure of your teams isn’t just an operational decision—it’s a strategic one. By adopting the Two Pizza Rule, you’re not just making life easier for your teams; you’re setting your entire organization up for long-term success.
So, the next time you’re assembling a team, think like a micro-services architect. Keep it small. Keep it focused. And remember: just like a well-designed system, a well-designed team is one that works seamlessly, scales effortlessly, and delivers consistently.
Because in the end, great teams build great things. And sometimes, all it takes is two pizzas to get started.
