LearningAPI has moved to a new blog!

The learningapi blog has moved to a new URL. These posts will remain here, but all new content has moved to learningAPI.com: Digital Media, Streaming Video & Educational Technology. You may also subscrdibe to the RSS feed for the new learningAPI.com blog.

November 10, 2005

Amazon.com's Two-Pizza Team Rule

"If a project team can eat more than two pizzas, it's too large."  This week's Baseline Magazine profiles Amazon.com CTO Verner Vogels and his approach to running Amazon's software development operation.  

Vogels breaks big problems into smaller ones, then assigns tightly focused teams to nail one small problem at a time. As I pointed out in my own Gilbane Conference Keynote presentation  earlier this year, sometimes you really do have a large problem that needs a large team with an expansive view to solve it.  Most often, though, we complicate matters by tackling too big a chunk at once.  

Small teams and tight meetings [are] targeted to solve one or two problems, with challenges cut down to bite-size chunks. Where other retailers might ponder how to improve customer checkout, Amazon shaves layers off the concept and assigns them. One team might work on streamlining gift certificate redemption, another on credit card authorization. All projects take this approach at Amazon.

Vogels upholds the Amazonian principle of "two-pizza teams." That is, technology teams working on a given project typically can be fed by no more than two pizzas—usually eight or fewer people. Small teams are fast, he says, and don't get bogged down in so-called administrivia. 

Each group assigned to a particular business is completely responsible for it. Team members aren't considered database administrators or Java programmers or some other techie title. They're the people responsible for the customer checkout procedure or credit card verification process or search function.

The team scopes the fix, designs it, builds it, implements it and monitors its ongoing use. This way, technology programmers and architects get direct feedback from the business people who use their code or applications--in regular meetings and informal conversations.

There are two parts to this that I think are key.  They are a bit self-evident, but worthy of repeating.
  1. Small problems are easier to grasp, examine, and solve than big ones.  Small solutions are easier to explain, understand, test, and implement .
  2. Small teams need less process, have few communications challenges, and lower overhead than larger ones.  Small teams can get real work done while large ones are still trying to find common understanding about the problem.  
I'm not saying that no one should do large projects -- sometimes you simply must.  But take care to understand the difference between when you must, and when you really don't have to.
Posted by larryb at 05:56 AM [permanent link]
Category: Web and Software Development
TrackBack URL for this entry:

Listed below are links to weblogs that reference 'Amazon.com's Two-Pizza Team Rule' from learningAPI.com: Media and Learning Technology - Larry Bouthillier.