This blog post covers one topic. How should you think about deploying the full Micro-battles System vs. alternative approaches to becoming a scale insurgent? The question dovetails into another one: How does any of this fit with the day-to-day challenges of running your company? We start with a bit of empathy, then describe four different approaches and finally step back to discuss how to think about the right fit for you.
A bit of empathy to start
We get it. You and your organization are busy. You’ve got multiple initiatives across the board, each of them drawing upon the same set of resources. Most of your stars are already double-booked between big-time day jobs and promises to help other teams transform the company. On top of this, the destination targeted by micro-battles is daunting: You’re considering launching into something few companies have accomplished—namely, the journey to become the scale insurgent in your industry and to become an Agile enterprise. Oh, and did we mention that your last few attempts at transformation didn’t work out so well? You have scars, and as a group of scarred and battered folks, you’re not even sure you’ve got all the capabilities you need to start this journey.
So, yeah, we get it. But to cite a quotation commonly attributed to Mark Twain, “The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one.” He also wrote words to the effect of: “If you hold a cat by the tail, you learn things you cannot learn any other way.” Between the two, the message is: “Just get started. Great things will happen, but you’ll get scratched a bit and will have to endure a lot of screeching.”
Four alternative starting points to the journey to scale insurgency
In addition to micro-battles, we’ve seen four other patterns for getting started on the journey to scale insurgency. Each has its own appeal, but they all share one core feature—the senior team is committed to the full journey from Day 1. Here are brief descriptions of the four.
- Start by turning innovation teams into Agile innovation teams. My colleague Darrell Rigby, who leads our innovation practice and has written extensively on Agile, argues that the way to get started is with Agile experimentation. This begins with setting up a couple of Agile teams focused on innovation and gradually introduces Agile teams across the whole innovation department (think of your major product or service groups). At the same time, you experiment with Agile in other parts of the organization. As you create more and more Agile teams, you begin to hit critical mass and eventually move to Agile at scale. One important realization on this journey is that the notion of what constitutes a product will morph over time. At traditional companies, products are what you sell to customers and projects are what you do internally to improve operations. But Agile teams recognize that projects are really products for internal customers and that the Agile test-and-learn approach is the most effective way to improve them.
- Launch micro-battles through the four doublings. We have argued in these blog posts that an effective way to start the journey is to find the “first failure points” of your most important strategic initiatives and attack them with micro-battles. You run these battles as microcosms of the company you want to become and scale what you learn to the entire enterprise. We recommend you start with three micro-battles, and once these are stabilized through three or four cycles, you double to six. Then rinse/repeat, double to 12; rinse/repeat and double to 20 to 25 micro-battles. These are all sponsored by top executives and, over time, micro-battles come to dominate their discussions and agenda. The approach is heavily oriented toward changing senior executive behaviors from the outset, since we find that bad leadership behaviors are often a company’s most significant handicap.
- Start with Engine 2 and roll back to Engine 1 once proven. Another alternative is to start outside your Engine 1, which is the core part of your business. You can either deploy Agile experimentation or micro-battles, but the point is you set up a separate Engine 2 lab as an initial focus. The argument for this approach is simply that Engine 1 is too overwhelmed or too hard to change initially, so you want to gain proof of concept elsewhere. But we are emphatic here. While this is a perfectly good first step, you should embark on it clearly intending to apply what you’ve learned in Engine 2 to the core Engine 1 business. Otherwise, this looks too much like a few astronauts blasting off for Mars, having given up on Earth altogether.
- Free up space by starting with massive complexity reduction. This isn’t a small step, but it’s sometimes absolutely necessary, as we discussed in our book The Founder’s Mentality. Sometimes the core business is in such a state of free fall that you have to start with a massive program to reduce complexity and costs. This gives you time and resources to do other things or launch a different organization or strategy. My fellow partner Manny Maceda talks a lot about the importance of choreographing a transformation, noting that the magnitude and velocity of change depend on your financial condition and the degree of turbulence. Sometimes you have the time to move deliberately; other times you have to change everything at once.
How to think about the choices
First, let’s note that these alternatives aren’t mutually exclusive. You could pursue Agile experimentation and micro-battles in different business units. You could pursue both in Engine 2 first and then move to Engine 1. You could pursue both in key parts of the business, while going through a major cost- or complexity-reduction program elsewhere. Second, these alternatives are just the start of the real journey, and you need to concentrate as much on the point of arrival and the challenges ahead as you do on first steps.
Let’s look at some advantages and disadvantages of each. The great thing about launching with Agile experimentation is you can get started very quickly and create early wins and evangelists. You still need the senior team on board and committed to the journey, but you can launch with a small, devoted group of innovators ready to deploy new ways of working. While micro-battles fully adopt Agile ways of working, there are two burdens of a micro-battle system. One, senior leadership plays a very active role from the outset, and success rides on behavioral change at the top. Two, it’s important to coordinate micro-battles as an integrated program with common timelines, which demands more coordination up front.
Unkindly, you could say that the Micro-battles System is Agile with a layer of bureaucratic junk on top. Positively, you could say that micro-battles aim at transforming the organization from the outset, and they force senior management to be a major part of the journey from the very start.
An Engine 2 approach can be less distracting and can lean on either Agile experimentation or micro-battles. It can offer a friendlier environment for experimentation, with less risk of tissue rejection from the traditional business. It can also create examples of success that you then bring back to the core. But let’s remember that we’re the folks who also wrote Profit from the Core, which argued that you have to push your core to full potential. As we said above, we believe that the ultimate goal has to be taking the lessons from your Engine 2 journey and applying them to Engine 1, not to innovate in isolation.
Finally, massive complexity reduction is really an option for those companies that (a) don’t have the time to address a journey of learning or (b) know that the current organization isn’t equipped to embark on the journey. Before the company can be transformed with a personal training program, in other words, it will need to undergo radical surgery.
So with all of the above in mind—and at the risk of gross oversimplification—we want to offer some key questions to help guide your thinking as you sort through these alternatives:
- Do we have the time and resources to start with small steps? If yes, you have options. If no, then you need to think about more radical change as a first step. Most likely, this will include significant cost and complexity reduction to give you breathing room for further change.
- Do we need to start by changing senior leadership behaviors and focusing on our most important strategic initiatives? If this is critical to you, then the micro-battle approach is most likely the right one. If you are less interested in these objectives right away and more concerned about accelerating innovation, then Agile experimentation might be the right fit. Even with Agile experimentation, you need the senior leadership team on board, and you should target the effort on innovation that is critical strategically. But, unlike micro-battles, Agile experimentation programs don’t commit to dominating the senior leadership agenda up front.
- Assuming now you have made a clear choice of micro-battles or Agile experimentation, you still have a final decision: Do we focus first on Engine 1 (our core) or do we want to focus our early efforts on Engine 2? You can launch either approach in Engine 1 or Engine 2. If Engine 1 is overwhelmed with an existing transformation program, you might decide to emphasize Engine 2 for a while to give the Engine 1 team time to free up its agenda. Or you might find that it is easier to set up Agile ways of working initially in Engine 2 and you’d rather get some wins under your belt before shifting back to Engine 1.
As noted, this understates the issues involved in choosing the right alternative. But these questions are a useful starting place for all management teams working through this decision. For those of you who have chosen the micro-battles route, we’ve designed this blog to walk you through the major elements of launching a portfolio of battles. Our Introducing the Bain Micro-battles System post is the good place to start.