Smaller Teams = Better Results: The Two-Pizza Rule

The Two-Pizza Rule: Why small teams lead to big success

Jeff Bezos didn’t just leverage the basic insight of Gall’s Law to develop what has become Amazon’s fastest-growing internal unit — he is also responsible for popularizing one of his own tech rules.

In early 2002, Bezos decided that to reduce communication overhead and improve productivity, all of Amazon would be re-organized into so-called “two-pizza teams” — squads small enough that just two pizzas would be enough to fully feed them when working late in the office.

While this has also been interpreted as a rule for meetings — either capping the maximum size of meetings at Amazon or capping the size of meetings that Bezos himself will attend — the original formulation was an edict about team size.

WHY TWO-PIZZA TEAMS GAVE AMAZON A STRATEGIC ADVANTAGE

For analyst Benedict Evans, the two-pizza rule has been a crucial structural advantage for Amazon.

The root of the two-pizza team idea was Bezos’ attitude toward both centralization and communication. Bezos wanted Amazon to remain nimble even as it grew, and that started with encouraging independent decision-making rather than an over-reliance on hierarchy.

And Bezos hated the overhead created by excess communication. In “The Everything Store,” Brad Stone quotes Bezos as saying that “communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.”

Source: Getty Images

The main advantage this conferred upon Amazon was simple: smaller and independent teams meant the ability to spin up new teams much faster, giving Amazon the power to scale more cheaply, explore new ideas easily, and ultimately ship more products to customers.

While many of the new initiatives spearheaded by these small teams have failed, some — like Prime, Kindle, and AWS — have become core businesses for Amazon.

For Bezos, it comes back to the idea of building a corporate structure that can generate the maximum amount of innovation for customers. Big, centralized teams maintain companies. Small, autonomous teams find new ideas.

“We have the good fortune of a large, inventive team and a patient, pioneering, customer-obsessed culture — great innovations, large and small, are happening every day on behalf of customers, and at all levels throughout the company,” he wrote in his 2013 shareholder letter. “[Decentralized] distribution of invention throughout the company — not limited to the company’s senior leaders — is the only way to get robust, high-throughput innovation.”

In other words, as Benedict Evans writes, “you don’t (in theory) need to fly to Seattle and schedule a bunch of meetings to get people to implement support for launching make-up in Italy, or persuade anyone to add things to their roadmap.”

There is a machine, and then there is a machine to build the machine, says Evans. And Amazon’s two-pizza rule ensures that the company, aside from being a ubiquitous tech leviathan, can operate a machine to build more Amazons.

SPOTIFY’S SQUADS COMBINE AUTONOMY WITH RESPONSIBILITY

The concept of small, autonomous teams has become extremely popular in the tech world over the years, and some of the biggest and most successful companies have adopted similar ideas to the two-pizza rule to help make their people more efficient and productive.

Spotify is one example of a company that abides by the smaller-is-better rule when it comes to organizational structure.

Source: Getty

The music streaming app organizes teams into 8-person squads, with the function of each squad determined autonomously, rather than being directed from above. Each squad functions as a mini-startup inside Spotify: cross-functional, self-sufficient, and sharing the same geographical location.

One unusual feature of Spotify’s squads is the lack of a designated leader or manager, with each squad member equally responsible for results. In the vein of autonomous operations, any leader of these squads emerges organically and informally. The company uses the squad structure to encourage greater innovation, disruptive thinking, and complete accountability, without the burden of excessive control.

Squads with similar functions across the organization are then grouped under tribes, chapters, and guilds. While tribes act as incubators and provide support for the development of squads, chapters connect employees based on specific skill sets such as web development and quality assurance. Guilds are a way to encourage knowledge sharing across the organization, irrespective of squad, function, or location.

This organizational structure is designed to support a bottom-up approach at Spotify. For example, best practices at the music streaming company only emerge after enough squads have adopted them.

Furthermore, by keeping teams highly autonomous, the structure “lowers the cost of failure” through ensuring that “failure has a ‘limited blast radius’ and affects only part of the user experience,” according to Michael Mankins and Eric Garton of the Harvard Business Review.

In the vein of Bezos’ idea of excessive communication being wasteful, Spotify looks to make communication more efficient by seating squads, guilds, and tribes that need to coordinate closer to each other.

NOT EVERYONE IS SATISFIED WITH TWO PIZZAS

According to organizational psychologist J. Richard Hackman, the more interconnections you have between people, the slower your decision-making and the higher the management costs for the organization.

As you add people to an organization, the number of communication links increases exponentially.

“The cost of coordinating, communicating, and relating with each other snowballs to such a degree that it lowers individual and team productivity,” writes blogger Janet Choi. Two-pizza teams solve this inherent scaling problem by artificially capping the number of links.

Despite the organizational clarity derived from the two-pizza team, not everyone at Amazon and in the wider tech world is a fan of the rule.

Some former Amazon employees and others believe the strategy was counterproductive, and some think that building products using two-pizza teams creates a disconnected user experience.

According to Brad Stone, the concept of two-pizza teams was unevenly applied throughout the Amazon. It took root most of all in engineering, while the idea barely touched the finance and legal departments.

Additionally, each team had to set up its own “fitness function” — some kind of quantitative, linear equation that could be used to judge whether that team succeeded or failed in its mission. For a marketing team, that might be the average email blast open rate multiplied by ensuing order value.

Yet, Stone writes, making some teams define this function for themselves was like “asking a condemned man to decide how he’d like to be executed.” For others, it was merely ineffective.

Kim Rachmeler, former VP at Amazon, said, “Being a two-pizza team was not exactly liberating. […] It was actually kind of a pain in the a**. It did not help you get your job done and consequently the vast majority of engineers and teams flipped the bit on it.”

Small, disconnected teams run the risk of producing disjointed products that don’t contribute to a seamless experience, according to product management consultant Matt LeMay.

For LeMay, the most important aspect of a product for a customer is not the individual features of a product, but how those features come together to deliver a cohesive experience.

Given the vast number of products that Amazon has put out over the years, and how cluttered many of its website’s menus can seem, it’s fair to say that Amazon’s drive for two-pizza teams has not been without its drawbacks.

TAKEAWAY

Jeff Bezos wanted small, autonomous teams that could be “independently set loose on Amazon’s biggest problems,” as Brad Stone writes. These teams wouldn’t have to waste cycles communicating with other teams, and they would each have all the resources and people necessary to launch new products. The result, Bezos thought, would be more creative offerings and faster results for customers.

Though not without its detractors, Bezos’ idea that over-communication between teams risks stoking inefficiencies is now commonly implemented at companies like Google and Spotify.

source: CBinsights

------------------------------

As for personal experience, I agree that the smaller team, in general, will produce a better product. The smallest team is ONE, and since I had the experience of developing TeleMagic completely alone for the first several years of its existence, and with only one other developer taking over for the next several years, there is no question in my mind that the smaller the team, the better the product. (Michael McCafferty)

The James Clear Newsletter

The James Clear Newsletter

The most wisdom per word of any newsletter on the web.

Free

Every Thursday. Short. Powerful. 

Click here


I have been a fan of James Clear for many years, 
and I only advertise products that I use myself,
and I do it for free.

Conway's Law: Corporate Structure Is Vital to Product Development

In 1967, the computer scientist Melvin Conway made a key observation about organizational structure.

The way that a team communicated and the design of that team’s products, Conway argued, were mirrored — one always reflected the other.

A droll illustration of Conway’s Law. Source: Manu Cornet, bonkersworld.net

In a simple explanation of Conway’s thesis, there are two pieces of software: software A and software B. If the developers of these two pieces of software don’t communicate, there’s no easy way for the software to integrate.

When communication between the developers occurs often and openly, on the other hand, the odds of a seamless experience are far greater.

HOW APPLE PRODUCES AN END-TO-END CUSTOMER EXPERIENCE

At Apple, teams are organized according to what’s called the Unitary Organizational Form. The basic idea — rooted in Conway’s Law — is that the company should be organized around functional expertise rather than products.

That means that instead of dedicated teams for products like the iPhone, the Mac, or the iPad, Apple has teams that work on design, teams that work on engineering, teams that work on marketing, and so on.

This structure encourages coordination between teams and helps Apple deliver a unified experience across products. No product is ever released that departs from the predominant Apple design, engineering, or operational paradigm. Even its credit card has an unmistakable Apple “feel.”

After the iPad first launched, Steve Jobs said this “post-PC device” needed to be “even easier to use than a PC” and “even more intuitive than a PC, where the software and the hardware and the applications need to intertwine in an even more seamless way than they do on a PC.  We think we have the right architecture not just in silicon but in our organization to build these kinds of products.”

Reorganizing Apple along functional rather than divisional lines was one of the first things Jobs did upon returning to Apple in 1997, and his successor at Apple, Tim Cook, still attributes the success of the company’s products to this move.

“We’ve found a way to make our products such that the experience is jaw-dropping,” Cook told Businessweek.

WHY GITHUB IS STRUCTURED LIKE AN OPEN-SOURCE PROJECT

GitHub provides an example of a company that obeys Conway’s Law while doing so in a remarkably different way from Apple.

Instead of integrating in order to promote an end-to-end experience, GitHub is intentionally structured like one of the open-source projects the service hosts: decentralized, autonomous, and asynchronous.

That structure reflects the kind of product GitHub has built — one designed for developers more than managers — as well as how that product works.

The GitHub tool is built for asynchronous collaboration: new code can be submitted anytime from anywhere, then reviewed at the responsible party’s leisure. Developers across the globe can use GitHub to collaborate on a project without having to deal with overlapping codebase changes or inconsistencies between their work.

The company itself is also built for asynchronous collaboration, with many of its basic organizational tenets ripped directly from the processes of open source development.

There are no codified standards about what time to come into the office, and most work is completely self-directed. “If you’re interested in working on something, then work on it,” wrote Zach Holman, one of the first engineers at GitHub.

Members of the team are spread out across the world, there are no daily stand-up meetings, and most of the communication they have with their colleagues happens asynchronously, over chat or email.

Collaborating asynchronously to the extreme is a way for the team at GitHub to stay close to one of the biggest problems they want to solve with the company: the difficulty of collaborating asynchronously when working on software projects. One of the ways they take on this problem is through “open, easy-to-use platforms” — precisely what GitHub itself is trying to build.

Apple, in other words, uses an integrated organization in order to build products that give the customer a seamless, end-to-end experience. GitHub uses an organization structured like an open-source project because its goal is to give its user base of developers a collaboration platform that allows distributed, decentralized teams to build great products.

TAKEAWAY

Conway’s Law helps explain not just how companies operate — and how their structures enable or hinder business activity — but also how they are managed.

As computer scientist Fred Brooks (we were at IBM in the mid '60s) has pointed out, for an organization that provides some good or service, the structure that it naturally takes on as it grows is unlikely to be the ideal system for delivering that offering. Remaining flexible is essential to the organization’s structure.

The people that run companies, in other words, must consider organizational design on a similar level as operations, R&D, and products. Much of what we attribute to the latter is rooted in the former.

source: CBinsights

Gall's Law: Why Simplicity Rules

Gall's Law, Free for Kindle at Amazon

Gall’s Law: Why the best products are built from simple systems

In 1975, the American author and pediatrician Robert Gall made an observation about systems that would go on to become hugely influential in computing.

“A complex system that works is invariably found to have evolved from a simple system that worked,” he wrote. “A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

This idea, originating in his book “General Systemantics,” would eventually become known as Gall’s Law. Since then, it has become one of the most important and foundational ideas in tech, especially when it comes to the design of new products.

HOW GALL’S LAW FOSTERS PRODUCTS THAT PEOPLE ACTUALLY WANT TO USE

One concept that can help illuminate the power of Gall’s Law is the idea of emergence: the notion that complex systems possess properties that the individual constituents of the system do not.

Powerful technologies can be built when users can manipulate and recombine individual pieces in order to create something of greater value.

Twitter, for example, was founded without reply or retweet functions. All users could do was post 140-character messages to their feeds.

Then Chris Messina proposed the idea of using a hashtag to collect all tweets relating to a single topic, and not long after, hashtags were added into the Twitter platform itself.

Replies and retweets followed later as the Twitter team realized that their users were trying to approximate these actions within their constrained set of possible behaviors.

Source: Getty Images

Twitter could have predicted that users of a public broadcasting app would want some way to share content with their followers, reply to other people’s messages, and even organize information along topical lines.

But cultivating an openness to what users actually did, rather than assuming they knew exactly what to build, was key to how Twitter developed into the product it would become. As co-founder Evan Williams put it, it wasn’t even clear “what [Twitter] was” in those early days, and the product took several turns before settling on what it is now.

This kind of emergence-friendly development process is more or less conventional wisdom in Silicon Valley today, with the creation of a “minimum viable product” (MVP) being standard practice within product businesses.

The thinking behind the MVP is simple and echoes the development processes followed both by Amazon in inventing AWS and by the team at Twitter: build a version of your product with just enough functionality that it can engage your core users. Roll that initial version out and start gathering data and feedback. Then, use that data and feedback to chart the path forward. When done right, the result is what Gall’s Law predicts: a complex system that has arisen from the organic growth of a much simpler system.

HOW AMAZON FOLLOWED GALL’S LAW TO DOMINATE CLOUD SERVICES

The development of Amazon Web Services (AWS) from an internal data storage service to a crucial backbone of the internet encapsulates the power of Gall’s Law.

AWS emerged from a relatively simple desire: Amazon needed a more modular system for its internal engineering work.

Every time a team at Amazon wanted to build out a new web feature, whether for internal use or for a retail partner, Amazon developers would end up building everything — from databases to computing power to storage — from scratch.

That’s when the idea emerged to build out each one of these functions as a modularized service. For one, the team had become highly competent at working on these functions. For another, the Amazon team was operating at a unique scale, being one of the biggest early internet companies.

It soon became clear that Amazon had an equally unique opportunity to make databases, computing, and storage easier for other companies and other developers to use.

“We tried to imagine a student in a dorm room who would have at his or her disposal the same infrastructure as the largest companies in the world,” Andy Jassy, head of AWS, told Brad Stone, author of “The Everything Store.” “We thought it was a great playing-field leveler for startups and smaller companies to have the same cost structure as big companies.”

Source: Flickr

While AWS today appears to be an intimidatingly complex system, it emerged from the interaction of a very simple set of modules designed for Amazon to use internally.

The concept was heavily inspired by the 2003 book “Creation,” written by game designer Steve Grand. Grand’s design approach had centered around building simple creatures, then sitting back and “watching surprising behaviors emerge.” For Amazon CEO Jeff Bezos, this idea proved perfectly applicable to computing.

On the influence of “Creation” across Amazon’s leadership, Brad Stone writes,

“If Amazon wanted to stimulate creativity among its developers, it shouldn’t try to guess what kind of services they might want; such guesses would be based on patterns of the past. Instead, it should be creating primitives — the building blocks of computing — and then getting out of the way. In other words, it needed to break its infrastructure down into the smallest, simplest atomic components and allow developers to freely access them with as much flexibility as possible.”

Today, Amazon Web Services drives most of Amazon’s operating profit and about 15% of its overall revenue.

FEATURE BLOAT: WHAT HAPPENS WHEN COMPANIES FLOUT GALL’S LAW

Tech history is full of products that failed because they went the opposite way of Twitter and Amazon: they built over-engineered products, bloated with features, that lacked enough simple utility for users.

One of the classic examples of feature bloat bringing a product down is ICQ, the once-popular instant messaging client. In a 2007 blog post, Robert Scoble attributed the service’s sudden decline mainly to over-engineering: “It got too cluttered and stopped being developed.”

At one point, ICQ had been the king of instant messaging. In 1998, AOL bought the company behind ICQ for $287M upfront and $120M in performance-related payments. The service had more than 100M accounts registered around the time it peaked in 2001.

For Scoble, that’s where the decline, and the clutter, started. ICQ started branching out from its core utility by adding features around shopping, music, games, and even careers, resulting in a busy interface that felt removed from the purpose of the product.

At the same time, new products like Facebook were emerging that allowed people to more organically connect with their friends outside the constraints of a messenger.

“Feature bloat is how most consumer web and desktop products suffocate themselves,” Dropbox co-founder and CEO Drew Houston has said. “ICQ became so comically bloated that they released an ‘ICQ Lite’ version, but by then they were already on the decline.”

Releasing a “lite” version of a product might make sense if you’re differentiating it from a “premium” version that serves an audience with more complex needs, but ICQ and ICQ Lite were the same basic product for the same basic target user.

The release of a “lite” version, in this case, could be seen as a way to actually offer a superior product — an attempt to cut the feature bloat that had crept in over the years.

TAKEAWAY

Today, with free trials, SaaS, and subscription business models in vogue, it’s more sensible than ever to produce a minimum viable product (MVP) and iterate on it based on user feedback.

While companies should avoid feature bloat, aiming for a gradual evolution from simple functionality is a way to build a growing product that actually reflects users’ needs.

And according to Gall’s Law, products that start small — as simple, effective systems — stand the best chance of becoming powerful businesses built on high-functioning, complex systems.

source: CBinsights