Over the past five years at ThoughtWorks, we’ve worked with technologists, people leaders, and executives to help them transform their organisations to become more responsive.
Our focus has been on helping to change the way teams behave, and the way in which organisations align their work to deliver quality products that bring joy to customers. Along the way, we've worked with people who were convinced of the need to change, and those who fought to the bitter end to resist it.
In the hope of learning how to better implement change that sticks, we travelled to Japan to talk with the experts who've put change at the heart of their organisation since its inception – the Toyota Group. The messages we heard consistently from Toyota’s leaders past and present, on how to successfully implement change were clear and simple - make information visible and create the right environment.
Here, we’ve applied their principles to some of our own client examples, to show where we’ve seen the benefits of this approach.
We found this very true from our own experience, which saw us demonstrate the value of making things visible with our own clients.
For example, at a multi-national financial services client, where one of our deliverables was to create a Lean PMO (Portfolio Management Office), we discovered that no-one had a holistic view of all the in-flight initiatives. We took the data out of the ‘information refrigerator’ that was their project tracking tool and made it clearly visible to all.
We put each project on a single card, and placed them on a wall in rows (by which department was working on it) and by columns (according to the due date in the project tracking tool). The number of projects in flight was the length of a corridor from floor to ceiling!
Many people walked by and commented on what they were now able to see – 'We have 4 projects from different teams trying to do the same thing!' or 'key resource X is working on 8 projects at once, I can see why none of them are getting done and he never has any time', down to 'more than 20 projects are 3 months past their due date, and we have way too much work in flight.'
In many instances, those walking by discovered that the information shown was not correct, and they updated it on the spot with a post-it and sharpie. These errors would have stayed hidden had the work not been displayed in a clearly visible location.
At every Japanese company we visited they began with their company’s purpose and vision. It was clearly visible as we entered the premises, and at the start of every powerpoint deck and presentation. In Australia, we were continually surprised by how few people knew what their company’s/division’s strategy is, and how few executives consistently communicated it.
At this client, part of the evolution of the Lean PMO was to understand the weighting of the work that was/wasn’t strategically aligned. We took the strategy and created a second version of the information on the wall, with all projects now tagged, showing which were and were not strategically aligned.
This led to difficult but important conversations about whether teams should continue working on projects that weren't strategically aligned, stopping some projects, so that capacity could be freed up to deliver higher-value and more strategic work, which had previously been bogged down due to limited capacity, and at times even asking if that fifth strategic objective was essential even when there were no active projects aligned to it.
We saw executives sit opposite each other in meeting rooms, enthusiastically trying to share their point and perspective, without awareness and understanding of the holistic picture. In one instance we had Manager X’s team struggling with three simultaneous requests, each the highest priority for the requestor, so we took them to the wall showing all the work and initiated a conversation. Manager X led the team which was in progress with a project for Executive A.
By making the information physical, tangible and visible, those same people who were in conflict, could now stand together facing the problem. The result? They discussed, collaborated and made difficult decisions together. In short,
So how does one best implement these lessons? And, how do you help create the right environment for change to occur? A word of warning here, even the experts say with a drawn out sigh, “this is not an easy task.”
At Toyota, managers start by observing and understanding the problem they want to solve. They take time and look intently at what is happening. They go to the ‘Gemba’ - the place where the value is being created and observe.
This means looking at the technology and tools, processes, place and lastly, the roles. Japanese leaders believe it’s very easy to start with the roles involved and blame the people, but most often it is the tools and processes that drive behaviours.
Managers seek out the root causes and create solutions together with the people who will be affected. It is amazing to see the ideas and suggestions that people affected create when the process is inclusive. We were told that at Toyota in 2017 alone, on average, every team member suggested over 8 improvements.
In addition, managers have the responsibility and capacity to clear small blockages or unexpected issues that would hinder the solution. They need to test the solution first; it’s a test of small change on a small scale. If it goes wrong, it’s easy to reverse, so the risk is low. Managers should not delegate a solution they are unwilling to experience themselves.
Once they have a solution that is proven to be more beneficial than the current state, they roll-out, scale, and embed the new solution as quickly as possible. As the solution was co-created and there is proof it works, this can occur quickly.
One Japanese leader told us that Managers often overlook kaizen when trying to make a big change, but it is the cumulation of all the small changes that achieves the big change.
Our approach when helping organisations change is to use Hypothesis-Driven Change, an approach that helps test solutions for organisational problems before rolling them out at scale.
We used this approcah at one of our clients to change their solution delivery lifecycle. The client was a large bank with more than 3,000 people working on projects that required technology change, and they wanted to implement an agile delivery process. The bank had previously tried a big-bang approach which was met with resistance from teams and individuals. Moreover, the bank executives wanted to see tangible results quickly rather than 'just theory, meetings, and PowerPoint decks.'
Starting small, we found an Alpha team and picked one problem. The problem we chose to solve was work being horizontally sliced across the technical stack, meaning that all slices had to be delivered together before any value could be realised. To solve this we co-created a new feature decomposition process with the team on one initiative.
We then refined the solution delivery lifecycle process based on what we learnt. Due to the size of the organisation we tested the process further with a Beta group of five more teams. We learnt that the process didn’t work in all use-cases and we needed to accommodate teams of different shapes. Again, we updated our solution delivery lifecycle process based on what we learnt.
We soon found that other teams who were not involved in Alpha or Beta were asking to start using the new approach, so adoption became a pull model. This triggered a move to general adoption of the co-created process and we moved to experimenting with other areas of the delivery process that also needed to change.
Taking this approach allowed us to:
Our focus has been on helping to change the way teams behave, and the way in which organisations align their work to deliver quality products that bring joy to customers. Along the way, we've worked with people who were convinced of the need to change, and those who fought to the bitter end to resist it.
In the hope of learning how to better implement change that sticks, we travelled to Japan to talk with the experts who've put change at the heart of their organisation since its inception – the Toyota Group. The messages we heard consistently from Toyota’s leaders past and present, on how to successfully implement change were clear and simple - make information visible and create the right environment.
Here, we’ve applied their principles to some of our own client examples, to show where we’ve seen the benefits of this approach.
#1 Make information visible
One of the senior leaders we met in Japan summed it up perfectly:If a manager talks no one listens, you have to make things visible so everyone understands and is aware of what is important.
We found this very true from our own experience, which saw us demonstrate the value of making things visible with our own clients.
For example, at a multi-national financial services client, where one of our deliverables was to create a Lean PMO (Portfolio Management Office), we discovered that no-one had a holistic view of all the in-flight initiatives. We took the data out of the ‘information refrigerator’ that was their project tracking tool and made it clearly visible to all.
We put each project on a single card, and placed them on a wall in rows (by which department was working on it) and by columns (according to the due date in the project tracking tool). The number of projects in flight was the length of a corridor from floor to ceiling!
Many people walked by and commented on what they were now able to see – 'We have 4 projects from different teams trying to do the same thing!' or 'key resource X is working on 8 projects at once, I can see why none of them are getting done and he never has any time', down to 'more than 20 projects are 3 months past their due date, and we have way too much work in flight.'
In many instances, those walking by discovered that the information shown was not correct, and they updated it on the spot with a post-it and sharpie. These errors would have stayed hidden had the work not been displayed in a clearly visible location.
This visibility led to conversations about which projects were valuable and aligned to the organisation’s strategy which, in turn, led to further conversations indicating a lack of clarity around the actual strategy.
At every Japanese company we visited they began with their company’s purpose and vision. It was clearly visible as we entered the premises, and at the start of every powerpoint deck and presentation. In Australia, we were continually surprised by how few people knew what their company’s/division’s strategy is, and how few executives consistently communicated it.
At this client, part of the evolution of the Lean PMO was to understand the weighting of the work that was/wasn’t strategically aligned. We took the strategy and created a second version of the information on the wall, with all projects now tagged, showing which were and were not strategically aligned.
This led to difficult but important conversations about whether teams should continue working on projects that weren't strategically aligned, stopping some projects, so that capacity could be freed up to deliver higher-value and more strategic work, which had previously been bogged down due to limited capacity, and at times even asking if that fifth strategic objective was essential even when there were no active projects aligned to it.
We saw executives sit opposite each other in meeting rooms, enthusiastically trying to share their point and perspective, without awareness and understanding of the holistic picture. In one instance we had Manager X’s team struggling with three simultaneous requests, each the highest priority for the requestor, so we took them to the wall showing all the work and initiated a conversation. Manager X led the team which was in progress with a project for Executive A.
- Executive A’s project had delivered 80% of the value with only 20% of the lowest priority features remaining to be completed (another 2 months work)
- Executive B’s project was expected to save his team of 20 people half a day per month
- Executive C’s project was expected to deliver a $1m increase in revenue per annum for her product
By making the information physical, tangible and visible, those same people who were in conflict, could now stand together facing the problem. The result? They discussed, collaborated and made difficult decisions together. In short,
You need to see where you are, to be able to change.
Call to action:
- Where are you now?
- What do you need to make clearly visible?
- Does everyone know what your strategic goals are and why?
- Who do you need to invite to see, so that together you can make the best decisions?
#2 Create the right environment
In our experience the major blockers to implementing change in large organisations are often the presence of a blame culture, organisational inertia and fear of failure. Teams and leaders at all levels, are sometimes so afraid to change that they actively avoid becoming involved in changing the organisation, or simply pay lip-service to those leading the change whilst following the same old practices and processes. When asked how to tackle these issues, the Japanese leaders we spoke to had some interesting lessons to share.- Make the change small, even if the overall change you want to make is big
- If you want something to change, do it yourself first before asking others to do it
- Co-create the solution
- Implement validated solutions quickly
So how does one best implement these lessons? And, how do you help create the right environment for change to occur? A word of warning here, even the experts say with a drawn out sigh, “this is not an easy task.”
What we heard consistently from leaders in Japan was they practice ‘Kaizen’ - small continuous improvement that never stops - and respect for people.
At Toyota, managers start by observing and understanding the problem they want to solve. They take time and look intently at what is happening. They go to the ‘Gemba’ - the place where the value is being created and observe.
This means looking at the technology and tools, processes, place and lastly, the roles. Japanese leaders believe it’s very easy to start with the roles involved and blame the people, but most often it is the tools and processes that drive behaviours.
Managers seek out the root causes and create solutions together with the people who will be affected. It is amazing to see the ideas and suggestions that people affected create when the process is inclusive. We were told that at Toyota in 2017 alone, on average, every team member suggested over 8 improvements.
In addition, managers have the responsibility and capacity to clear small blockages or unexpected issues that would hinder the solution. They need to test the solution first; it’s a test of small change on a small scale. If it goes wrong, it’s easy to reverse, so the risk is low. Managers should not delegate a solution they are unwilling to experience themselves.
Once they have a solution that is proven to be more beneficial than the current state, they roll-out, scale, and embed the new solution as quickly as possible. As the solution was co-created and there is proof it works, this can occur quickly.
One Japanese leader told us that Managers often overlook kaizen when trying to make a big change, but it is the cumulation of all the small changes that achieves the big change.
Our approach when helping organisations change is to use Hypothesis-Driven Change, an approach that helps test solutions for organisational problems before rolling them out at scale.
We used this approcah at one of our clients to change their solution delivery lifecycle. The client was a large bank with more than 3,000 people working on projects that required technology change, and they wanted to implement an agile delivery process. The bank had previously tried a big-bang approach which was met with resistance from teams and individuals. Moreover, the bank executives wanted to see tangible results quickly rather than 'just theory, meetings, and PowerPoint decks.'
Starting small, we found an Alpha team and picked one problem. The problem we chose to solve was work being horizontally sliced across the technical stack, meaning that all slices had to be delivered together before any value could be realised. To solve this we co-created a new feature decomposition process with the team on one initiative.
By co-creating the new process, we gained a ton of insights, including new behaviours that were needed to make the process successful.
We then refined the solution delivery lifecycle process based on what we learnt. Due to the size of the organisation we tested the process further with a Beta group of five more teams. We learnt that the process didn’t work in all use-cases and we needed to accommodate teams of different shapes. Again, we updated our solution delivery lifecycle process based on what we learnt.
We soon found that other teams who were not involved in Alpha or Beta were asking to start using the new approach, so adoption became a pull model. This triggered a move to general adoption of the co-created process and we moved to experimenting with other areas of the delivery process that also needed to change.
Taking this approach allowed us to:
- Try new things with small, low-risk experiments
- Start with the existing processes and quickly begin making improvements
- Identify champions along the way who could help adoption of the new process
- Can you make people within your area feel safe to implement change?
- Can you make the change small and incremental?
- Are there any colleagues you can co-create the solution with?
