Surface Level Solutions
Why surface-level solutions to a problem are not a good investment and how you can use the iceberg model to dig deep until you find the root cause.
A company, at its fundamental level, is a collaboration of people working for the same cause. In any collaboration, there are always difficulties and obstacles that need to be resolved and tackled. The longer you drag your problems behind you, the slower you will move, and the more resources you will burn.
Many times I have experienced teams struggling to find a solution to their recurring collaboration problems. What I’ve seen so far is that it is quite easy to find a surface-level solution to a problem, but in that case, only a very short-term improvement can be seen. As soon as one or two weeks pass by, someone from the team gets replaced, or they start working on a new task, and the same problems resurface.
Long-lasting change has to be approached with a unique mindset. When you provide a surface-level solution to a problem, you’re just treating the symptom, not the cause. That is what I would like to talk about in the post below.
Empathy is key to understand the cause
Empathy is an extremely overused word, especially in the design industry, to the point where it has somewhat lost its meaning. What it originally meant is the ability to put yourself in someone else's position and feel what they are feeling. When you are trying to help an organization resolve a problem, there is a huge need for empathy from everyone’s point of view. That is one of the key ingredients to really trigger any long-lasting change. Partially, that is why it is so hard to change bad routines and underlying structures.
Take hierarchies into consideration
Whether we like it or not, hierarchy is very important and is here to stay. When it comes to most organizations, hierarchy is something that needs to be taken into consideration when trying to induce change. If someone from the higher hierarchical level is not able to empathize with the problems of the rest of the team from the lower levels, it will be almost impossible to accomplish any meaningful long-term development.
Short-term and surface-level changes can be easily achieved, but that is not the goal of a systems thinker or someone who is trying to build a long-lasting design system.
Changing the way of how an organisation work
It is very difficult to identify the real root cause and provide a proper solution, partially because most problems are underneath the surface and can’t be seen at first glance. If you want to accomplish any real change, you have to dig deep—really understand how people in that organization think, what are the recurring patterns, and what are the different mental models that people have.
Below you can see a famous model that is frequently shown when system thinking comes up. Let me tell you about an example that I encountered when helping companies change the way they work and save money: The members of the design and development team encountered a very visible problem: They didn’t have documentation, and there was very little structure to their work overall. Valuable time was wasted due to work that had to be redone and information that had to be re-shared in preventable meetings.
The obvious answer would be to introduce a new tool that helps manage tasks and documentation. Also, maybe the company should introduce weekly or monthly recurring time slots where team members would have dedicated time to keep their materials clean, up to date, and in sync with each other.
I think this solution would have solved most of the problems that the team struggled with, but only for a week or so—if I’m optimistic. After that, every problem mentioned above would resurface.
Why do the same problems resurface?
First, you have to really understand the core reason behind having almost no documentation and having disorganized work materials. If you treat the surface-level symptom—not the cause—the problem will reappear shortly. The iceberg model provides a framework for identifying the root cause. It is a very simple model that can be shown to team members or even stakeholders when trying to achieve meaningful change and get everyone on board and involved.
In a collaboration, you have some visible events that anyone can see and experience. If we go with our gut reaction, we can make an immediate response and provide a surface-level solution. If we don’t have documentation, then introduce a new tool that helps with creating documentation.
What happened? We reacted to a surface-level experience with a short-term solution. After a couple of days or weeks, what we’ll see is that the problem we tried to solve reappeared again. We have to dig deeper and find out the real reason behind that surface-level event. In the iceberg model, there are four main levels:
First Level: Event (Results, Outcomes)
Question: What is happening, what have people experienced?
Second Level: Pattern (Processes, Practices, Flows)
Question: What has been happening over time?
Third Level: Structure (Relationships, Dependencies)
Question: What is influencing the behaviours or trends?
Fourth Level: Mental Model (Mindset, Beliefs, Values)
Question: What values and beliefs drives the behaviour?
After identifying the event that happened, we have to examine the patterns. How often does this event happen? How many times has the team encountered the problem? What is happening before and after this event? We might be able to see patterns if we examine the process where the event took place. Then we have to reveal the underlying structure and ask: What is the core influence behind the trends that are happening? Why is it happening this way? What is the relationship between the processes? If we are able to identify the structure, we can arrive at the mental model level. What values or beliefs drive the behavior that produces the event?
Using the Iceberg model:
What was the event?
No documentation & chaos across many platforms, long onboarding processes due to not having structured materials, team members doing repeated tasks.
What was the pattern?
Designers and developers are developing features very rapidly and releasing as soon as possible without producing documentation or cleaning up code/design.
What was the underlying structure?
There was a directive from the business team to roll out features as soon as possible. The stakeholders did not see a point in having documentation since they don’t have time to read it anyway—thus, the documentation writing and syncing would just cost the company lots of money with little or no return on investment.
What was the mental model?
The business team has low design maturity and no visibility on the development process. They think that more frequent releases are a clear indication of the performance of the design/development team. Since no time is wasted on documentation, the overall cost is lower. It’s a win-win for everyone.
In reality, the money saved by not documenting already had a huge backlash since developers and designers spent significantly more time creating the next feature than they would have with documentation.
A totally logical and understandable need from the business team:
We need to release faster and cut out the documentation to lower costs.
What was happening in reality:
The time spent developing a new feature and thus the overall cost increased.
Now you might be able to see that without including the whole team and really digging deep to the core, we wouldn’t be able to identify the mental model that caused the problem in the first place. Since the business team has the final say in everything, introducing a documentation tool or a dedicated time slot without their involvement wouldn’t work for long.
But if you can organize a quick workshop to show the return on investment of the documentation, that can be a good start. The business team not only has to support but also use the documentation so they wouldn’t jeopardise the team effort to keep the important information in a documented format. Using the documentations would sync the team, lower development costs, provide a visible status for the business, and help when new team members need onboarding. This is just a sneak peak into what the iceberg model can do, and how to solve problems like we mentioned above, but we’ll share more information on the actual steps that you can take with your team.
Are you interested in working together or finding out the root cause of your problems? Are you looking for designers to help you with product design?
Contact us at: contact@adrem.world and have a chat!