One of the most difficult challenges companies face today is how to be more flexible and adaptive in a dynamic, volatile business environment. How do you build a company that can identify and capitalize on opportunities, navigate around risks and other challenges, and respond quickly to changes in the environment? How do you embed that kind of agility into the DNA of your company?
The answer is to distribute control in such a way that decisions can be made as quickly and as close to customers as possible. There is no way for people to respond and adapt quickly if they have to get permission before they can do anything.
If you want an adaptive company, you will need to unleash the creative forces in your organization, so people have the freedom to deliver value to customers and respond to their needs more dynamically. One way to do this is by enabling small, autonomous units that can act and react quickly and easily, without fear of disrupting other business activities – pods.
A pod is a small, autonomous unit that is enabled and empowered to deliver the things that customers value.
By value, I mean anything that’s a part of a service that delivers value, even though the customer may not see it. For example, in a construction firm, the activities valued by customers are those that are directly related to building. The accounting department of a construction firm is not part of the value delivery system, it’s a support team. But in an accounting firm, any activity related to accounting is part of the customer value delivery system.
There’s a reason that pods need to focus on value-creating activities rather than support activities. Support activities might need to be organized differently. More on that later.
Process to pod
Traditionally, it’s been the job of managers to coordinate activity across divisions or lines of business, because processes are usually complex and interdependent. Making changes in one part of the process might solve a problem for that unit but cause problems for others.
The goal of podular design is to reduce interdependency by enabling autonomous pods to focus on clear outcomes that deliver value to customers. Pods can coordinate with each other via clear cultural, behavioral and technical standards.
Chains vs. nets
You can think of any business process as a chain – a series of steps that people go through to get things done. Processes don’t depend on the intelligence or creativity of the people who run them, so much as their consistency and ability to perform a specialized task. The manager of the process is responsible for the intelligence of the system.
A process is like a recipe. Recipes are fine as long as you want to achieve the same result every time. But recipes are also very brittle when it comes to change and innovation. If you are responsible for a part of a complex process, it’s hard to try something new.
If you get one step wrong, there is a cascading effect, and everything downstream from that change is affected. Small changes at the beginning of a process can have devastating effects elsewhere in the system.
A chain, as the saying goes, is only as strong as its weakest link. Break one link and the whole chain fails.
A podular system is like a net. It distributes the work load across a wider area by allowing each pod to focus on goals rather than steps or stages. If one strand breaks, the system can still carry the load.
In a podular system, the burden of creativity and intelligence is on the people in the pod. In a pod, your focus is on solving problems and delivering value rather than executing previously-defined steps. You can no longer pull the levers, move the dials and say you did your job, even though the customer didn’t get what they wanted. Giving the customer what they want is your job.
If processes are fool-proof, then pods are fail-proof.
Standards and protocols
Even without a traditional command-and-control hierarchy, autonomous pods still need to make decisions and coordinate their activity in order to deliver value to customers. The secret of coordination is to make those exchanges as frictionless as possible.
Technical standards are simply interfaces that allow you to connect things at will. For example, the electrical socket in your wall uses a common standard that allows you to get electricity when you plug in a device. When your electrician installed that socket in the wall, you didn’t have to know in advance what you might want to plug in to it. And device-makers can be confident that if their plugs follow a common standard, you will be able to plug it into your wall.
Those of us who travel a lot wish that the world had a common electrical standard, but alas it does not. And, sadly, these kinds of standards are not as common in business as you might think. But things have come a long way in the last ten years or so.
Service-Oriented Architecture (SOA) and Software as a Service (SaaS) are ways to bundle small pieces of functionality into pods that anyone can access. PayPal, for example, handles payments securely and quickly via standard connections with other companies. Any web service or company can easily link in PayPal for payment processing, which means they don’t have to build that function for itself. But even such a simple thing as a standard protocol for email addresses (first initial, last name, for example) can help people connect with less friction.
Decisions: If you’re in a pod and you need to make a decision, common values can help you make that decision autonomously, without the need to check with superiors. This means you can act more quickly than competitors who need to “check with the boss” before they can proceed. Common cultural standards give you confidence that your behavior will be consistent with those of other units.
Connections: If your pod needs to connect with other pods, it’s easier to link up and collaborate when you know what kinds of behavior to expect – when you speak the same language and work in the same way. Pattern languages are collections of common standards that allow teams to more easily connect and collaborate. Gamestorming, for example, is a pattern language for cross-disciplinary design.
Culture can be as simple as a set of shared values, or it can be codified in rules and policies. The important thing is that the values and rules are understood and the behavior is consistent with them. If the culture says everyone is equal, the CEO better not have a reserved parking spot. Culture is built by establishing behaviors that the whole organization can and will adhere to consistently.
Pods are flexible, pods are fast
When pods are autonomous, they can try new things without worrying about a “ripple effect” that will disrupt the activities of other units. They can adopt new tools and practices quickly, without having to ask permission. They can be flexible in the ways that they choose to respond to customer requests. This means that each pod can be free to innovate, try new things, adjust its work process, and so on.
Even though most innovations will happen at the pod level, innovation doesn’t have to be contained to one pod. Since linking up with other pods is realtively friction-free, an innovation in one pod can be quickly adopted by other pods.
Pods can fail
When a step in a complex process fails, the entire process comes to a halt. In a Toyota plant, workers have the power to stop the entire process when they see a problem or opportunity. This is great in the sense that it enables a process to continually improve, but it doesn’t solve the problem of interdependency – the whole process still must stop in order to accommodate the change.
In a podular system however, each pod can make adjustments without disrupting its neighbors, and even when a pod fails, there is enough redundancy in the system that those services can most likely be found elsewhere.
A recent New York Times article describes how Volvo is reinventing the automotive assembly line to make it more podular. Quality and productivity have soared. According to the article, Volvo’s approach has led to 20% pre-tax profitability and 25% return on capital, making it one of the most profitable car companies in the world.
Pods can scale up fast
Since pods are inherently modular, it’s easier to scale them up to meet increases in demand. There’s a huge amount of tacit experience in each pod, because each pod is like a tiny fractal snapshot of the entire business – focused on customer value instead of a specialized task or functional process step.
This means that when it’s time to scale up a particular service, a pod that has, for example, seven people, can reproduce itself by dividing into two pods which can bring on new members with minimal growing pains.
This kind of growth system is not new. It’s been a standard practice in knowledge-intensive professions for hundreds of years. When a job requires a lot of experience and creativity, people learn by apprenticing themselves to others who are more experienced, and they learn by doing. Think of a medical intern in a hospital, or the patrol cops in your favorite police drama. They always team up the rookie cop with the experienced veteran so the new cop can learn the ropes.
A podular system needs a backbone
For a podular system to work, cultural and technical standards are imperative. This means that a pod’s autonomy does not extend to choices in shared standards and protocols. This kind of system needs a strong backbone that clearly articulates those standards and provides a mechanism for evolving them when necessary.
For small and large companies alike, the most advantageous standards are those that are most widely adopted, because those standards will allow you to plug in more easily to the big wide world – and the big wide world always offers more functionality, better and more cheaply than you can build it yourself. Backbone activities are about coordination and consistency, so the best way to organize them may not be podular. When it comes to language, protocols, culture and values, you don’t want variability, you want consistency. Shared values is one of the best ways to ensure consistent behavior when you lack a formal hierarchy. Consistency in standards is an absolute requirement if you want to enable autonomous units.
Backbone decisions can be dictated from above (for example, the way Apple dictates standards for its App Store) or agreed by consensus (for example, the way Web standards are developed). What’s most important about backbone decisions is that they focus on the connections between pods rather than within pods In other words, a pod can do what it likes internally, but when it shares or receives information it needs to speak the same language as other pods.
But to truly enable the pods, backbones should be as lightweight as possible. Consider this: The U.S. military will be using standard internet protocol as the backbone for its net-centric warfare strategy, a podular approach to military operations. If internet protocol is secure enough for the U.S. military, it’s probably secure enough for you.
A podular system trades flexibility for consistency
Pods don’t answer every business problem. Like any other strategic decision, the choice to go podular involves inherent risks and tradeoffs. A podular system is certainly not the most efficient or consistent way to conduct business. There is more redundancy in this kind of system, which usually means greater cost. When units are autonomous, activity will also be more variable, which means it will be less consistent.
The bet you are making with a podular strategy is that the increase in value to customers, paired with increased resiliency in your operations, will more than offset the increases in costs. It’s a fundamental tradeoff and thus a design decision: the more flexible and adaptive you are, the less consistent your behavior will be. The benefit, though, is that you unleash people to bring more of their intelligence, passion, creative energy and expertise to their work. If you’re in an industry where these things matter (and who isn’t), then you should take a look at podular design.
If you want to dive deeper into podular thinking, take a look at the following:
The view from the pod: Personal Kanban: Mapping Work, Navigating Life by Jim Benson lays out a framework for podular work teams.
The company view: Rethink: A Business manifesto for Cutting Costs and Boosting Innovation by Ric Merrifield gets into greater detail about how companies can make the shift from process to podular, with examples from Amazon, Procter & Gamble, JetBlue and others. (many thanks to @jcsteels for pointing me to that one!)
The market view: The Origin of Wealth by Eric D. Beinhocker takes a deep dive into the nature of economies and the arguments for more podular organizations.
In times of stability, the world belongs to those in power. In times of change, it belongs to the bold, the bright, the brave. Seize the day!
Thank you to Larry Irons for pointing me to the New York Times article about Volvo podular approach.