A better way to change: how small teams drive big transformations

Companies pour millions into transformation projects, only to end up with a frustrated workforce and no real change. Why? Because many go down the road of the big-bang-change-everything-at-once approach to rework the product development processes and practices. This is risky, rarely works, leads to frustration, and wastes so much money. The better – and easier – way to change is to incrementally enable individual teams to introduce new ways of working and let this diffuse through the organization. This may take longer but is a more sustainable approach to actually change product development culture. 

Today, I will explain the default way companies try to introduce new product development approaches and explore why that is the case. Then, I will make the case why an iterative approach is preferable and share how to execute this approach. 

 

The default way of introducing new ways of working (that rarely works)

At one point or another almost all companies attempt to change the way they develop products. Whether it’s trying to change to an agile way of working, scaling Scrum, implementing the product operating model, introducing Basecamp’s Shape Up, or whatever else may be en vogue, companies typically try to introduce these changes for large parts of the organization all at once. 

The steps are often as follows: 

1. Hire consultants
2. Conduct countless training sessions
3. Execute a complete reorganization and introduce new processes for everyone
4. People get frustrated
5. Productivity drops
6. Hire more consultants
7. Do more trainings
8. Watch everything become even worse
9. Go back to the initial way of working 

It never works and so much money is wasted. The money is wasted directly by paying expensive consultants. More importantly, though, money is wasted by reducing productivity. Finally, the organization incurs tremendous opportunity cost (people always forget about this) because everyone focuses on internal struggles as opposed to, you know, actually developing products that customers pay money for. 

Why companies chose the big-bang approach

Most change initiatives fail. We all know that. A big-bang approach is expensive and the company will only know in the very end if it was successful. It’s risky and expensive. Still, many smart people apply the steps from above in attempting to improve product development. Why is that? 

I think there are a few things at work here. 

One, introducing prescribed processes and changing the org chart seems like a straightforward solution. On the surface, if successful – a BIG if – the big-bang change should quickly lead to improvements. In reality, it takes much longer and is much harder to actually change the culture. Exceptional leadership is needed for that. 

Two, “nobody gets fired for buying IBM”. What’s at the heart of this well known phrase is true here as well: risk aversion. It’s much more risky for one’s reputation to try an unconventional approach. Instead, many simply do what other companies do and introduce a more or less established framework. If it doesn’t work, it’s much easier to deflect blame.  

Three, the above leads to a paradoxical situation where humans tend to stop thinking and simultaneously overthink it. They stop thinking in the sense that many just apply what the consultants recommend. At the same time they overthink it by using a highly complex approach instead of going with something very simple and small.

Why an iterative approach is better 

Starting simple and small and changing one small step at a time is by far the better approach. The parallels between organizational change and product development itself are striking. 

The big-bang approach rarely works in both cases. In product development, you don’t give yourself a chance to learn and correct course on the way to the goal. Instead you find out at the very end if people will buy what you build, and often waste a lot of money doing so. 

The best way to develop products is iteratively getting product improvements out in front of customers as often as possible. That way you can quickly see if you are on the right track and adapt the product if necessary. The same is true for introducing a new way of developing products. 

Doing it little by little and adapting based on the things you learn dramatically reduces risk and costs. If a small change fails, so be it. You didn’t spend a lot of time and resources. Moreover, you can learn along the way, course correct, and adapt the solution to your situation, instead of introducing the one-size-fits-all solution that often causes a huge mess.

Creating “bubbles” that experiment with new ways of developing is the way to go

Going iteratively in organizational change means starting with a single team. When I was part of a group trying to introduce agile product development in a large, bureaucratic automotive organization, we used the picture of creating “agile bubbles”.

A bubble is a single team that tries a new way of building products shielded from the rest of the organization. If this single team reaches some level of success, others organically want to also try the new way of working. This creates additional bubbles slowly but sustainably changing the entire organization.

The specific steps are as follows: 

1. Empower the team to solve a single problem
2. Make the team as independent as possible
3. Connect the team directly with customers and/or users 
4. Provide support whenever it’s requested
5. Place the team on a stage
6. Create and nurture additional bubbles

Giving the team a single problem means there automatically is focus. Choosing a problem instead of a specific feature means the team is empowered to come up with the solution itslef, leading to more motivation, ownership, and better results.

Removing dependencies to others means the team can move fast. It can frequently release small product increments and learn.

Getting as close to users is one of the keys to successful product development. It greatly increases the rate of learning and thus the chances for success. There is nothing more insightful than seeing a user interact with your product. So many ideas come out of that. 

The start will still be bumpy. The team will often need to re-learn how to develop. The members will need to figure out how to collaborate. This will not necessarily be easy. Thus it’s important to provide management support whenever it’s necessary, also to protect the team from the established organization. 

Once first results come in, it’s critical to place the “bubble” team on a stage. This starts the diffusion process. It can be a literal stage (e.g. town hall meetings) or any manner of digital stages (e.g. internal blog/newsletter). The important thing is to inform the rest of the company what is going on. Ideally the team presents itself. And it’s important to be honest about the progress. People will know if the team is just window dressing. So, the team should honestly explain why they are doing what they are doing, how it’s going, what they are struggling with, and what they have accomplished.

This will undoubtedly lead to other teams becoming curious and requesting to also try out the new approach. These are the next bubbles and you should nurture these early adopters in the same way as the first team. Over time, the organization will be in a virtuous cycle and more and more teams will organically adopt the new way of working.

Iterative approaches are better in product development and organizational change

What is true in product development is true in changing an organization’s way of working as well. Big-bang approaches are risky. But many companies use them, even though they are likely to fail and waste a lot of money along the way. 

The better approach is to move iteratively forward. Start with a single team. Give it a problem to solve and access to customers. Nurture this team and put it on a stage. This will start a diffusion process to other teams and over time, the entire organization will adopt the new way of working.   

So before hiring an army of consultants, start with one small experiment. Empower a single team, create a bubble, and let the results speak for themselves.