Systems Thinking As Collective Decision Making

By Diana Montalion

in Thinking | March 5, 2019


Strategic and systems thinking are interrelated and interdependent. Technology initiatives, especially complex ones, rely on both. Avoid drowning in the gaps between them. Build bridges with strong collective decision making.

“Teamwork is a strategic decision.”

Patrick Lencioni // Author, The Five Dysfunctions of a Team

In our last article, we explored strategic thinking. In this article, we’ll examine systems thinking as collective decision making. Successful initiatives depend on both strategic and systems thinking — they are interrelated. To be honest, I find them difficult to extricate because they meet similar needs.

Both conceptualize circumstances as ecosystems, evolving holistically from a present state to a future state. Both predict how changes in one area will impact, positively or negatively, the whole. Both seek to optimize those ecosystems.

Strategic and systems thinking are also interdependent. Strategies manifest as systems and systems embody a strategic purpose. The system’s priority is work that is valuable to that purpose.

They are merely divergent points of view. Oversimply, strategic thinking focuses on Why and What. Systems thinking looks at How. Both, in their own way, value emergence: the whole becoming greater than the sum of its parts.

Strategy depends on systems and systems depend on strategy. Yet, when taking on technology initiatives, organizations often increase the divergence between them. People and processes cement into roles and responsibilities. Business people in the east, techies in the west. Leadership in the north, implementors in the south.

In the center, everyone hopes to make the best possible decisions under the circumstances. They need bridges built between their interdependent and interrelated points of view. Bridges that strengthen and support good decision making. Strong, well-considered decisions deliver strong, trustworthy solutions.

The fault lines

“He who establishes his argument by noise and command shows that his reason is weak.”

Michel de Montaigne // French Essayist

Before we discuss bridges, let’s peer into some of the rifts that make them necessary:

Point of view blindness

People with differing points of view conceptualize ecosystems differently. When deciding what is valuable to do, accountants and engineers rely on disparate conceptual models. When four people can’t agree on a solution they are usually, unbeknownst to them, solving different problems.

Specialized language barriers

Strategic and systems thinking depend on specialized language, often across multiple domains. Integrating those languages requires developing a shared conceptual vocabulary. Many times, I’ve used a word that had a clear meaning for me — only to discover that I was completely misunderstood. The word had a different, antithetical meaning for others.

Resistance

People don’t necessarily want to interrelate and interdepend. Individuals and teams choose to command or isolate rather than partner proactively. In meetings, they focus on what is personally relevant and don’t contribute. Yes, organizations reinforce this behavior, even make it necessary. That’s a problem. But individuals must also value interrelation.

Lack of structured transparency

The wisdom of the parts depends on the wisdom of the whole. And vice versa. Strategic systems design depends on information flowing up and down the macro-micro scale. Blocking this flow are closed-door leadership decisions that "trickle down" as tasks. Transparency isn’t simply a culture-building value, it’s a business imperative. People who understand their ecosystems’ strategic purpose contribute more valuable work to its systems.

When building systems, every rift in the process will manifest as a rift in the system itself. Systems thinkers must build bridges.

The bridges

“Miscommunication is the number one cause of all problems; communication is your bridge to other people. Without it, there’s nothing.”

Earl Sweatshirt // American Rapper

Strategic and systems thinking are always operating under uncertain conditions. Their raison d’etre is conceptualizing change. Change triggers fear of losing control, which explains the appeal of control-based methodologies. Uncertainty seems risky, even though uncertainty is a constant. We often react to uncertainty by demanding it submit to authority.

Alas, reality refuses to bow down to power. Command and control approaches only work when teams are inherently weak or directionless and need to be commanded. Most teams are strong despite the pressure to be needful of command. A better approach is to strengthen their ability to contribute strong thinking.

Ultimate control arises from well-reasoned, strongly-justified decisions made when circumstances are uncertain or changing. This requires trust building. Strategic and systems leadership builds trust by structuring collective decision making. This approach is also a better return on investment. People engaged in technology initiatives are being paid for their expertise. Leverage it.

Examples of bridge-building habits:

  1. 1
    Before diving into solutionizing, define the problem and why its valuable to solve. When a discussion gets lost in circular email threads, go back to this step.
  2. 2
    Avoid the curse of knowledge by defining domain-specific concepts, especially if they seem obvious to you. Even better, use common language rather than domain speak. People don’t need to know the words ‘Agile’, ‘EC2’, ‘JSON’, or ‘value flow’ to understand what they are and why they matter.
  3. 3
    Decide that gathering others’ expertise is an essential part the decision making. Critically listen to others’ ideas and strengthen them by reflecting on how well (or not) they solve the problem. I do not mean cat herding — getting everyone to agree. Reasonable people disagree. Understand and articulate why they view the circumstance differently. The goal is not to be right; the goal is to be correct under the circumstances.
  4. 4
    Discussions have deliverables – deliver them. A quick document, model, or photo of the whiteboard are deliverables.
  5. 5
    Structure a digital space for those deliverables. Make it easy to connect the smaller discussions to the big picture. This space can interconnect with a group of spaces, backlogs or repositories. The goal is to create a transparent view of the ecosystem and the strategies evolving within it.

Collective decision making

“The aim of argument, or of discussion, should not be victory, but progress.”

Joseph Joubert // French Moralist and Essayist

Making the best possible choice under the circumstances requires defining "the circumstances" and "best possible". First, we conceive of choices and consider the reasons for choosing one. Then, we infer. Do those reasons support that choice? Does that choice lead to the best possible outcome?

In other words, we guess. We make a parachute out of facts, experiences, research and then … leap. Collective decision making is leaping together.

Everyone involved is taking the risk. Perhaps they are wrong, or the circumstances will change. Perhaps they’ve missed something or there was a better choice they didn’t consider. Regardless, they hope that the choices they make together are better than they’d make alone.

Collective decision making, also called argumentation, is an exercise in shared vulnerability and critical listening. The goal of working together is to strengthen the reasons. The reasons behind a choice are more important than the choice itself. The ideal outcome is to co-create reasons that so strongly justify the choice, no further inquiry is necessary.

There are many ways to structure this process. Here I describe the easiest model to begin with, a top-down elaboration (TDE) document. I’ve witnessed teams significantly reduce the "noise" of initiatives by introducing TDEs. As they became more efficient at making strong decisions, they built trust. This trust gave them more control over their day-to-day decisions and more voice in bigger-picture discussions.

Getting on the same page

Anyone can create a TDE and whenever two or more gather, someone should. One page is usually enough to summarize. Link to further information, code, models or other spaces. TDEs are simple but their potential for breadth and depth (through linking) is endless.
TDEs evolve. Decisions often arise after discussion. Sometimes they describe a dead end. Deciding not to act is equally valuable. Wisdom hides in knowing what not to do.
Reasonable people disagree on what belongs in each section. That’s okay, disagreement is welcome. Here’s how I approach it:

Summary

What is the decision or solution and what are the highest-value reasons that support it? Three are usually enough, five at most. This summary can be at the top, the bottom (Therefore,) or implicit throughout the TDE.

WHY?

Describing WHY is difficult. We usually don’t aim high enough. Saving money isn’t WHY, unless we understand why saving money is valuable under the circumstances. Most of our WHY reasons are WHAT reasons. "A world-class solution for our customers" is a WHAT. Why does "world-class" matter and how do we measure it? A general rule is: Everyone who reads the WHY will understand the value.

Imagine Frodo throwing The Ring into the river of molten lava. Imagine a woman standing beside a river on a spring day, taking off her wedding ring and throwing it in. Imagine a man in the midnight shadows walking along a river, sirens and police lights in the distance, taking a ring and other trinkets from his pocket and throwing them into the water. Same WHAT – entirely different WHYs.

WHAT?

What —exactly— are we talking about doing? This section describes what the solution will do in order to meet the WHY goal. Inherent in this section are inferences between the WHY and the WHATs.

WHO?

Who is impacted and how do they benefit from the WHAT? Who does the work? Including users, doers and decision makers defines boundaries and how people will participate.

HOW?

How will we do, build, design or continue to explore the WHAT? Here is where an honest discussion of alternative options and considered assumptions belongs. Describe issues, blockers, challenges and/or risks. The bridge between strategic and systems thinking is built here.

WHEN?

People want to know, first and foremost, “when will this be delivered and how much will it cost?” In reality, WHEN is the last piece of relevant information that can be understood. Describe how you will discover the answer. Are there any timing considerations? (Note: "We want this by April" is not a WHEN, it requires a reason.)

Who is at the table?

“Disagreement is the life blood of democracy, dissension is its cancer.”

Daniel J. Boorstin // American Historian

When a TDE is created and decisions are made, who is in the room discussing it? The answer is: the people who can strengthen a claim from multiple points of view. Which is to say, it depends.

Interdependency and interrelating are essential but so are boundaries. The goal is to get the right mix of people in the room. The goal is not to include "everyone". That will be a merry-go-round of indecision. The goal is not to form committees, whose role is to judge. Collectives discern and seek truth. And though tradeoffs are made, the goal is not negotiation. The best outcome may not (necessarily) appease organizational politics.

Speaking of politics, voting is an unreliable decision-making method. Popular does not equal well reasoned (see current world politics). Not everyone has subject matter expertise that can, or will, strengthen the reasoning.

Not everyone needs to have a say in everything; everyone is not responsible for the same things. Boundaries encapsulate problems so they can be solved by people who work within that boundary. For example, if I will be up at 2am debugging after a code release, I want responsibility for how code is designed and implemented.

Identifying areas of responsibility is not the same as identifying who has the authority. A better question is "who can provide insight?" You need both authority and insight in the room.

Everyone at the table is collectively strengthening the TDE. If people are in the room but not joining the discussion, then something is broken.

Needing feedback is different from critical listening. Feedback is a form of research and when you need some, tools like surveys, quick chats or emails are sufficient for gathering it. Clarifying questions often spin off into other groups to discuss. That is why adopting collective decision making across teams is so valuable … the parts can be constantly improving the whole. And vice versa.

Are your bridges strong?

“Action is the real measure of intelligence.”

Napolian Hill // American Author

How do you know if collective decision making is improving technology initiatives? Here are some indicators that good thinking is taking root:

Strong

Weak

Proactive

Reactive

Different parts of the ecosystem have a similar feel

Different parts of the ecosystem are unnecessarily dissimilar

Solutions are argued at the conceptual level, “Portability is valuable and a priority because …”

Solutions are argued at the implementation level, “We need Kubernetes.”

Constraints strengthen

Constraints control

Tradeoffs are made

Blame is shifted

Mission driven

Power driven

Transparency

Need to know

Transparent

Information is a power currency

Decisions can be traced to priorities

Decisions can be traced to authority

Considerate and respectful

Derisive and frustrating

Elegant simplicity in the system

Mounting technical debt

Summary

Strategic and systems thinking depend on each other. Collective decision making, also called argumentation, builds bridges between Why, What and How. Done well, these bridges foster emergence: delivering a whole that is greater than the sum of its parts.

In upcoming articles, we’ll continue to explore strategic and systems thinking. We’ll outline practical methods for structuring and discuss related skills. Want to follow along? Subscribe to Architecting Enterprise and receive our monthly edition.

Resources


Diana Montalion

About the author

If you’ve read The Economist, donated to Wikipedia, or contributed to The World Monuments Fund, you’ve interacted with systems that Diana helped to architect. She has 15+ years experience delivering initiatives, independently or as part of a professional services group, to clients including Stanford, The Gates Foundation and Teach For All. She is co-founder of Mentrix Group, a consultancy providing enterprise systems architecture, technology strategy, and content systems development. She also takes meeting notes with a fountain pen and is an aspiring plant chef.

Get Notified

Receive updates with our latest thinking about content systems modernization.