Pods – also known as self-directed work teams – have been around for more than 20 years. Pods are 30% to 50% more effective than their traditional counterparts. A survey of senior line managers offers some of the benefits derived from implementing self-directed teams:
- Improved quality, productivity and service.
Reduced operating costs.
Faster response to technological change.
Fewer, simpler job classifications.
Better response to workers’ values.
Increased employee commitment to the organization.
Ability to attract and retain the best people.
So if it’s such a great idea to go podular, why aren’t more companies doing it?
Podular design is a concept that focuses on modularizing work: making units more independent, adaptive, linkable, and swappable. But the environment that surrounds the pods is equally critical to the success or failure of a podular system. Modular components are a critical element of a connected company. But to take advantage of pods you also need a business that is designed to support them.
Architectural vs component innovation
Most innovation involves small, incremental improvements to the parts of a system. A better spark plug, a better kind of tire, a better bar of soap, and so on. This is because these kinds of innovations are easier to inject into an existing system.
But some kinds of innovations – often called disruptive innovations – involve changes to the system itself. The PC revolution is an example of disruptive innovation, because the entire system of work computing had to change to accommodate it. This required a whole host of component innovations beyond the PC itself, such as the office scanner, printer, networking, and so on. System innovation like this requires changes to the fundamental architecture – known as architectural innovation.
Component innovation swaps out one node for another, which usually results in an incremental improvement. Architectural innovation changes the links. Changing the relationships between nodes is a sweeping change that usually transforms the way that the entire system works. Apple’s iTunes/iPhone ecosystem was an architectural innovation that changed the music industry forever.
Perhaps one of the reasons more companies haven’t organized around small, empowered teams is that their business architectures don’t allow it. It’s not easy to plug modules into a platform that isn’t designed for it.
What kinds of companies have been successful with a podular approach?
Xerox, Procter and Gamble, AT& T and many other companies have credited self-directed teams with marked impact on their operations, including improvements in customer service, manufacturing, inventory management, and other productivity gains. In this post I’d like to highlight three highly effective podular systems: one old-school company, one new-school company, and one old-school industry that’s reinventing itself.
3M is podular
Although they are known for innovation, 3M was incorporated in 1902, which makes it more than a hundred years old. 3M was one of the companies in the famous (but unpublished) 1983 Shell study of long-lived companies that I mentioned in the original Connected Company post.
3M has roughly 100 autonomous profit centers, each of which operates like a separate company. As operations grow, profit centers divide in order to keep each group small and agile. 3M’s R&D teams are integrated with business units to keep them close to buyers and markets.
In the 1990’s 3M implemented “self-directed work teams” in their manufacturing operations. The teams do their work as a team and manage themselves. Managers in this system were freed up to become coaches and teachers – essentially full-time trainers. Self-directed teams were not a top-down directive at 3M. Initial self-direction efforts arose out of manufacturing, where complexity in the operations made traditional management cumbersome. Productivity soared.
Amazon is podular
Amazon is still a teenager, but it’s also the largest online retailer in the Unites States, and almost the biggest retailer period (in market cap, second only to Wal-Mart).
Amazon is an ecosystem
Legend has it that Jeff Bezos named his company Amazon after the world’s largest river to give the impression of size, or to ensure that it showed up high in Yahoo.com’s alphabetical listings. But I suspect that a deeper, more strategic concept underlies the name. The Amazon rainforest is one of the richest ecosystems in the world, and Amazon the company has been very deliberately organized like a complex, customer-centered ecosystem.
Rapid change: Just like animals co-evolving in a complex ecosystem, small teams at Amazon develop features in parallel. It’s a probabilistic approach, oriented toward fast-failure and recovery rather than failure-avoidance. Teams are self-organizing, self-repairing and self-managed.
Data Darwinism: New features are tested on a small portion of the overall population and compared against the original, an approach known as A/B testing. The fittest designs survive and are rolled out to the larger system. “What you want to do as a company is maximize the number of experiments you can do per unit of time” said Bezos in a 2007 interview with Harvard Business.
Amazon is built around self-managed teams
In 2004, Bezos told Fast Company that
We have this weirdness in our business… The raw ingredients that make our business — things like CPU processing power, bandwidth, and disk space — get twice as cheap every 12 to 18 months. Disk space is 30 times cheaper today than it was five years ago. Thirty times cheaper! So the real question becomes, What can you do with 30 times as much disk space, 20 times as much computing power, and 30 times as much bandwidth? All right, how are you going to make customers happy with that? It turns out that these are not easy questions to answer.
Bezos does have an answer though: Break big problems down into small ones. Distribute authority, design, creativity and decision-making to the smallest possible units, and set them free to innovate. Small teams focus on small, measurable components that customers value. One example is a team that decided to focus on finding phrases that are unique to a particular book. Says Amazon CTO Werner Vogels:
The Statistically-Improbable Phrases service… turns out to be a mechanism that brings very remarkable collections together… Remember that most of our developers are in the loop with customers, so they have a rather good understanding about what our customers like, what they do not like, and what is still missing.
Teams are limited in size to about 8-10 people. At Amazon they call them 2-pizza teams: If you can’t feed a team with two pizzas, it’s too large.
What keeps the teams close to customers? Three things:
- 1. Each team has a fitness function —a number they are focusing on – and organizes its work in any way it pleases to improve that number. Such data is critical for organizing autonomous pods: “Fact-based decisions overrule the hierarchy” says Bezos. Since each team focuses on a small part of the ecosystem, the company gets closer and closer to the data, tightening up feedback loops and helping the whole system evolve faster.
2. Teams work backwards from customer value to service or product. They start with a press release describing their intended features and start collecting feedback before they have built a thing.
3. Every two years, each Amazon employee is required to spend a couple of days interacting directly with customers at a call center or other facility.
Amazon’s approach is supported by a strong platform that allows the whole Amazon website to be developed in a massively parallel fashion by podular teams. When you visit an Amazon page, you might be accessing a hundred or more web services that are orchestrated to give you a personalized experience. Behind the scenes is a sophisticated service-oriented architecture that allows Amazon’s podular teams to access common data and functionality without having to worry about interdependency and conflict. “Any algorithm that requires agreement will eventually become a bottleneck… each node should be able to make decisions based on the local state.” says Amazon CTO Werner Vogels. Because of the architecture, services can evolve in parallel without affecting each other.
What could be more old-school than the automotive industry? With the innovations of Henry Ford, the automotive industry ushered in the Industrial Revolution. But the automotive industry has not remained static over its hundred-year lifespan. Alfred Sloan began the trend to decentralize work when he designed the first truly modern corporation, GM, with a centralized finance and planning function that oversaw semi-autonomous business units. And between 1950 and 1975, Taiichi Ohno of Toyota reinvented the assembly line with the Toyota Production System, which pushed autonomy even further – down to the factory floor.
Perhaps one of the most exciting innovation platforms I’ve heard about recently isn’t a company at all – it’s more like a hive of podular activity. The Chinese motorcycle industry is a buzzing ecosystem of companies that creates motorcycles using a common platform and modular components. Because of this simple platform, motorcycle manufacturers can outsource components to suppliers with confidence that the pieces will fit together in the end product. The common platform also gives the component makers a lot of freedom to innovate within the modular structure.
The Chinese motorcycle industry has exploded onto the global market. China now makes more than 50% of the motorcycles in the world.
A US-based company named Wikispeed has adopted the same approach with the design of the SGT01, a car designed as a modular platform which will empower suppliers to innovate freely. Each part of the car is a component that fits into a standard interface. For example, when the engine wears out, it can be removed and replaced in one piece, like a tire. Although they are still seeking funding to go into full production, they have designed a 4-seater commuter car that gets up to 114 miles per gallon and can sell for $20,000 using this approach. Although it’s not in production yet, you can still order one today on the internet.
Do podular systems have to be embedded in a company from day one? I don’t think so. As we saw with the PC, disruptive or architectural innovation is possible within existing companies. But think about how that transition happened – in many cases because managers were brave enough to take on the internal powers-that-be, such as corporate IT, and take personal risks that they knew would increase the productivity in their unit. If you want to go podular you will need to face some challenges:
How to reward performance?
Self-managed teams must not only have authority, they must be accountable for the results they deliver. The results the team is responsible for should be clear and measurable. There is some debate over whether self-directed teams should be compensated on a pay-for-performance basis. Some say that it damages morale and performance should be recognized in other ways. Some say that it works, so long as it’s done well. The jury is out. My opinion here is that most pay-for-performance systems are costly, difficult to measure, and tend to encourage people to game the system. So I believe successful teams should be rewarded in other ways: by being recognized by their peers, or allocating more of the resources that make them successful, like better equipment, more people, support, and so on.
How do you deal with loafers and disagreement within the team?
This is where culture is critical. The culture of the company should be clear about expected behaviors like resolving disagreements, dealing with underperformers and so on. Letting teams self-organize will alleviate many of these issues up front. 360-degree reviews, where employees rate each others’ performance, can also help.
Do you have an infrastructure that can support the pods?
Culture is the most important support infrastructure you can possibly have, because it clarifies behavioral expectations and offers an approach for resolving conflicts. When a culture is working, it is also self-managing and self-reinforcing.
Technical standards help to reduce friction, but they are secondary to culture. Focus on culture first, and teams will start to demand the technical infrastructure they need to perform.
Complexity and interdependence among business units.
If your organization is not already constructed in a modular fashion, then architectural innovation is difficult at best. Most architectural innovation does not happen within a firm but within an industry. But any principle that can be applied within an industry can also be applied within a department. What you want is a part of the company that can be treated as a “black box.” If you can clarify the inputs and outputs you expect from a group or department, and what is inside the black box has limited interdependencies with other units, you have a sandbox where you can experiment with pods.
Find an area that is clearly connected to customer value, that’s as independent as possible from the rest of the organization. Early adopters in the PC revolution were sales teams, historically an area where broad autonomy is accepted as long as the group delivers results.
Can you go the distance?
Patience is important. If you implement a team-based approach, productivity will get worse before it gets better, as people learn new ways of working and build trust with each other and the wider organization. Set a reasonable time frame and give the pods some time to ramp up.
The self-empowered team concept is not new. In fact, it precedes the Industrial Age altogether. In an age where passion and creativity is increasingly important, we need to take another look at organizational forms that play to natural human strengths, like ingenuity, curiosity, and the joy of making a clear and recognizable impact on the world.
The road ahead
Pods aren’t the answer to every problem. But customers are demanding more and more. The world is increasing in complexity and more than 90% of CEOs say they will need to restructure the way their organizations work in order to deal with it. Chances are that the changes you will need to make are not so much incremental as fundamental. If you’re not ready to start now, then when will you be?
Think about the level of complexity in your business, and ask yourself if it’s increasing or decreasing. Ask yourself:
- How close to customers can your company make decisions?
How fast are the feedback and learning loops on the things that customers value?
How fast can your organization adapt to changes in your business ecosystem?
What do you need to do in your organization to prepare for the next 20 years?
Give pods a chance. The future is podular.
The IBM 2010 C-suite study series reveals senior executives’ prevailing views about complexity and the need for deep transformation.
Amazon CTO Werner Vogels discusses the technology infrastructure that supports Amazon’s podular approach.
1995 article about self-directed 3M teams by Ron Williams.
If you don’t feel like reading, here’s some stuff you can watch:
Thank you Doug Miller for pointing me to some of the rich history of self-directed teams.
Note 1: The term podular and the use of the term “pod” to describe self-directed teams is my own concoction. Do we need a new term? We can debate that, but “self-directed work team” is rather a mouthful, and SDWT is even worse. We could call them cells, but as a manager I can’t imagine trying to get people excited about going to work in a cell every day. Use your own term if you want, in the end it’s not the terminology but the change we make in the world that counts.
Note 2: I’m counting the 2001 reference as “fair use.” That’s my story and I’m sticking to it