Causal graphs and principles for designing your life’s systems

Dear Young Tim,

In life, you will inevitably design and debug systems. Think of the physical systems you interact with. Your cardiovascular, dental, immune, and transportation systems. Think of the procedural systems you interact with. Your personal research system, your personal finance system, your personal software system, your business operational system.

Trust, time is a short man. If you want to see far, then it is in your best interest to learn from others. To stand on the shoulders of giants. In other words, read! Learn from the experiences of others.

What I wish I told you earlier is that debugging is a three step process.

Takeaways

First, you respond to the immediate negative outcome.

Second, you modify your procedures and decision-making processes so this particular issue does not happen again.

Third, you address the root causes about oneself and about one’s organization so this problem is less likely to recur in the future.

How did I get to these conclusions? Through books, a causal graphical approach, a general systems view and causal graph, and through gleaned principles of debugging.

Right. Let me unpack that…

Books

First, the books. I read Principles by Ray Dalio and Work the System by Sam Carpenter.

Perspective

While reading, I made use of the following key idea from Michael Margolis.

Graphing causal models, while reading econometric papers can make it easy to understand assumptions that are vague in prose and to isolate those assumptions that are crucial to believe the main causal claims [strikethrough by Timothy]

With that perspective, I approached these two books as causal graphical novels, rather than as traditional books.

Graphs

The first graph that stood out to me was the following.

Dalio wrote:

So, the quality of our lives depends on the quality of the decisions we make. We literally make millions of decisions that add up to the consequences that are our lives. (p. 16)

decisions-cause-outcomes

Next, I saw Carpenter write about a life of linear systems. Specifically, he said

Linear: For our purposes, this is how most systems execute themselves, in a 1-2-3 stepped progression Yes, there are always minor external and internal variables [i.e., circumstance…]. But here in the real world, we are streamlining things so events can be understood and manipulated. (p. 10)

linear-decisions

Putting the two together, I see the sequence of my decisions AS the system from Carpenter or the “machine” from Dalio.

That’s the first milestone.

I am in charge of managing my life, aka the sequence of decisions I make, that, in combination with all the circumstance of life, result in the outcomes that I experience.

Next, what happens when that system produces outcomes that I don’t like? How should I debug?

Dalio writes that,

It is important to distinguish root causes from proximate causes. (Principles, p.31)

proximate-cause

Proximate causes typically are the actions or lack of actions that lead to problems— e.g., “I missed the train because I didn’t check the train schedule.” (Principles, p.31)

Following this, Dalio notes that

Root causes are the deeper reasons behind the proximate cause: “I didn’t check the schedule because I am forgetful”—a root cause. (Principles, p.31)

root-cause

Here, we see that debugging or responding to a system that is not producing desirable outcomes has at least two steps. We change how we make our decisions to change our proximate causes. We change how we are to change our root causes.

Not to be left out, Carpenter writes that,

[…] a problem is […] a wake-up call. This means that once the manager corrects the immediate negative effects, there is a second step. It is this second step that is key: The problem’s cause is traced to the errant subsystem, which is then modified so that the problem doesn’t happen again. –Work the System

Here we see the emphasis placed on a different section of our graph.

immediate-effects

From Carpenter, we see that when debugging and responding to a system that is not producing desirable outcomes, we must first respond to the immediate negative outcome, and then we need to fix the subsystem (our constitution / makeup and decisions) “so the problem doesn’t happen again.”

the-system

Putting it together, we see that debugging is a three step process.

  • Address the immediate ramifications of the undesired outcome.
  • Change the way you make decisions so that we change our proximate causes.
  • Change the way you are as a person so you change your root causes.

That Young Tim, is what I wish I told you many years ago.