A multi-million dollar chip production line is halted, but it’s not clear where the problem is coming from. An independent consulting engineer is called in. She walks all around the production floor looking at the screens, the indicators, the dials, the cables, the mousetraps. She examines some log files and makes a Google search. Then she edits two lines in a particular configuration file, and all is well again.
The plant manager is extremely happy until he receives her invoice: €10,000. He emails her to ask for an explanation – how can 20 minutes of work merit such a large sum? The reply is a rework of the invoice, with more detail:
Editing 2 lines in a configuration file: €100
Knowing which lines to edit: €9,900
This is a variant of an old story (originally from Eric Berne in the field of Transactional Analysis) that illustrates a systemic approach to problem solving. It contrasts to the analytical, divide and conquer approach, which would have required that our consultant check each component of the production system in isolation to find the one that was ‘at fault’. If there is no obvious individual component failure, then it can be far more effective to assume that every component is functional and to consider the system as a whole. Perhaps it’s the interaction between two or more components that’s causing the issue?
The story also highlights the value of anyone with an understanding of the dynamics of a complex system!
Of course, many complex systems consist not only of machines, but also of people. By definition, they are composed of interacting components with both feedforward and feedback elements, the components themselves often being non-linear and time-varying. It only requires a small number of such components and interconnections to make a complex system – three humans is quite enough! – whereas complicated systems such as digital integrated circuits may contain billions of transistors and still behave predictably.
The need for engineers to master and balance the analytical and systemic approaches is crucial to effective problem solving, decision making and relationship management, and it is becoming ever more so.
Consider recent changes in software design practices. It is now rare for a programming team to work through a process of specification, design, implementation, test/debug then review. Instead, most teams use an agile process where objectives are rethought every few weeks and rapid feedback is key to progress. Furthermore, this trend is not limited to software, as rapid prototyping has also become a mainstream practice for hardware design.
In other words, we are tending away from relatively linear processes (specification, design, …), where each part is considered to be independent, to non-linear, recursiveones. Of course, this change has not happened because we are cleverer than our predecessors. Rather, it’s been caused by the evolution of our environment: market demands combined with the tools and technology at our disposal.
Engineers who prefer not to go with way of the dodo therefore need to get comfortable with the systemic approach … and this may run counter to their inclinations and training.
The rule is: the more complex the problem, the more likely that some kind of systemic thinking will be needed. And, if it is, then a couple of conceptually dramatic changes are necessary.
Crucially, in a complex (rather than just complicated) system, the search for a root cause may be a waste of time. There is no beginning or end to a feedback chain, any more than there is a beginning or end to a circle.
For this reason, the essence of systemic thinking is to abandon the search for a root cause and, instead, to focus on the desired future state.
It then follows that, since we do not have a perfect understanding of the system, we cannot be confident that our first efforts to fix it will succeed. Hence, we must expect to iterate towards a solution, rather than get there in one mighty bound.
To be clear, I am not suggesting that we never look for a root cause. Rather, that if initial efforts to find one fail and it becomes clear that the system is complex, then it may be time to change the approach. This can take courage, since a systemic approach is less comfortable than an analytical one – no root cause, no simple cause-and-effect chain, no certainty about what the effect of my next attempted fix will be!
Let’s finish with a topic dear to my heart: engineering in a commercial context, where engineers are in contact with customers, both external and internal. Client interaction automatically involves feedback and complexity, not least because few clients or client organisations are predictable. Hence, as soon as there is customer contact, we are obliged to incorporate some systemic reasoning into our problem solving.
Many engineers adopt this way of working spontaneously, in which case I hope this text clarifies what they have achieved through intuition. For others, it may be more difficult: some people strongly prefer ‘clean’, isolated problems and, as mentioned, scientific training reinforces this inclination. In this case, simply being aware of the analytical-systemic balance can help.
I work with this challenge on a daily basis, helping engineers to combine the advantages of the analytical and systemic approaches through training and coaching. Our goal is to enable them to interact with their clients more effectively and hence maximise the positive impact of their work.
If you are interested in this topic, then I would love to hear from you. To learn about my activity, please go to www.icondasolutions.com.
