Thursday, October 24, 2013

"Unintended Consequences!" - Peter

Excerpts from "The Everything Store: Jeff Bezos and the age of Amazon" by Brad Stone

Chapter 6 - Chaos Theory

The drive to cut costs also forced Bezos to eliminate any emerging layers of middle management from his company. After the stock market crash in 2000, Amazon went through two rounds of layoffs. But Bezos didn’t want to stop recruiting altogether; he just wanted to be more efficient. So he framed the kind of employees he wanted in simple terms. All new hires had to directly improve the outcome of the company. He wanted doers—engineers, developers, perhaps merchandise buyers, but not managers. “We didn’t want to be a monolithic army of program managers, à la Microsoft. We wanted independent teams to be entrepreneurial,” says Neil Roseman. Or, as Roseman also put it: “Autonomous working units are good. Things to manage working units are bad.”

But as was often the case, no one could anticipate just how far Bezos would venture into these organizational theories in his quest to distill them down to their core ideas. In early 2002, as part of a new personal ritual, he took time after the holidays to think and read. (In this respect, Microsoft’s Bill Gates, who also took such annual think weeks, served as a positive example.) Returning to the company after a few weeks, Bezos presented his next big idea to the S Team in the basement of his Medina, Washington, home.

The entire company, he said, would restructure itself around what he called “two-pizza teams.” Employees would be organized into autonomous groups of fewer than ten people—small enough that, when working late, the team members could be fed with two pizza pies. These teams would be independently set loose on Amazon’s biggest problems. They would likely compete with one another for resources and sometimes duplicate their efforts, replicating the Darwinian realities of surviving in nature. Freed from the constraints of intracompany communication, Bezos hoped, these loosely coupled teams could move faster and get features to customers quicker.

There were some head-scratching aspects to Bezos’s two-pizza-team concept. Each group was required to propose its own “fitness function”—a linear equation that it could use to measure its own impact without ambiguity. For example, a two-pizza team in charge of sending advertising e-mails to customers might choose for its fitness function the rate at which these messages were opened multiplied by the average order size those e-mails generated. A group writing software code for the fulfillment centers might home in on decreasing the cost of shipping each type of product and reducing the time that elapsed between a customer’s making a purchase and the item leaving the FC in a truck. Bezos wanted to personally approve each equation and track the results over time. It would be his way of guiding a team’s evolution.

Bezos was applying a kind of chaos theory to management, acknowledging the complexity of his organization by breaking it down to its most basic parts in the hopes that surprising results might emerge. That, at least, was the high-minded goal; the end result was somewhat disappointing. The two-pizza-team concept took root first in engineering, where it was backed by Rick Dalzell, and over the course of several years, it was somewhat inconsistently applied through the rest of the company. There was just no reason to organize some departments, such as legal and finance, in this way.

The idea of fitness functions in particular appeared to clash with some fundamental aspects of human nature—it’s uncomfortable to have to set the framework for your own evaluation when you might be judged harshly by the end result. Asking groups to define their own fitness functions was a little like asking a condemned man to decide how he’d like to be executed. Teams ended up spending too much time worrying over their formulas and making them ever more complex and abstract. “Being a two-pizza team was not exactly liberating,” says Kim Rachmeler. “It was actually kind of a pain in the ass. It did not help you get your job done and consequently the vast majority of engineers and teams flipped the bit on it.”

No comments:

Post a Comment