(Systems + Design) Thinking

Solving systems-level problems

By Diego Espinosa

Back up. That’s what we need to do in order to solve the world’s biggest problems. 

We don’t just need to think about solutions. The problems we face, collectively, are new. They challenge old frameworks and require up-dated ones. That’s a big part of the reason why we, as a society and a species, seem stuck, unable to adapt to an existential threat. 

We need to back up, and re-think how we address problems in the first place. The problems we face are systemic. We need a common way of approaching them, one that recognizes the true nature of systems and injects it into our design process. We call this new framework network design thinking. 

Networks are everywhere: in our ecosystems and society, and of course in our digital world. They are also ageless. We humans were networked from the get-go, one of a few handfuls of species that cooperate extensively. Ultimately, that capability allowed us to organize and coordinate in the billions, and to alter the earth to our benefit.

Now our networks are breaking bad. We are knocking the planet off-balance and into a tragic feedback loop. Clearly it’s us that need altering. 

How do we get our networks to behave differently? That’s the question that occupies us. The answer is not by designing individual-level solutions. Design thinking is famously user-centric, but that doesn’t mean it’s human-centric. Humans exist in networks. We cooperate, therefore we are. What works for individual users doesn’t necessarily produce the best outcome. If the network gets sick in the process, it will feed back and affect the individuals. Economics calls this an “externality”, as if some deux ex machina were at work, an asteroid falling from space. No. They miss it. Whatever is happening is, at some level of the network, an internal dynamic. 

If economics re-labeled it an internality, the field might get us somewhere.

To influence a network, we need a network-level focus: How can we alter the connections, the feedback or the boundaries in order to change the behavior of the network. The connections, the feedback, the boundaries. Those three are the only things that characterize a network. Change one or more, and the change in the behavior of the network can be exponential. 

Designing network behavior means figuring out what is wrong with the network — why it’s functioning in an adverse way — and then designing a change to the three parts that will induce a positive shift. Fortunately, doing so fits neatly within the same general four-step outline as design thinking (DT). All that’s needed is a shift in orientation from the pain points of the parts to those of the whole. 

On to the re-cast steps, along with concrete examples that happen to be from healthcare (because human health is systemic in nature).

(1)

Network design thinking starts with empathy. One can actually empathize with a network, to observe its dynamics and “query it” for network-level data. Is there data missing, information that the players wish they had? Or are the boundaries wrong, because the network is excluding important components. Are the parts connected in the wrong way, so data exists but doesn’t flow to the right people? What is a “network journey” like, the path the different pieces take and their interaction? What are the parts of the network feeling, hearing and doing about the other parts? 

Finally and most importantly, does the network exhibit a simplifying pattern, like a positive feedback loop, explosive percolation or trophic cascade? These patterns, or dynamics, are how networks move mountains through self-organization. Identifying them is what allows us to escape the spaghetti bowl of causal loop diagrams. Extracting the core dynamic, the one that produces behavior we’d like to change, is key. 

For example: doctors are paid to intervene when patients get sick, sometimes to cure, and most often to just manage an illness. With chronic diseases like diabetes, the more they intervene, the more they charge, the less access to healthcare, the more people get sick, the more they intervene. The doctors are succeeding according to the network feedback: revenue. Yet the feedback loop fuels a diabetes epidemic, a planet-level phenomenon. How do we alter it?  

(2)

Once the problem is in view, the next step is ideate on how to solve it. How can we change the three parts to improve the network’s function? Create new data — feedback —- and break down silos so that it gets to where it is needed; connect parts of the network that today are cut off from each other; expand the network to include different actors. Design will encompass changes, perhaps multiple ones, to one or all of these factors. The changes should dissipate the current problem dynamic, and hopefully spark a new one. 

For example, if patients owned their lifetime health data, they could better manage their own disease progression with less intervention (change the feedback); these patients could connect to health coaches, virtual or human, who combine that data with AI to advise them at low cost (change the boundaries); and large companies could bypass carriers and self-insure to better manage population health (change connections). The more data, the more it improves health outcomes, the more self-insure, the more incentive to collect and analyze the data in the first place. 

(3)

The ideation stage yields the features and components of a new network design. Combining and implementing them into a working solution is the purpose of the prototype stage. What really sets network design apart from traditional DT is the vital importance of sequencing. Networks don’t boot up new behavior all at once. In technical terms, they exhibit path dependence, or non-ergodicity. Small differences in early steps can have a big influence on final outcomes. Once those steps are taken, they are hard if not impossible to reverse. 

Networks have to be coaxed, step by step, until finally a self-propagating dynamic falls into place. The right solution in the wrong order will fail. The word “implementation” itself carries too much unhelpful baggage. This is not about endless slide decks with checklists. It’s about the art of sparking self-organizing behavior, or, in other words, designing for emergence. We call this sequenced design — a key part of the prototype — the network path.

For example: How do we get patients to care about collecting their lifetime health data, when it’s not much use today? What early use-case can we use to drive patient adoption? What data do we need for that use case, and how hard is it to get? At what point will employers see the value in self-insuring, and how can we accelerate that using partnerships? How can we safeguard patient privacy in the process? 

(4)

Once the prototype design is complete, it’s time to deploy and test it, and learn from the feedback the test produces. Testing a network may involve creating a pilot that incorporates enough of the connections and feedback to produce the desired dynamic. This can be tricky when that behavior only appears at large scales, or a large minimum viable network (MVN). The best solution to the MVN problem is not to have it in the first place: that is, to design a prototype and network path that sparks behavior at lower scales. Along with the test, it’s important to define the metrics for success: how could we tell if the network is proceeding along the right path? How should we adapt the prototype if that path is shifting, or if the feedback is different than expected? 

For example: Run a test of the personal data-driven network with functional (holistic) medicine providers that tend to have loyal patients hungry for innovation. Have them target metrics achievable in short time frames, and allow limited reporting to select employer partners (while respecting privacy). Once metrics are met, ask the employers for some skin in the game: incentives, funding, etc — something short of asking them to self-insure using that set of providers. Once the incentives/funding is in place, see how the metrics respond further, and expand the plot to more patients. 

What’s the difference between network design thinking and systems thinking?

Network design thinking does two things: 

First, it updates the “mechanical” systems thinking metaphor. Network science is both relatively new and on a tear. Researchers across archeology, evolutionary economics, physics, ecology, immunology, genetics, blockchain, AI and other fields are adopting a networks world-view, one with emergence at center stage. The result is an improved understanding of network dynamics, as well as a common language for discussing them. 

Second it combines systems and design thinking in a holistic, natural way: designing for emergence. Just a few tweaks to the framework, and a supporting toolkit, and people adept at DT can quickly absorb its network variant. This makes it easy to train potentially millions of people quickly, to have whole organizations, across the globe, “switch on” a network design capability. 

And that is the main point. 

We are running out of time to find small solutions to big problems. Sustainability requires us to raise our focus to the network level, and to harness the power of self-organizing dynamics. Our organizations are mis-matched for that. They look at individuals (or sums of them), and they rely on hierarchical control. We need a path to get us from an untenable crisis point A to a sustainable point B. That path has to produce network solutions that take hold and scale quickly, and it needs to be immediately accessible to people across the globe. 

Network design thinking can take us down that path.