In times of change, changing ingrained beliefs often turns out to be the most complicated thing to do. Just as elephants carry memories for generations, so do organisations.
Companies have their own unwritten rules and beliefs. To name a few: “Here you are a hero when you put out fires with decisiveness; proactively prevent- ing problems produces less appreciation.” Or: “sales is in the lead; everything else costs money.” Such unwritten laws that live below the surface derail many organisational change initiatives. Beliefs that have often been built up over the years and reaffirmed repeatedly are stubborn. How do you break through that?
The current system of paradigms, beliefs and unwritten rules in an organi- sation is tough to change. At the same time, it is one of the most important topics to address, as it is the reason for the failure of many change initiatives. Therefore, examining which unwritten rules and beliefs apply is an essential first step. Once you have mapped them out, you can make them transparent. The iceberg tool helps to provide insights into unwritten rules and how to discuss them proactively. The practical example illustrates how you can im- plement a set of interventions.
The iceberg tool helps to uncover the underlying reasons for specific be- haviours observed in an individual, team or organisation. With this tool, you describe which behaviours exist, which underlying beliefs feed them, which behaviours you want to see, and which beliefs are fundamental to the organi- sation’s values. This way, you clarify which beliefs you want to keep and which you want to let go of. I use the iceberg tool in conversations with individuals and groups to discuss beliefs and behaviour.
These conversations tend to be surprising and illuminating because everyone encounters behaviour and underlying beliefs in the organisation, but they rarely have structured talks about them.
In a technical organisation, the wheel is constantly being reinvented. The organisation’s learning capabilities are so low that it gradually develops a technological disadvantage compared to competitors. In addition, the repetition of moves leads to costly mistakes. The directorowner has already tried multiple fixes, including technical training and breakfast knowledge exchange sessions, but the problem seems to run deeper.
She asks an organisational consultant to help her. The consultant first has conversations to determine which beliefs and ways of working impede or discourage learning from each other. There appear to be three core beliefs.
Firstly, it is normal to start a new initiative or project without building on knowledge already amassed inside or outside the organisation. People can pioneer and create with out any form of framework.
Secondly, it is considered foolish to share your mistakes in this organisation because you will then be ridiculed for doing so. Senior management also participates in this.
Thirdly, the process to evaluate an action, project or innovation is often not included. It usually is considered – falsely – a waste of time.
When these observations are shared with the management team, they are instantly rec ognised. But how do you turn these three beliefs and behaviours around? The manage ment team, together with the consultant, decide to employ three interventions that have proven their value in other industries; sharing knowledge as strategy consultants do, sharing errors as tech firms do, and performing project evaluation as the military does. Like strategy consultants, from now on, no assignment or project can be started with out calling colleagues or external parties who have previously dealt with this. These colleagues respond to a request for knowledge within 24 hours. By making this form of knowledgesharing mandatory in advance, it becomes normal for every new initiative to build on the collective organisational understanding instead of the knowledge and experience of one individual. Compliance with this step is monitored.
Like tech firms, from now on, a “screwup event” is organised once every three weeks in which the directorowner goes first, followed by colleagues in senior management, to share what mistakes they have made and what they learned from them. They share these lessons with the rest of the organisation. Following the motto “fail fast and fail forward”, these events help to encourage sharing mistakes, and it becomes “cool” if you dare to share mistakes instead of it branding you a “loser”.
The underlying idea is that mistakes are allowed if you limit the impact and learn from them.
Like the military, a new process step is built: AfterAction Reviews. These reviews have a standard format and become a permanent part of everyday work; from now on, an Af terAction Review takes place after every assignment or project. Managers are trained in this way of working; subsequently, the review quality is checked randomly, and emerg ing insights are implemented. This way, it gradually becomes normal to take time to look back, resulting in less repetition of mistakes.
The directorowner looks back with great satisfaction on these interventions. Step by step, she sees her organisation growing in its capacity to learn.
Tip for change leader
Do you have a good idea of the beliefs under the iceberg that guide your behaviour? Which beliefs do you want to let go of, and which do you want to keep? Analyse those and adjust your behaviour.
Tip for change enabler
By performing the iceberg analysis with several focus groups, you calibrate. By then sharing the summary of these discussions with executives, you hold up a mirror to them. That mirror demonstrates the undercurrents and clarifies how to act to counter ineffec tive behavioural patterns.
Breaking through beliefs that have been ingrained for years requires very targeted interventions and takes patience. The actual change will feel uncom- fortable. Making the unwritten rules transparent in advance is a necessary condition to be able to intervene in a targeted manner. The iceberg tool helps with that. If you want to adjust an entire company culture, that requires more. Challenge 37 addresses this.