2.

THE LAW OF THE SMALL TEAM

The fundamental task is to achieve smallness within large organizations.

—E. F. SCHUMACHER¹

Picture this. It’s 1997 and you’ve just had a great idea: a slim handheld device that’s small enough to slip into your pocket and that can perform multiple functions at the touch of a fingertip. It will serve as a portable telephone, an address book, a map, a navigation system, an airline boarding pass, a music or movie player, a television set, a camera, a flashlight, a dictation machine, a stopwatch, an alarm clock, a translation machine, a remote control, a repository of the world’s newspapers and magazines, a library of thousands of books, and more. Moreover, the device will be lightning-quick in its responsiveness and it will be customizable to meet the individual needs and preferences of hundreds of millions of people around the world.

Sound good? You know it’s a winner. But how to bring it to reality? Well, it’s 1997 and so you apply the best management practices of the day. First, you spend a couple of years winning support for the idea’s feasibility and persuading the strategy committee of a major corporation to design, build, and market this amazing new device. After finally getting this approval, you pull together a huge team of designers and engineers and spend another couple of years developing detailed specifications for the device with a timeline to deliver and integrate its various components. You then recruit hundreds of thousands of engineers and developers to build the device. You also hire tens of thousands of managers to supervise and control them to ensure that they deliver according to the plan and on schedule. You set up comprehensive reporting systems so that top management knows exactly how every dollar has been spent and what progress is being made on each component, thereby eliminating risk. You put in place a system of coordination committees to ensure that all the many units will be working together on the device like a finely tuned symphony orchestra.

The result? Many years and billions of dollars later, you find that your device is still far from being ready for the marketplace. The technical problems are unending and seemingly exponential. Coordination between units is a massive headache, despite vast amounts of time and effort by the coordination committees. There is acrimonious finger-pointing about who is responsible for the technical problems and the delays. While many individual components appear promising, they are often incompatible with each other. Each unit blames the other, but in the end, no one can be found accountable and fixing the problems takes forever. Even when solutions to known problems are produced, they generate fresh problems. Worse, you suspect that there’s a massive backlog of unknown technical problems waiting to explode at any moment. And your device is still years away from being ready for the marketplace.

In organizing the work this way, you had hoped to achieve economies of scale. But you see now that you have achieved the opposite: dis-economies of scale. The cost associated with organizing and coordinating so many people and units is growing more quickly than any additional value that those people are likely to create. And whether they will ever complete the work is still a question mark.²

Sadly, after years of effort and billions of dollars spent, management decides that your project must be canceled. That’s because a real-life competitor—Apple—had by 2007 developed a similar product, having brought it “from scratch to market” in just eighteen months at a fraction of the cost of traditional management practices.

How was that possible? Instead of building a very complex device with a very complex organization according to elaborate specifications, Apple did the opposite. It designed and built a relatively simple physical device—the iPhone—that was developed in an iterative fashion in short cycles and steadily upgraded. Instead of recruiting hundreds of thousands of its own engineers to build a monolithic software operating system to perform the device’s functions, Apple set up a technology platform and invited hundreds of thousands of independent teams of developers to imagine and create their own purpose-built applications (“apps”) to meet every conceivable human need and to offer them directly to Apple’s customers. Together, the apps can perform an almost infinite array of functions. They are added as they are developed while interacting directly with customers. The customers themselves decide which apps are valuable for their own specific needs and configure the device according to their own idiosyncratic preferences. The result is a multifunctional device that is customized to meet the needs and passing whims of hundreds of millions of individual users—a feat inconceivable with traditional management methods. Instead of scaling up the organization to resolve a complex problem, Apple scaled down the problem into tiny bite-size pieces that small independent teams could deliver in an iterative fashion with direct feedback from customers.

The success of Apple’s iPhone is often attributed to the genius of Steve Jobs. Brilliant marketing. Superior design. Meticulous attention to detail. Breakthrough thinking. Ferocious drive to solve problems. All of this is true. But what is often overlooked is that these elements would have gone for naught if Apple had not developed a relatively simple hardware device in an iterative fashion and offered a platform to mobilize independent software developers: hundreds of thousands of small teams of developers contributing their ingenuity and talents to build apps in an iterative fashion while interacting directly with customers.

The Law of the Small Team is simple. It’s a presumption that in a VUCA world, big and difficult problems should—to the extent possible—be disaggregated into small batches and performed by small cross-functional autonomous teams working iteratively in short cycles in a state of flow, with fast feedback from customers and end-users. Instead of constructing a big and complex organization to handle complexity, the organization disaggregates the problem into tiny pieces so that it can be put together in minuscule increments and adjusted in the light of new and rapidly changing information about both the technology and the customer.

The lessons of the Law of the Small Team are still being learned. The failed effort to produce a portable device by traditional management practices (as described in the opening story) is imaginary, although some aspects are eerily reminiscent of the history of the Newton—a personal digital assistant that Apple’s then CEO, John Sculley, oversaw development of in 1987 until it was abandoned by Steve Jobs in 1998.³

The real-world disasters that flow from trying to manage complexity within a top-down bureaucracy are very real. For instance, in 2006, the U.S. Air Force launched a project aimed at modernizing the management of logistics. It awarded a $628 million contract to Computer Sciences Corporation to serve as the system integrator; its job was to configure, deploy, and conduct training and change management activities before the launch.⁴

“We’ve never tried to change all the processes, tools and languages of all 250,000 people in our business at once,” said Grover Dunn, the Air Force director of transformation, “and that’s essentially what we’re about to do.”⁵ As Elizabeth McGrath, the Defense Department’s deputy chief management officer, explains, “We started with a Big Bang approach and put every possible requirement into the program, which made it very large and very complex.”⁶

Over the next seven years, the project was restructured several times. Finally, in 2013, the Air Force realized that it would cost another $1 billion to achieve one-quarter of the capabilities originally planned. Even then the system would not be ready for another seven years. So, the Air Force gave up on the project entirely. It canceled the project after spending some $1.3 billion.

You might say that the approach of disaggregating work into tiny pieces might make sense for a personal entertainment device like the iPhone. But could it ever really work for a serious industrial project where reliability is required—such as, say, a stealth fighter jet? The answer is that it already has. The Swedish aircraft maker Saab has done exactly that. Saab’s Gripen fighter jet was developed and built using Agile practices.⁷ Every six months Saab issues a new release of the jet’s operating system that makes it faster, cheaper, lighter, more efficient, more powerful, with better electronics and more sophisticated targeting. Serious defense experts have called it “the best stealth fighter in the world.”⁸

A study conducted by the respected international defense publishing group IHS Jane’s compared the operating costs of Saab’s Gripen fighter aircraft with Lockheed Martin’s F-16 and F-35 aircraft, Boeing’s F/A-18 Super Hornet, Dassault’s Rafale, and Eurofighter’s Typhoon. It concluded that the Gripen had “the lowest operational cost of all these aircraft in terms of fuel used, pre-flight preparation and repair, and scheduled airfield-level maintenance together with associated personnel costs.”⁹

Software plays a steadily increasing role in the design and evolution of the Gripen: “The conundrum facing fighter planners,” writes Bill Sweetman in Aviation Week and Space Technology, “is that, however smart your engineering, these aircraft are expensive to design and build, and have a cradle-to-grave product life that is far beyond either the political or technological horizon.” Saab’s Gripen has been designed with these issues in mind. “Long life requires adaptability, both across missions and through-life.”¹⁰

The same phenomenon is emerging in the world of automobiles. For the first century of the history of cars, when you bought a car, you were stuck with what you bought. If you wanted something better, like more features or more power, you had to buy a new car. Now that’s changing. Tesla, for instance, can add new capabilities into cars it has already sold by downloading new software for the car. The new features include automatic braking when the vehicle senses a pending collision, a partial autopilot system, and a robotic parking program. These features aren’t unique to Tesla’s cars—they are found on other luxury cars like the Audi or Mercedes-Benz. What’s different is that the Tesla Model S is designed to be continuously upgraded on the fly. Tesla can remotely add substantial functions to cars already on the road.

“We really designed the Model S to be a very sophisticated computer on wheels,” says CEO Elon Musk. “Tesla is a software company as much as it is a hardware company. A huge part of what Tesla is, is a Silicon Valley software company. We view this the same as updating your phone or your laptop.”¹¹

Cars are thus more and more resembling flexible electronic devices than mechanical machines. Like the iPhone, the car is becoming a platform for apps that steadily improve the vehicle’s functions rather than embodying static performance defined by mechanical features installed at the time of purchase.

In understanding the scope of Agile, it’s useful to remember that Agile management became associated with software only after 2001, and that its historical roots lie in manufacturing with the quality movement in Japan and the Toyota Production System. Toyota began by disaggregating the manufacturing process itself. It experimented with small production runs. Contrary to what common sense might indicate, Toyota discovered that once rapid changeovers were accomplished, small demand-driven iterations generally turned out to be more efficient than mass-production runs.¹²

This model of manufacturing spread throughout Japan in the 1970s and came to the United States in the 1980s. It was discovered that when these iterative techniques were executed well, with small batch sizes, cycle times could drop by factors of 10 to 100. Inventories could be reduced by more than 90 percent, freeing enormous amounts of cash. Secondary effects include improved quality, accelerated learning, and lower production costs.

Iterative thinking was then applied to the process of developing new products, as described in the seminal 1986 article in Harvard Business Review by Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game.” The authors wrote:

Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multi-learning,” subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast, flexible process for new product development. Just as important, the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.¹³

The examples given in the article—Fuji-Xerox, Honda, and Canon— are all hardware, not software.

In 1990, the iterative small-team approach was further disseminated as “lean manufacturing” in the classic book The Machine That Changed the World.¹⁴ But while the systematic use of small teams and iterative approaches began in hardware, it really took off in software development after the publication of the Agile Manifesto in 2001.

What exactly are the practices that make up the Law of the Small Team? One answer is that “it depends.” For the first decade after the Agile Manifesto, there were many furious arguments among Agile practitioners as to what are the “true Agile practices.” Some urged Scrum. Others were adamant that kanban was the answer. Still others were convinced that the answer lay in lean manufacturing. Eventually it became clear that the answer to the question was something different altogether. The Law of the Small Team concerns a mindset, not a specific set of tools and processes that can be written down in an operational manual. If you are thinking about Agile as a set of tools and processes, you’re looking for the wrong thing. You can’t go to the store and “buy some Agile management.”

The Law of the Small Team is a presumption about how complex work in principle should be done. In any particular organization, the practices that emerge will be the result of an interaction between the Agile mindset and the specific organizational context. That’s one reason why hiring a firm of consultants to “come in and train our staff on Agile management tools and processes” rarely by itself produces a happy result.

Over the last couple of years, the SD Learning Consortium has organized a series of mutual site visits among its members to learn what is involved in successfully implementing Agile management.¹⁵ The object is for the firms to find out from each other what Agile implementation looks like in real life. The result? In each successful case, we found that the firm started from some general principles and prior examples and then organically grew a set of practices to meet its own specific needs and culture, sometimes with its own idiosyncratic labels. Although there is no “one size fits all” and no universal “best practice,” we did see convergence toward management practices that have a striking family resemblance. The main characteristics are listed in Figure 2-1.

This way of working emerged out of practical experience and extensive experimentation. Is it more productive? Google thinks so. At Google, “the company’s top executives long believed that building the best teams meant combining the best people,” said Abeer Dubey, a manager in Google’s People Analytics division. But when they studied it, it turned out not to be the case. A comprehensive study of what characteristics led to a high-performance team showed that there was practically no correlation with the types of individuals on the team. The study, which became known as the Aristotle project, showed that the composition of the team had much less to do with team performance than five key dynamics that are supported by Agile management practices.¹⁶

1. Psychological safety. Can we take risks on this team without feeling insecure or embarrassed?

2. Dependability. Can we count on each other to do high-quality work on time?

3. Structure and clarity. Are goals, roles, and execution plans on our team clear?

4. Meaning of work. Are we working on something that is personally important for each of us?

5. Impact of work. Do we fundamentally believe that the work we’re doing matters?

The result of organizing work in an Agile manner is not only that work gets done faster, but that those doing the work tend to be engaged in what they are doing. Unlike the traditional workplace where only one in five employees is fully engaged in his or her work, in an Agile management workplace, employees are in a psychological state of “flow,” as identified by Mihály Csíkszentmihályi—that is, those doing the work are fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. When those doing the work can see the meaning of what they do for those for whom they are doing it, they “bring their brain to work.”

This phenomenon accounts for the high motivation that we observed in teams encountered during the site visits. When we asked staff members in these organizations whether they would ever willingly work in a firm using traditional management practices, the universal answer was “never.”

Although there are strong family resemblances among the practices, each firm has developed its own unique combination of practices. An interesting mix occurs at Menlo Innovations, a software design and development firm in Ann Arbor, Michigan, and the brainchild of its hugely enthusiastic CEO, Richard Sheridan, and cofounder James Goebel. Menlo delivers custom software applications, mostly for business-to-business purposes and often in mission-critical fields such as medical and health care. What’s nice is that Menlo welcomes visitors. You can go and visit the firm in Ann Arbor and observe this workplace of the future.

Sheridan talks more about joy in the workplace than about Agile. So, when visitors to Menlo come to learn about Agile and lean, why does he talk about joy? “It’s simple,” says Sheridan. “What we have tried to do at Menlo is to emancipate the heart of the engineer, which is to serve others. We engineers exist to produce something that the world will enjoy, something that will delight people. All of these things that we call Agile or lean, or any of the other processes that have a name, that’s what they are really about when they are done well: How do we serve others?

“In doing so, we borrowed from a lot of concepts,” Sheridan says. “That’s why you won’t catch us using the word ‘Agile’ very often. People visit us and say, ‘You look very Agile to us. Why not call it Agile?’ We are not doing these things because we want to be Agile. We’re doing them because we want to produce joy in the world with our work.”

It all began some twenty years ago when Sheridan was exasperated with the bad organizational practices he had experienced as a manager in software development. In his own firm, he set out with the explicit goal of ending the human suffering involved in software development.¹⁷

Before he set up Menlo Innovations, almost the only thing he did was to resolve software crises when systems broke down or experienced major outages. Traditional management processes were creating fires and Sheridan had to put them out. He felt like a chief firefighter. The stress level was terrible. So, he set out to create a firm that didn’t do that to its people—a firm that wouldn’t experience constant emergencies with high levels of angst. He wanted people to be proud of what they were doing and how they were doing it. He wanted software to be produced by people who experienced joy in what they did, not stress.

The word “joy” is not one normally associated with the twentieth-century workplace. Good workplaces were perhaps “effective” or “efficient” or even “engaged.” But joyful? Even thinking about the possibility initially sounded ridiculous.

Yet for some fifteen years, Menlo Innovations has been doing exactly that—maintaining a workplace that generates joy both for those doing the work (software developers), for those for whom the work is being done (clients), and for those who will one day use the results of the labor (the end-users). “We don’t believe for a second,” says Sheridan, “that we can serve others well unless we are taking care of our team. So, we created a system that is focused first and foremost on servicing others and producing great results for the world. But in order to do that, we had to recraft the way software is designed and developed.”

Sheridan’s goal of producing a joyful workplace means generating ultra-reliable code that never breaks and never needs fixing. This in turn reflects the sector in which Menlo operates—medical devices that must be fail-safe. “The last time we had a software emergency was in 2004,” says Sheridan. “It’s different with some of our clients. We just started work with a new client and in the very first week, the internal team launched a big new project that had been under development for years and it was a disaster. People were working nights and weekends, trying to recover. It affected their business in big ways and slowed sales of their products in the marketplace.”

By contrast, Menlo operates as an emergency-free environment. When Menlo’s staff saw what was happening with this client, they said, “Oh, so that’s what an emergency looks like!” They had never seen one. They had never experienced it. They didn’t know what it was.

“What we are doing,” says Sheridan, “is creating freedom through tyranny. It’s true that we have created a joyful place and people love working here and they are fully engaged. And yet it’s also true that we have introduced tyranny by removing ambiguity from the workplace. In our world, people know who they are working with and who they are working for. They know what they are working on, and they know what order they are going to work on it. That’s the tyranny part. Once that’s established, the freedom part kicks in. I say, ‘You are now free to pursue the work that you love without anyone hanging over your shoulder, cutting in, and asking what you are working on and how it’s going.’

“We have a process,” says Sheridan, “that the team believes in. And because they believe in the process, we don’t need process police going around checking whether they are staying on task and doing their jobs. The process they know actually protects them. The process is clear both to them and to our customers. Teamwork is not optional. Collaboration is not optional. We say that we are giving our teams ‘permission to collaborate.’ By forcing the idea of working in small teams, we are creating the freedom to collaborate.”

How does Menlo produce “emergency-free software”? One striking feature is how Menlo approaches the issue of team continuity. Most firms practicing Agile management, such as Microsoft and Ericsson, put effort into keeping the members of the teams together, with the same people working on the same team as long as possible. The idea is that such teams become like a champion sports team in which everyone knows each other’s skills and idiosyncrasies. Moreover, the ones who create the code are the ones who understand it and who are best placed to maintain it. Giving them responsibility for fixing their own quality problems (“bugs”) also gives them an incentive to get it right the first time. These firms almost see the team itself as the product.

“That works fine,” says Sheridan with a smile, “as long as the team is immortal and people never take vacations! We do the opposite because we know that if software is dependent on the individual members of a team, we have to ask: What happens if that team [member] is not available? If there are four people working on a project in a traditional setting, each of them will be a tower of exclusive knowledge and expertise in their own area. As a result, you can’t operate in the absence of one of the experts without the entire team crashing. You have to have the database guy. You can’t lose the secret sauce guy. You can’t move without the middleware guy. That’s because they are the only ones who know their own piece of the code. In effect, the knowledge about that piece of software is trapped inside the team. We need teams and software that are not dependent on individuals.”

At Menlo, the work cycles are very short—only one week—and the membership of teams is deliberately changed each week. “Because of our switching of team members, each team is touching code that someone else wrote the previous week. Effectively, we are testing right then and there whether the code is reliable and maintainable. The new team needs to understand the code in order to make changes effectively. If they don’t understand the code, they can go and find the pair that wrote the code. They might be sitting just a few feet away. In the process, the first team also gets to understand the code that they created and discover what they thought was clear wasn’t clear after all.

“The result,” says Sheridan, “is really clear, reliable, maintainable code. That’s our goal. When we work this way over and over again every single week, we end up with a rock-solid body of code that is clear and maintainable by lots of people. That enables us to expand and extend the code. It gives us code that is emergency-free.”

A second unusual feature at Menlo is the approach to staffing. Many firms approach staffing by trying to find exactly the right person with exactly the skills they need, such as Python 4.6 or Oracle 9.1.1.1 or whatever. To solve this problem, they try to match the skills needed for a particular task with a person who possesses those precise skills.

Menlo does the opposite. It seeks to create a culture of collaboration, adaptability, transparency, and trust. “It starts with our hiring practices,” says Sheridan. “Unless our people fit the culture, we won’t have a chance of maintaining our culture over time. When we need new staff, we bring people in and get them to ‘speed date’ with our own staff. The question is always: Would you like to work with this person? If the answer is yes, then we bring them in to work with us for a day, then a week, and then a month. If the answer is still ‘Yes, I would like to work with this person,’ then they are hired.”

Says Sheridan, “We developed this interview process to match our culture. In the beginning, we don’t ask many questions. We don’t pay too much attention to résumés. We are more interested in culture fit. We don’t start with how smart you are. We don’t care what you’ve learned. We aren’t interested in where you’ve gone to college. None of that matters if you don’t fit our culture. Once we’ve determined that there is a fit with our culture, then we start to ask about skills. But frankly, with the right culture, acquiring skills is not all that difficult in comparison to having the right attitude and mindset.”

A third striking feature at Menlo is the use of pairing: All work is done in pairs. To traditional managers, having two people working on the same computer and doing the work of one is unproductive and inefficient, almost by definition. Managers think pairing must be cutting productivity in half. Sheridan says it’s the opposite. Menlo does all its work in pairs precisely because it’s so productive. Performance measures show that it is up to ten times more productive than working as individuals.

Earlier in his career, Sheridan would have bosses who, when they saw two people working together, would assume that at least one of them wasn’t working at that moment, and probably both of them. They would inject themselves into the conversation and make those people “go back to work.” Menlo is the opposite of that. “It’s only if we see someone alone,” says Sheridan, “that we are likely to ask: ‘Why aren’t you working?’”

Menlo is practicing code stewardship of maintainable code, rather than code ownership that is hard to maintain. Menlo isn’t the only firm practicing pairing. But it’s still rare.

A fourth striking feature of Menlo is the central role played by the anthropologists. “Sadly, in software we have created an industry,” says Sheridan, “which produces technology that doesn’t fit people’s needs and then treats them as ‘stupid users.’ We write guides for people showing them how to use software that doesn’t meet their needs very well. In Menlo, we take exactly the opposite approach. We want to create software that doesn’t require user manuals or help desks. We aim to delight the people who are going to use the software that we are developing. The way we do this is by learning a great deal about the people we serve—those people who are going to touch the software we create. We call this practice ‘high-tech anthropology.’

“Our anthropologists,” says Sheridan, “using empathy and compassion and the tools of the anthropologists, go out into the world. They go to where the work is done and not only understand the people and the environment, but also the vocabulary, the workflow, the habits, the fears, and the dreams of those human beings, and [they] design a software experience accordingly.”

These four atypical practices at Menlo—recruiting, pairing, changing team membership, and using anthropologists—are not being presented here as “better” than the practices at other organizations or something that every firm should emulate. They happen to fit Menlo’s context and culture. They may or may not fit other organizations. They are options that other organizations may—or may not—adopt. One size does not fit all.

The Law of the Small Team involves working in short cycles. Microsoft and Ericsson have adopted three-week cycles. Menlo works in one-week cycles. How short can a cycle be? When I heard about Etsy, the rapidly growing billion-dollar online market for handicraft products that deploys more than thirty innovations each day, my immediate reaction was that this must be a hellishly stressful place to work. I was therefore surprised to learn that it is the opposite. Continuous deployment was introduced not only to accelerate innovation but also to overcome excessive stress in the workplace. It has done both.

Seven years ago, Etsy was issuing code changes every two to three weeks, which was already quite rapid compared to what other firms were doing at the time, such as Salesforce’s three releases per year or the Microsoft Office upgrades that used to be issued every couple of years. Like many firms, Etsy had separate groups for the development and the deployment of software. The developers created new software and operators would deploy the bundle of changes that the developers had put together. The work environment was characterized by long days and late nights, particularly when something went wrong, which was happening all the time. There were frequent and prolonged outages. Some of this resulted from the fact that software was being written by one group of people and then introduced and operated by a different group.

In 2010, the management at Etsy set out to fix this. It was committed to “innovate or die” and wanted to resolve the hurdles of improving and scaling a website that had become huge, with more than 60 million unique visitors per month. Etsy managers saw that quality involved not only releasing high-quality code, but also improving adaptability and response time when there were problems. They also wanted to have a healthy engineering team working at a sustainable pace. Like many Agile firms, they were committed to Dan Pink’s principles of “autonomy, mastery and purpose.”¹⁸ Above all, they wanted to reduce the stress levels that were associated with releases of upgrades.

They had put in place continuous integration and automated testing that, in theory, ensured that the effects of any change in the code could be ascertained in a staging area that was an exact replica of the operating site. But in practice, unexpected things kept happening in deployment. Users sometimes did unexpected things, like launching a flash sale that inundated the site with a huge number of users at one instant. Or there could be some unexpected interaction between the actual hardware and the software. Or sometimes in a bundle of many changes it was difficult to figure out exactly what was the cause of the problem.

Etsy decided to go really small. They found—to their surprise—that by having more frequent releases of small changes, it was easier to spot and fix problems. To make the shift happen, basic changes in the implementation and the management approval process were needed. Instead of management approval being required for all changes to the actual site, now all improvements that had been tested were deployed immediately. The staff devising the improvement also oversaw implementation.

Management has articulated a clear vision for the firm and the staff are committed to it, making Etsy a “cool” online market for handmade and vintage items, just as Spotify offers “cool” music streaming. At firms like Etsy and Spotify, purpose isn’t a problem. Within the broad strategic framework, the staff are authorized to proceed with continuous improvement. Many of the changes are “dark” changes that users never see, but which improve the performance of the site. There is continuous testing, and if an improvement doesn’t make things better for customers, it is immediately removed.

Some changes are experiments aimed at finding out whether something would work better. For instance, would it make sense to include the shipping price in the price of the goods and then offer “free shipping”? The answer to this apparently promising idea in one experiment turned out to be no.

The result is a workplace that is very different from what it was seven years ago. Along with the marked acceleration in innovation, the work is much less stressful. Instead of a separate “deployment army” to cope with bundled changes, now the same staff who are devising the improvement oversee the release, which improves mastery and autonomy. The long days and late nights of the developers at Etsy are largely gone. Also largely gone are prolonged outages. Yes, there’s still stress when something goes wrong, but it is much less frequent and much easier to fix. The engineering team now has normal work hours, with evenings and weekends off.

With an average of thirty changes to the website deployed each day, we are looking at extremely rapid innovation. Each of the changes is small, but a small change can be significant, sometimes adding millions of dollars in sales. Doing all this change in tiny increments at warp speed within the framework of a central strategy enables extremely rapid innovation and learning, as well as much greater facility in spotting and fixing any problems that may emerge.

Obviously, this process can only work in an environment with a work culture of trust and collaboration. Is it possible to establish stress-free innovation at warp speed? The experience at Etsy suggests that the answer is yes.

Is it sustainable? In 2015, Etsy went public. Time will tell whether this move has put the organizational culture at risk. Already there are worrying signs of pressure from investors to maximize shareholder value. If Etsy succumbs to those pressures, it may join firms pursuing short-term financial gains at the expense of sustainability. Like Spotify fighting Apple Music, Etsy’s only chance of survival is to innovate faster than its competitors and delight its customers to such an extent that Etsy is the must-have experience for steadily more customers.

When confronted with Agile teams, traditional managers often scoff. “Teams? Nothing new there. We’ve always had teams. This is not even remotely a new idea.”

In one sense, they are right. As noted in Chapter 1, teams have been talked about in management for almost a century. Yet many of the teams were teams in name only. When the team leader acted like any other boss in a bureaucracy, it was hardly a surprise that few teams achieved consistently high performance.

Teams were generally used for solving specific problems, such as R&D or special projects, but not for day-to-day management. The thinking was that you could have disciplined execution through bureaucracy, or innovation with teams, but not both. You had to choose. (See Figure 2-2.)

The result of the innovations made by Agile management is that there is no longer a choice to be made between disciplined execution and innovation through teams. The new way of operating enables the firm to do both at the same time. Now teams can be deployed to handle almost all work. (See Figure 2-3.)

The twentieth-century humanist managers promoting teams meant well. These psychologists, sociologists, and management consultants had analyzed what people needed and how they should work in groups. Surely employees who saw work as meaningful and felt fulfilled in a workplace with a friendly atmosphere would be more productive. Surely managers who were perceived as kind and caring, and who could inspire and coach employees, would do better than bosses who were mean and surly.

Figure 2-2. Traditional management had to choose disciplined execution vs. innovation.

Figure 2-3. Agile management achieves both disciplined execution and innovation.

The language of teams became pervasive, even if the practices of high-performance teams didn’t. There was talk of “team spirit,” “winning,” self-actualization,” “excellence,” “commitment to a goal,” “the desire for perfection,” and so on.

But often the language of teams was a desolate echo of the real thing. It consisted of empty clichés, a rah-rah world of fake conviviality. The actual implementation was thus a drab caricature of the romantic language in which these schemes were couched. The language embodied a fairy tale about the enchanted corporation.¹⁹

By contrast, the founders of Agile management chose terms that were deliberately mundane and even ugly: “Scrum,” “Scrum Masters,” “product owners,” “kanban,” “burndown charts,” “working software,” “sprints,” “standups,” and getting work not just “done” but “done, done, done.” There was no hint here of magic or enchantment, no highfalutin language about self-actualization and no fake camaraderie. Instead there was a rigorous focus on solving problems and enabling people to get on with work without interruption, drawing on real expertise, removing impediments, and continuously delivering value to customers in the face of mind-boggling complexity.²⁰

The result is that Agile teams operated very differently from the team initiatives of the twentieth century.

Whereas the language of the twentieth-century team initiatives was romantic, the language of Agile teams is down-to-earth and pragmatic.

Whereas the twentieth-century team initiatives tended to assume linear problems that could be definitively solved, Agile teams accept unfathomable complexity and the nonlinearity of a continually morphing environment as the basic nature of the game.

Whereas the twentieth-century teams had difficulty coping with large-scale problems, the use of platforms and networks has enabled Agile management to achieve almost infinitely large scale without sclerosis.

These considerations help us see why the Law of the Small Team is more than a change in terminology. By adopting the small team as the default method for getting almost anything done, Agile management changed the game fundamentally.

In retrospect, we can see why the problem that the humanist theorists were trying to solve—a zero-sum power struggle between bosses and workers—was insoluble. It was a battle that bosses would inevitably win, although the victory would turn to dust in their hands, since the workers became dispirited.

The voice of the customer was often lost in the struggles up and down the hierarchy, between the competing organizational silos and between differing managerial agendas. What was needed was to change the game from a zero-sum vertical dynamic of conflict into a win-win horizontal dynamic of delivering value to the customer through collaboration and joint problem solving. Whereas the twentieth-century team initiatives were often internally focused, what was needed was a shift to an external focus by providing value continuously for the customer. How is this accomplished in practice? It is to this set of issues that we now turn.