In our blog on the micro-battles training agenda, we referred to our Leadership training workshop, where we work with leaders to better understand how to manage the portfolio of micro-battles. A good deal of this training is about behavioral change, but we also train on skills. One skill that’s common to most companies working on micro-battles is scaling. But to put it bluntly, most companies realize they’re not very good at it. This is our collection of best practices for scaling issues.

Quick context: Scaling is at the heart of the Bain Micro-battles System℠. And we’ve been writing about it for a while. In introducing the Win-Scale model, we described in some detail how to move from a prototype to a repeatable model. Specifically, we warned that too often, companies jump from a working prototype to a playbook to a rollout in the organization. We covered all the steps that need to happen between prototype and playbook, and also discussed alternative scaling models. In our blog “Introducing the Bain Micro-battles System,” we covered the need to build scaling skills and introduced the idea of the “three communities”—one that disrupts, one that executes, and one that scales by bridging the gap between disruption and the playbook. In fact, this idea of the scaling community has become so critical that we recognize it as one of the six design principles of the scale insurgent. So we’ve been focused on scaling from Day 1. And after completing detailed interviews with leading CEOs on the topic, we want to share their tips with you. Here are the top 10, along with implications for your executive teams.

Founder's Mentality®

Micro-battles

Want to learn more about the journey to scale insurgency? Explore the Bain Micro-battles System℠, step by step.

1. Recognize that scaling will be critical to your success and that a winning repeatable model will require an iterative process. Demand that your leaders remain in balance across the Win-Scale and Amplify stages. The need for balance plays out on two levels.

• Balance within micro-battle teams. Leaders working on individual micro-battles must constantly balance the need to test and learn in the short term with the need to scale prototypes across the company in the long term. Prototyping is about winning. It demands that the leader make problems smaller so the next minimally viable product can be shared with customers. You’re working fast, testing and learning as you go. The act of scaling, however, demands you test early on whether you can transfer the prototype to other parts of the business. You also must define early on the ultimate repeatable model you’re trying to build. And a key issue for repeatability is behavior: What changes do we need to make to ensure that our front line pulls through this model and adopts it quickly? It’s tough to keep balance—teams get overly focused on one extreme or the other. Some teams are obsessed with addressing behavioral change and forget to prototype. Others are fantastic at prototyping, but consider scaling too late—they end up prototyping the wrong things. This is why we focused so much time on the skills of winning and of scaling. Forcing a debate on “will this prototype scale?” early in discussions will speed up the overall time to scaling. Examples abound of a better prototype emerging from a specific discussion on the repeatable model.
  • At a global airline, teams were working on reducing costs. They wanted to see if they could automate certain coordination tasks that were being performed by midlevel managers who collected information across multiple teams. Several technology options were available, but they settled on an electronic pad for the flight crew. Why? They had a debate about how they could create a repeatable model that would eliminate paper for all flight crew and airport staff.
  • At an Asian consumer goods business, teams redefined a prototype to improve the product mix in stores, from one that would work with individual retailers in the general trade to one that would work with wholesalers. It was only when they started discussing the repeatable model that they realized they’d never have the resources to roll out the prototype to individual mom-and-pop shops. They had to work through wholesalers if they were going to distribute resources properly.
  • In a global logistics business, teams redefined the prototype from specific service improvements by function to integrated solutions for a single customer. They realized that the functional prototypes would never deliver a repeatable model for integrated customer solutions. They had to prototype cross-functional solutions within single customer accounts.
• Balance across the portfolio of micro-battles. We also demand balance within the Leadership team managing the portfolio of micro-battles. On one hand, we want them to act like insurgents: helping to accelerate individual micro-battle teams, making problems smaller, unblocking organizational obstacles with surgical intervention. On the other hand, we want them to learn lessons across micro-battles and be prepared to make major interventions in the company’s strategy or operating model. They must ensure that the micro-battle teams are having a scalable, material impact on the value of the company. It’s tough to maintain balance within the executive team. Some teams are obsessed with helping each micro-battle team, but miss the forest for the trees. They don’t see patterns across micro-battles, and they don’t lead big interventions. Others are obsessed with the broader strategic or organizational implications of micro-battles. They don’t focus enough on making individual teams successful. This is why we invested time in covering the skills demanded during the Amplify stage of micro-battles.

Implication No. 1: Ensure that the idea of staying in balance is front and center on your mindset wall (see "Micro-battles and the Learning Center"), and interrogate your micro-battle teams from Day 1 on the repeatable model they advocate and the scaling issues they’ll address. These issues aren’t addressed after building a successful prototype—they happen during the prototyping process.

2. Use the standard taxonomy of the three levels (customer experience, business process and technology) to address common scaling issues from Day 1. By anticipating demands to change business processes and support new technology solutions, you can track and unblock resource bottlenecks earlier.

In our blog “The Three Levels of Micro-battles,” we introduced the idea that the most successful micro-battle teams working on the most successful innovations always address three levels. They do so in the following order: customer experience, business process, technology. The best teams start with the customer and ask, “Which episodes of the customer experience are we actually trying to improve?” At the same time, they’re focusing on scaling by testing whether they can transfer prototypes to other customers and markets. Then they move to level two by asking, “To fully implement the improvement of customer experience X, what business processes do we need to improve?” And these business processes ultimately lead to level three, or the question, “What technology solutions are needed to improve business process Y?”

Understanding the three levels can help you address common scaling issues before they become blockers. Are multiple teams planning to draw on the same areas for changes in business processes or technology? Are there resource bottlenecks that you can unblock in advance by reallocating or recruiting additional resources? A common taxonomy, which defines the three levels and breaks out their specifics, can help. Introducing the taxonomy ensures all teams use the same language to make requests and to define the resources they need.

Implication No. 2: Support your micro-battle teams as they go through the cycle of the three levels. Introduce the common taxonomy and challenge the teams to think about each level early to identify resource bottlenecks. Share lessons from the three levels across the micro-battles portfolio. As we noted elsewhere, all roads lead to technology, but they don’t all start there. Best to start with the customer.

3. From Day 1, identify the people at the center of customer, process and technology bottlenecks. Address the “everyone wants Brent” problem.

The “everyone wants Brent” problem recognizes that many of your micro-battles will depend on three to four functional leaders. At first, you’ll think of the Brents as stars—they’re in such extraordinary demand that they must be extraordinary individuals. But then you start to realize something. The Brents of your world haven’t institutionalized (and therefore scaled) their knowledge. They’re a bottleneck. While we don’t want to judge the Brents’ motivations, you could say they’re using their knowledge to wield power in the organization. They ensure that they’re in constant demand and use the subsequent shortages as a form of leverage. This problem is discussed brilliantly in Gene Kim, Kevin Behr and George Spafford’s book The Phoenix Project. They suggest a simple solution: Surround each Brent with two emerging stars in your business, let’s call them Jane and Simon, and impose two rules. Rule No. 1: Brent can no longer do anything by himself; he must tell Jane how to support micro-battle teams. Rule No. 2: Simon must work with Brent and Jane to create an institutional workbook for all of Brent’s main activities, so others can be trained for Brent’s job.

Implication No. 3: Identify the list of Brents who are emerging in the early days of micro-battle staffing and begin imposing “The Phoenix Project Rule Book.”

4. Don’t jump to playbooks. Scaling models differ according to the degree of tailoring required and the breadth of people who come on board. We spoke in detail about this in our blog on scaling a repeatable model, so we’ll refer you there. But let’s highlight a few best practices that have emerged in this context.

• Be realistic about the degree of tailoring required. We all want to believe that once we have a winning prototype, we can painlessly scale it across the organization. But life isn’t that simple. Even the best Repeatable Models® still require tailoring as you roll them out across specific products, channels or markets. Don’t be naïve. Talk about it honestly.
• Allocate enough resources to scaling. Everyone wants to believe that the best rollout model is to send out playbooks. But few prototypes can be scaled simply through playbooks, so everyone seriously under-resources the scaling step. Once you have honest conversations about the degree of tailoring that the rollout demands, you can start having honest conversations about resourcing.
• Assume push rarely works, and focus on creating pull. A common sentiment that we hear at best-practice companies is, “Pushing bad ideas to frontline people who know better is called change management—and change management never leads to change.” To scale initiatives, you need honest discussions about how to pull the initiative. In other words, how will you make sure the initiative is so helpful that your people will fight to bring it to their market? Best-practice companies start these conversations on Day 1. A good question to ask at that time is, “Can we make the case to the front line that this new initiative will make them more money or save them time?”
• Consider “influencers” in how you build your micro-battle teams. To create pull for solutions that emerge from micro-battles, you’ll need to consider a different makeup for your micro-battle team. You’ll want to bring early adopters, influencers and some detractors into the process very early, so you can design solutions. You’ll think about how to use their testimony to create demand elsewhere in the company.

Implication No. 4: Challenge your micro-battle teams early on how they’ll create pull for change. This will help them think about the right team of influencers to bring on board.

5. The best scaling models consider the “unit of scaling.” Jargon alert: What the heck do we mean by “unit of scaling?” Here’s an example. When you study the early days of Enterprise Rent-A-Car, you see that the founders were crystal clear on the company’s unit of scaling. Enterprise would grow by adding more and more branches, each with a fleet of 150 cars. If the branch got bigger than 150, the company would divide the branch into two branches and regrow them to 150. So the unit of scaling was the branch, and you could grow only as fast as your ability to grow branch managers. This focuses the mind. All your micro-battle teams should consider the unit of scaling from Day 1, so you can identify unanticipated bottlenecks. The right scaling model might even force you to change the Win-Scale team. Here are a few more examples:

• At a consumer products company, a core micro-battle was to improve online sales by identifying which daily offers prompted consumers to make purchases. It developed a checklist of things to test for creating higher revenue. It was a proven repeatable model. The unit of scaling was to use this approach with all major products, marching down the checklist for each one. But the checklist didn’t lend itself to algorithms; a smart marketer had to run the process. This was the bottleneck—and it was identified on Day 2. That meant the company needed to start recruiting and training the marketers before it had even finalized the checklist.
• A global logistics business created cross-functional solutions for top customers. We cited this company earlier for shifting its prototypes from functionally focused to customer focused. The unit of scaling was its customers—specifically, the top 40 customers. Because each micro-battle included executives of those customers, this demanded top-to-top discussions between CEOs who had to commit resources to the journey. The early bottleneck was actually the logistics company’s CEO, who needed to set up 20 meetings with his top customers’ CEOs. This was recognized in the first Leadership review session, after the team reported that it had shifted the prototype to customers.

Implication No. 5: Ask your teams specific questions about the unit of scaling, and use this conversation to identify early resource bottlenecks.

6. Everyone still underestimates the behavioral change required. In our discussion of the six design principles of a scale insurgent, we highlighted that few companies figure out how to ensure Agile teams are working productively with global functions, which operate in traditional hierarchies. Agile micro-battle teams work fast and rely heavily on a test-and-learn model that requires multiple iterations. They also rely on their companies’ global functions to work with them—not simply by supplying resources for micro-battle teams, but also by enabling a winning prototype to scale. But here’s the rub: At the point you need to scale a winning proposition, you need to work directly with a large, hierarchical structure that’s working according to its own timelines and priorities. Either micro-battles scale at the pace of the slowest hierarchical group, or you need to start helping the hierarchies reprioritize their agenda. This way, micro-battle teams can get resources when they need them. That’s an easy sentence to write, but a difficult mission to pull off. A key part of this difficulty is behavioral—the functional leaders will agree on new priorities, but won’t change their behaviors. Old initiatives remain in place, and old resources are locked into them. You’ll make a decision to simplify or stop doing things—then find nothing is simplified or stopped. Inertia is a hard thing to disrupt. That’s why our Leadership workshops focus so much on the need for behavioral change, for both the leaders in that room and the teams they lead. That’s also why we talk about the first 100 days as a series of foundational elements, training modules, interventions and communications. Prepare to intervene a lot.

Implication No. 6: Set aside time to work through how group functions support the micro-battle teams to scale their initiatives. Recognize that this will take a long journey to get right.

7. Understand the role of the three communities and the specific skills required. This might be the most important best practice on the list and the one where the most innovative work is happening. Perhaps immodestly, we think our work with companies on the three-communities issue is some of the most exciting work in Agile enterprise today. We described the three communities in an earlier blog: All companies consist of three communities that operate across structural boundaries. The first is the Agile/disruptive/innovator community—this is 5% to 10% of your activities. Members of this community are disrupting your products and services, your core business processes and your business model itself, to ensure that your customers benefit from innovation. The second is the expert/execution community—this is 85% of your activities. This community is simply executing existing playbooks. This community delivers to your customers the benefits of the flawless execution of a repeatable model and the continuous improvement that comes from good feedback loops. But there’s a third, routinely overlooked community—the scaling community. This is the 5% to 10% of activity that bridges the gap between innovation and execution. Members of this community can turn disruption into routine and recognize the behavioral changes required for scaling new ideas. The simple truth is that no one is talking about the scaling community. This explains why companies have such a hard time scaling Agile. Here’s what our best-practice companies are doing to address this gap.

• They name the scaling community. You can’t begin to address a problem until you can name it. These companies are united by putting a simple sentence on their mindset wall in the learning center: “We must build the scaling community so its members can begin to bridge the gap between innovation and adoption, between disruption and routine.”
• They invest in building the scaling community and recognize that it takes a village. Their starting assumption is that no one is in this community now, but the skills to create this community exist in team members currently involved in execution or innovation. Here’s our short list of these skills. You’ll immediately recognize that we’re not looking for one individual who has it all. We’re creating a diverse community that has these skills.
  • Playbook-development skills to make things simple and practical for the frontline teams executing long-established playbooks. We all know extraordinary leaders who can take incredibly complex ideas and turn them into something simple that others can follow. Over my 30 years of consulting, the single best master of this I’ve seen is Harish Manwani, the former chief operating officer of Unilever. Because of his years of experience managing salesforces, he has a unique ability to turn complex strategic ideas into clear tasks for his sales team. The scaling community starts with your best example of Harish.
  • Builders of Repeatable Models who understand scaling models. Some business leaders are superb at “rolling things out.” They always strike the right balance between a single, inflexible repeatable model vs. a rollout that requires tailoring by market, channel and product. They have keen instincts built from years of experience—they understand the yield loss of a bad rollout. Find them.
  • Pedagogical skills to make ideas teachable. Scaling demands training on the new ways of working. Some of your leaders will be adept at moving from an idea to something that can be trained. This is its own skill.
  • People-development skills to understand the right set of incentives and behaviors to create a pull for change. It’s a common refrain among our best-practice companies that successful scaling almost always requires us to create a pull for change. Finding the core variables to drive this pull is a separate and important skill.
  • Builders of the Net Promoter System® and employee Net Promoter System who know how to create and run feedback loops. All good scaling initiatives demand feedback loops so your execution community can continually improve. This involves feedback loops of employees (employee Net Promoter System) and customers (Net Promoter System).

Implication No. 7: Start building your scaling community today, focusing on these five essential skills.

8. Scaling well demands shifting resources quickly behind a winner. This is self-evident, but worth stating clearly. The whole point of micro-battles is to improve the value of your company and to rediscover the skill of getting the right things done fast. Some of your micro-battles will be real winners, demanding 10 times the resources of others. Your ability to back the winners and over-resource them will be critical to creating value. This can’t happen within an annual budgeting process. It has to be far more dynamic. And the 10-times resources have to come from somewhere, including resources and investments that were agreed upon during an annual cycle. Your Leadership sessions will demand that you continually free up resources from elsewhere to back winners. In almost every case, there are two immediate lessons.

• You’ll need to launch micro-battles on costs to fund the winners. So why not start a series of cost micro-battles to anticipate these funding demands?
• You’ll be simplifying your functional agenda, to move from the “tyranny of functional excellence” programs to a much more focused agenda based on capability spikes. So why not launch an insurgency workshop from Day 1, so that you can reprioritize your functional agenda?

Implication No. 8: Introduce dynamic resource-allocation processes into your Leadership sessions, and start on Day 1 to consider how to free up resources to fund winning micro-battles.

9. Eventually, scaling will demand changes to your operating model. Interventions are required to get Agile teams to work with hierarchical organizations. Earlier, we mentioned that you’ll need to change behavior in order to ensure your global functions work within the timelines of micro-battle teams. But of course, it’s more than that. Ultimately, you’ll need to change your operating model to ensure that the functional teams speed up and become more dynamic in their own allocation of resources. We’ve seen common patterns emerge across organizations. Given that a common goal in micro-battles is to improve the customer experience, which will demand process and technology changes, we’ve found that organizations need to build out six capabilities.

• A customer-experience focus: As we noted earlier, successful micro-battle teams always start with the customer experience. Define the organization’s customer taxonomy and assign experience owners. Support them with strong process disciplines.
• Agile enterprise: Build Agile teams throughout the organization; experimenting with Agile in isolation is likely to fail. The organization needs to widely embrace new ways of working and create transparency across functions and groups to remove silos.
• Human-centered design: Put the customer at the center of all design work. This need can be filled initially through partnerships, but building this capability is essential for the long term.
• Data analytics: Data analytics is critical to developing winning prototypes that you can test with the customer, and increasingly important in businesses where personalization is key to the product. Ensure your data analytics capability is sufficient to drive the critical insights required to win.
• Flexible technology: Maintain flexible but stable system architecture throughout the stack (front to back) to support new front-end prototypes. This role is often outsourced, leaving organizations with big capability gaps and an inability to execute.
• Strategic partnerships: Form partnerships with business, marketing and technology providers to fill capability gaps, if needed. Ensuring the organization has the right operational and commercial capabilities to enter into successful partnerships is key.

A common lesson among best-practice companies is to begin not with structural changes, but rather with surgical strikes in governance and accountabilities, and new incentives for talent. Consider micro-battle resourcing in all resource decisions at a functional level. Bring members of the Leadership team into these decisions, so they can help set the right priorities. During our Leadership training, we emphasize brainstorming on some early quick wins.

Implication No. 9: Consider simple changes to governance, accountabilities and new incentives for talent to ensure that discussions of global priorities and resourcing give precedence to micro-battles.

10. Use Engine 2 to build specific capabilities. If you don’t, the most important capabilities will languish. While building the scaling community (see Lesson 7) might be the most important action, using Engine 2 to help you build capabilities is perhaps the most counterintuitive. As you become obsessed with scaling, you’ll find yourself creating a long list of capabilities that you need to build. And no matter how much you emphasize their importance, you’ll find that those initiatives always end up at the bottom of the Engine 1 to-do list. There are simply too many priorities. One best practice we’ve seen is to move those initiatives over to Engine 2, giving them the freedom to find ecosystem partners to build these capabilities. Several companies are doing this to great effect.

Implication No. 10: Think about building scaling capabilities across Engine 1 and Engine 2.

That’s it. Long blog; rich topic. And we’re certain this won’t be our last word on the topic, but rather the beginning of a rich conversation.

Related

How to Identify Great Scalers

People who excel at scaling businesses are defined by a unique set of traits and behaviors.

Bain Micro-battles System℠ is a service mark of Bain & Company, Inc.

Repeatable Models® and Great Repeatable Models® are registered trademarks of Bain & Company, Inc.

Net Promoter Score®, Net Promoter System®, Net Promoter® and NPS® are registered trademarks of Bain & Company, Inc., Fred Reichheld and Satmetrix Systems, Inc.