We build what we think. We structure thinking through communication, and then we craft it into something actionable. Communication is how we think together. The structure and flow of information, in our own minds, with other people and as organizations, creates the sociotechnical systems, the integration of people and technology, that are the core of our work.
Nice callback to Conway’s Law. We build systems that mimic the communication in the organisation… but software is becoming too complex and systems thinking seems to be a solution.
The author suggests our default mode of thinking is linear, the “if this, then that” causal relationships, and we expect software to act predictably. We break the system into parts and manage complexity by dividing the systems with modularity.
We try to divide systems into little boxes, but the world is dynamic and always changing, which leads to the boxes becoming outdated “legacy” systems as soon as they are released because they don’t match the real world.
In contrast, systems thinking involves observing events or data to identify underlying patterns, and surface or build those underlying structures that drive the events and patterns in the system. So instead of a top-down approach of using software architecture to design and plan a perfect system, we let the underlying structures emerge from the flow of information in the system…
I think it would be important to consider again that this involves the humans that work with the system, you could design a perfect helpdesk system but the team you’re working with might prefer to handle support tickets over the phone, while another organization might prefer more technical emails where everything can be documented correctly. When working with systems, it might not just be about letting the underlying structures in the data emerge but how the team also interacts with the systems.
In short, there is no universal solution to our problems.
A perfect system also doesn’t take into account that humans can make mistakes, forget to complete things, write down duplicate information, need reminders, or just need encouragement because they don’t care… or that teams within an organisation might not collaborate well.
There is no magic bullet. Even if there was a magic bullet, you’d be standing there holding it, and nobody would believe you. People don’t see magic; they see what they expect to see. You need to show people, over time, how the magic works.
When we want to change a system, we should look for “leverage points” where small fixes can have big impacts. This helps if you have blocking issues between two teams, or you need to convince others that systems thinking is a good approach to solving problems – by resolving small issues that cause large delays you can maximize your efforts.
I think in the age of AI it’s also great how flexible we can become with software, we can create and destroy systems with a few prompts, and modernise legacy software in a day. This allows the code to be expendable and let us focus on the systems between things. If the code isn’t working… just throw it away and rebuild the system to be more efficient.
This makes us more agile because we can quickly learn and adapt.
Systems thinking requires us to be detectives and look underneath the surface, like an iceberg that has much more depth below the water: we need to look deeper into the structure, how patterns or problems are related, and even limiting beliefs or mental models the users interacting with the system might have.
And remember that since you are dealing with humans, it’s important not to blame anyone.
When analysing systems it’s important to distinguish between signals and noise, and remember that our own biases might introduce biases when searching for signals or solutions to a problem.
When trying to determine if a new solution could work, make a mockup or prototype first and get feedback!
It’s good to see the author devoted a whole chapter to dealing with emotional reactions when working with teams.
When analysing the scope of problems, it’s also good to use systematic reasoning. In this way, instead of just asking what happened, why, and how long will it take to fix? We ask questions like:
- How do we know it’s a problem?
- What is the impact?
- A problem for whom?
- How does this problem compare to other challenges we are currently facing?
- What has been happening over time?
Also keep in mind that when discussing abstract topics with others, to make sure that everyone has a similar mental map of what is actually happening.
While doing systemic reasoning it’s important to ensure that the reasoning is:
- Reliable: is the reasoning truthful
- Relevant: for the current problem
- Cohesive: the reasons support each other to make a convincing whole
- Cogent: clear and understandable
Managers are often taught that “giving feedback” means criticizing performance or improving compliance. While there are circumstances wherein this type of feedback might be helpful, it is not systemic reasoning.
To understand if the systems are functioning well you need feedback from the system. The feedback loop is a mechanism for gaining useful feedback about the state of the system, from the system. These loops enable learning and knowledge to flow. This is something that was discussed at length during my master’s in entrepreneurship… the more you understand about the current state of the company at every moment, the more you can fine-tune and adjust the engine and ensure you are heading in the right direction. The more you can learn from every moment the more you can continually improve at each stage.
Without feedback you have no way of understanding if the changes are meaningful.
When people in an organization can’t communicate well, they build software parts that don’t communicate well. They constantly try to change the system but without changing the way they communicate. That is a recipe for disaster.
The feedback loop also helps you build systems that are more resilient and easier to adapt to change.
The next important part of building feedback loops is to make sure you get the relevant feedback you need, look for signals not noise. If you can determine what feedback you need first – you can find the right people to ask.
If someone you rely on for feedback only gives you critical feedback, no matter what you improve, that person’s feedback is inherently unreliable regardless of their level of expertise. They can’t, as they say, see the forest for the trees. Find someone who can.
In addition to systems thinking, we have patterns thinking which is about discerning how relationships produce effects. We look for patterns in the data, which is repeating events, that might even evolve over time. The example the author gives is that if you have a critical bug once a year, you can diagnose it, fix it and move on… that is just a single event. If you have 30 critical bugs in a year, everyone starts to feel under pressure, the management team is putting pressure on the developers, the developers are stressed out and introducing more bugs into the system, the good developers are leaving the organisation which is causing code quality to go down, which continues to increase the amount of critical failures. The patterns emerge from these events over time, and can become self-reinforcing.
The term structures is also used to identify things that hold patterns in place, this might be the hierarchy of the company, the software delivery methods, project management processes, etc.
Systems thinking work is rarely done by one person. You can’t possibly understand circumstances from multiple perspectives without…multiple perspectives.
In systems thinking, models are used to:
- Enable conversations
- Frame questions and explore answers
- Explore relationships with other models
- Find leverage points
Creating models with others helps build engagement, respect, cooperation and the willingness to change.
In some ways systems thinking is similar to design thinking, which follows the steps of:
- Exploration: conduct research and empathize with users
- Experimentation: create models and understand problem
- Explanation: define problem
- Execution: implement change, listen to feedback loop, and repeat
There is no sense in talking about the solution before we agree on the problem, and no sense talking about the implementation steps before we agree on the solution. – Efrat Goldratt-Ashlag
The author ends the book saying that you don’t need to be an expert in technology to be a systems thinker (unlike a solutions architect) rather you need to be an expert in building relationships with other people as experts. The key to good systems is to facilitate good communication, have effective knowledge flow through the system, detect signals in the noise, etc.