From Noise to Clarity | Track 9

COMPLEXITY: Untangling Complexity Without Oversimplifying #23

Visual Thinking for Transformation | Post 23 of 30

Before you read: think of the last time you saw a complex situation reduced to a simple framework for the benefit of a presentation. What did the framework leave out, and did anyone notice?

When complexity arrives in a transformation, the pressure to simplify it is immediate and understandable. Complexity is uncomfortable to hold, difficult to communicate, and resistant to the kind of clean decision-making that organisational calendars and meeting formats are designed to support. Leaders who can reduce a complex situation to a clear, simple message are valued precisely because that reduction feels like mastery. It looks like someone has understood something that was confusing and brought it under control.

The problem is that the simplification is often not mastery. It is omission. The complex situation has not been understood more deeply. It has been described more briefly, with the parts that do not fit the simple message quietly removed. This is not always dishonest. It is very often a well-intentioned response to real cognitive and organisational constraints, a recognition that the full complexity cannot be communicated in the time available and a reasonable attempt to convey the most important parts. But it produces a specific and predictable downstream problem: decisions are made on the basis of the simplified version, and then reality, which did not simplify along with the description, pushes back in ways that the simplified description gave no warning of.

The alternative to simplification is legibility. A legible complex system is not a simple system. It is a complex system that has been made navigable, that has been described in a way that allows people to understand enough of its actual structure to act wisely within it, without pretending that the parts left out of the description do not exist or do not matter. The distinction between simplicity and legibility is small in the moment and enormous in its consequences, and it is worth sitting with carefully before any significant transformation decision is made on the basis of a description that felt reassuringly clear.

“Simplicity removes what does not fit. Legibility reveals what is actually there. Leaders need the second, not the first.”

How oversimplification produces bad decisions

Oversimplification in transformation tends to produce bad decisions through a specific mechanism that is worth understanding clearly. When a complex situation is reduced to a simpler description, the decisions made on the basis of that description will be appropriate for the simpler version but not for the actual complex one. The decision that looks obviously right in the framework is wrong in the reality because the framework has excluded the conditions that would make it wrong.

This happens most visibly in the early stages of a transformation, when the planning is at its most abstract and the distance from the actual complexity of implementation is at its greatest. A restructure that looks clean on an org chart fails to account for the informal relationships that the new reporting lines will sever. A new process that looks straightforward in a swim lane diagram encounters the reality that three of the steps depend on a system integration that was not in scope. A cost reduction that looks achievable in a financial model does not account for the tacit knowledge embedded in the roles being eliminated.

In one case, a retail organisation was redesigning its supply chain to reduce complexity, explicitly using the language of simplification as a guiding principle. The design team produced a genuinely simpler supply chain structure that removed several layers of intermediary and consolidated supplier relationships from over forty active suppliers to fewer than fifteen. On paper, the design was elegant and the cost savings were real and well documented. The presentations to the board were compelling and the strategic rationale was sound.

What the simplified design had removed, however, was the redundancy that the existing complexity had provided, specifically the ability to route around a supplier failure or a regional logistics disruption using one of several alternative paths that the larger supplier network had made available. When a significant supplier experienced a disruption eighteen months after the new model went live, the organisation discovered that the complexity it had eliminated had been providing a resilience that the elegant design could not replicate. Sourcing alternatives under pressure was significantly harder than it had been under the old model, which had maintained relationships that could be activated quickly precisely because they were already warm. The simplification had been a genuine improvement in efficiency under normal conditions. It had also been an inadvertent reduction in robustness that was only visible under stress, and stress conditions are precisely when robustness matters most.

“The parts of a complex system that look redundant are often the parts doing the most important work.”

What legibility actually looks like

Making a complex system legible rather than simply reducing it requires a different kind of design discipline, one that starts from a commitment to keeping the important complexity visible even when the temptation to remove it is strong. Legibility is not the same as completeness. A fully complete description of a complex system is itself unusable, because the complexity of the description matches the complexity of the system and provides no navigational advantage. Legibility is selective, but it selects for preservation of the complexity that matters rather than for removal of the complexity that is inconvenient.

The most useful question for distinguishing between simplification and legibility in practice is: what would someone need to know about this system to avoid making decisions that the simple description would lead them to make but that the complex reality would penalise them for. That question focuses attention on the parts of the complexity that are most consequential for the decisions being made, and provides a principled basis for deciding which complexity to make visible and which can safely be left in the background.

In one case, a financial services organisation was mapping its client onboarding process in preparation for a significant redesign. The initial process map, produced by the project team from documented procedures and interviews with process owners, showed a clean twelve-step sequence that looked eminently redesignable. The twelve steps were logical, the handoffs were clear, and the inefficiencies were visible and addressable. The design team was confident.

When the same process was mapped by shadowing the people who actually performed it over three weeks, the map expanded to forty-seven steps, including seventeen that existed nowhere in any documented procedure. Several of these seventeen steps existed specifically because a previous redesign, three years earlier, had created gaps in the formal process that the team had filled with improvised workarounds. One workaround had been in place so long that the two people who had invented it had both left the organisation, and the current team performed it without knowing why it existed, only that it was necessary and that removing it caused the process to fail at a specific downstream point.

The forty-seven step map was not presented to the steering committee. The steering committee would not have found it useful and it would not have produced the kind of decisions the redesign needed. What it produced was a set of specific decisions about which of the seventeen undocumented steps needed to be preserved in some form in the new design, which needed to be addressed directly rather than being designed around, and which could safely be eliminated because their function was genuinely redundant. The final redesign that went to the steering committee was simpler than the existing process. It was not as simple as the initial twelve-step map had implied. The complexity that remained in the final design was the complexity that mattered, retained deliberately rather than removed carelessly.

“The goal is not the simplest possible description. It is the description that preserves the complexity you cannot afford to lose.”

Holding complexity without being paralysed by it

There is a practical challenge in working with complexity that legibility helps but does not fully resolve: the challenge of holding enough of the complex picture in mind at once to make decisions that are wise rather than merely coherent. Coherent decisions are easy to make in a simplified system, where the logic of the simplified version is internally consistent and the decision follows from it clearly. Wise decisions require holding the parts of the system that are in tension with each other, the efficiency and the resilience, the speed and the accuracy, the clear structure and the informal relationship, without collapsing that tension prematurely into a resolution that the situation has not yet warranted.

This is a cognitive and organisational challenge as much as a design one. Individual leaders rarely have the capacity to hold the full complexity of a significant transformation in mind alone, and those who try tend either to oversimplify under pressure or to become paralysed by the amount they are trying to hold. The most effective approaches to navigating complexity in transformation tend to be genuinely collaborative, distributing the holding of complexity across people who have different pieces of it and creating the conditions for decisions that are informed by more of the actual situation than any single person can access.

Visual thinking is one practical tool for this kind of collaborative complexity-holding. When a complex system is made visible in even an approximate and provisional way, it externalises the complexity from individual heads onto a shared surface where it can be examined, questioned, and navigated collectively. The act of drawing a complex situation out, even roughly, consistently reveals connections and dependencies that verbal description leaves implicit, and it creates a shared reference point that allows a group to hold more of the actual complexity together than any of them could hold individually. The forty-seven step map in the financial services example was not for the steering committee. It was for the design team. It gave them a shared surface on which the complexity was visible enough to navigate deliberately rather than stumble through inadvertently.

Transformation that navigates complexity well is not transformation that has made the complex simple. It is transformation that has made the complex visible enough, legible enough, and shared enough that the people navigating it can act wisely within it rather than despite it.

Where in your current transformation is complexity being simplified when it should be made legible, and what is that simplification hiding?

Next time, we close this stretch with One Thread at a Time.

If this resonates, you will find a deeper exploration of how to see business situations clearly in The S.T.A.R. System: Applying Visual Thinking for Career & Business Success, available on Amazon.

Ai Yat Goh is the co-author of The S.T.A.R. System: Applying Visual Thinking for Career & Business Success(Marshall Cavendish Business, with Sherrie Low). Follow Ai Yat on LinkedIn and Medium.

VisualThinking #Transformation #Complexity #Leadership #FromNoiseToClarity

BK HAN Candy Chan RH Malini GOW Hui Yian Lawrence Lee Germaine Kwek Joelynn Koh