Tempo 2.0 - Chapter 3: Your company is a system and section 3.1: The Monty Hall Problem

To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately.

— Dr. Russel Ackoff

Companies and other organizations are systems. All systems have some properties in common. As you will soon see, these properties can be counter-intuitive. If we rely only on intuition, we will make the wrong decision, even when we have all the information we need to make better ones.

The Monty Hall problem

We are used to solve problems through analysis. To analyze means to split a problem into parts, and trying to understand the whole by understanding each part separately. The idea is that understanding the parts enables us to understand the whole. This way of viewing the world is called reductionism, and it has been the dominating way of viewing the world in Western culture for hundreds of years.

Analysis is indeed a powerful tool, but it has limits. When we try to understand a system by examining its parts, we loose the full picture. This can lead us to making bad decisions. Here is a classic example, the Monty Hall problem:1

You are a contestant in a game show. The game show host, Monty, puts three cards on a table. All cards are face down. Monty tells you that one of the cards is a winning card, the other two are blanks.

Monty asks you to pick a card, but keep it face down on the table. Then, Monty flips one of the two remaining cards over. It’s a blank.

Now you get to choose: You can either stick with the card you have, or you throw it away and pick the remaining card on the table.

Think it over before you turn the page and read the answer. What would you do, and why? Does it matter what you choose?

Figure: A Future Reality Tree with the solution to the Monty Hall problem.

The diagram above has the solution. Read the diagram in the direction of the arrows, from the bottom, and up, to the top.

The diagram is called a Future Reality Tree (FRT) and it is one of the tools you will learn from this book. It is fairly easy to read the diagram even if you have never seen a Future Reality Tree before.

Boxes with rounded corners contain text describing reality as it is right now. Boxes with straight corners describe things we do to change reality. The ellipses mean and. No ellipsis means the content of any one box can cause the effect on its own. Note that in a complete tree, all the boxes must describe things that actually do exist. Speculation and guesswork should not be present in the diagram itself.

The four boxes at the bottom of the diagram are read like this:

If there are three cards on the table face down and only one of the cards is a winning card, and I pick a card, but I do not look at the face side, then there is a 1/3 chance I have picked a winning card.

Analysis can easily lead you astray when you are dealing with anything even slightly complicated. If you break the problem down in separate parts, you end up in a situation where you have two cards to pick from, the one in your hand and the only remaining card on the table. It is easy to conclude that there is a 50-50 chance of winning, regardless of whether you switch cards or not. Because of this, most people choose to keep the card they picked at the start.

If you follow the diagram all the way to the top, you will see that after Monty has flipped a blank card, there is a 2/3 chance that the remaining card on the table is the winning card!

Really! Please do not take my word for it, after all, I could be wrong, or even trying to trick you. Walk through the diagram yourself. Even better, go get a deck of cards, and try it out a couple of times.

The Future Reality Tree helps us combine two different ways of thinking, analysis, and synthesis:

  Analysis is breaking down the problem into parts. That is what I did when I split the problem up in little boxes.

  Synthesis means putting different ideas together to form a whole. I did that when I organized the boxes, and drew arrows and ellipses.

You can think of it as laying a puzzle. Analysis is when you look at the shape and color of each piece. Synthesis is when you put the pieces together, so we can see the entire picture.

In this book, I use one of the best methods I know to understand complicated problems, The Logical Thinking Process (TLTP). I explain how you can use The Logical Thinking Process to solve problems and develop both strategies and tactics in Part C: Navigation.

It is fairly easy to read TLTP diagrams even if you do not yet know how to create them, so I’ll use them whenever I want to be extra careful to show cause and effect, and to build logical arguments.

Like all other tools, TLTP diagrams are based on certain assumptions of how things work, and that means they have certain limitations. We will have a look at those limitations later on, when we get to complexity theory and Cynefin. The reason I mention the limitations now, is I do not want you to believe that just because I show you a really great hammer, all problems are nails. We will deal with both nail-shaped, and not-nail-shaped problems and solutions in this book.


  Analysis is when you break a problem into smaller pieces to try to understand each piece.

  Synthesis is when you organize and connect pieces of a problem, so you get an understanding of the whole.

  We need analysis and synthesis together to understand and solve complicated problems.

  Visual methods, like The Logical Thinking Process can be a great help when analyzing and synthesizing problems and solutions.

  Just because you have a hammer, not every problem will be a nail. The tools in this book has limitations, and to use them well, you must understand not just how and when they work, but also when they do not work.

1 The Monty Hall problem got its name from Maurice “Monty Hall” Halperin, who led the game show Let’s Make a Deal in the sixties and seventies.


Popular posts from this blog

Waterfall - The Dark Age of Software Development Has Returned!

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Interlude: The Cost of Agile