Second-Order Thinking or How to Make Better Decisions
Most leaders are familiar with this dynamic: a good decision today may lead to a huge problem tomorrow. Here is an example:
Imagine that you have a very experienced team working on part of the product, let’s say Payments. As soon as you have some work that needs to be done in Payments, you give that work to this team. Sounds great, but what will happen in a year or two if we continue with this dynamic? You will definitely see that the result of this dynamic could be predicted. This is what we call Second-Order thinking.
Essentials of Decision Consequences
Let’s stay for a while with this example and observe how it works in dynamics.
There is an obvious first-order consequence in this example with a clear positive dynamic: speed of development. When team A gets work in Payments, they better understand the code inside this component, getting better in a business domain or customer service.
We can also see this dynamic using the next causal-loop diagram:
The better Team A’s understanding of the codebase is, the faster they can deliver solutions (no need to learn the code). This definitely decreases the cycle time for such tasks. It will also increase the probability of the next task in Payments going to Team A (as they are faster in completing such tasks). We will call this cycle R1 — reinforcing cycle 1.
Usually, this is enough to decide that this is a good way of working. But let’s visualize the side dynamic that will grow over time: the more work Team A has in Payments, the bigger the gap will be in knowledge between the Payments component and all other components. And this actually means that the team will become more specialized. The more the team becomes specialized, the more the preference will be to give them work in the known area, so the probability of getting new tasks in Payments will increase. Let’s call this cycle R2- reinforcing cycle 2.
This means that after some time, the negative effect will appear:
But let’s continue and see what will happen next, let’s say, a year after the decision was made (it might be faster or slower depending on your circumstances). That decision will slow down the whole organization because now you have specific teams that can only manage specific tasks, so the trend will be towards local optimization — management will try to find more tasks in Payments to keep the team busy, even if there are more valuable tasks in the backlog from other areas.
Let’s see this in a wider time frame:
If we have Team A specialized in Payments, there will definitely be other teams specialized in other components. Let’s say we also have Team B handling Site Catalog and Team C handling Cart. Now, to make an end-to-end customer feature you need to have A, B, and C integrated (to make online shopping work). But if they are optimized locally (for development of their own part), someone will need to optimize globally — in such a company, you need to have coordinators handling the finished product, who will:
- Break down tasks for areas ABC
- Sync ABC teams in priorities
- Manage the delivery pipeline
- Test end-to-end result (yes, now you probably will have team D — The QA Team)
- Be responsible for end-to-end scenarios
What if there is no work for Team A? What if there is no need to do anything in Payments? Well, you will never face such a situation in this setup — Team A is always going to be busy because they cannot be without work. The person who manages their backlog will continuously keep them busy, even if the work they are doing is not the most important. This is intrinsic to a local optimization system.
Here is a very important note: there was no intention to create all of this in the first place. All of this is the result of a decision that might have been made 1–2 years earlier, but the problem is that no one will be able to link that past decision with the current result. There will be a root-cause gap, because you cannot say, “we now hire coordinators in this company because we started giving specialized tasks to our teams a year ago”.
That is how we can possibly get a bad outcome from a good decision. And we need to think in second-order to be aware of it or avoid it.
Second-Order Thinking
Inside The Most Important Thing book, Howard Marks explains the concept of second-order thinking. His concept is also closely linked to Daniel Kahneman’s Thinking, Fast and Slow book.
First Order Thinking: the fast decisions may feel obvious but they might have long-running negative outcomes, like let’s introduce KPI when somebody “feels” teams are not performing. Or smoking a cigarette when you are stressed. Such decisions work like pain-killer pills — they give relief temporarily but do not fix the root cause.
Second-Order Thinking is the mental model tool that helps think in terms of consequences, trying to model possible future scenarios. The key here is to see what others can’t see right now and share this knowledge for the future. So second-order thinking is a great tool for collaborative discussions on decision making.
When people think this way they usually ask themself the next questions:
- What will be the long-term results of my decisions? In a month? A Year?
- And then what?
- What are the other possible outcomes?
- What are the parts of the picture I do not see?
- Are there any other possibilities that I’m wrong? Who can help discover these unknown possibilities?
Using this approach you can model the system behavior over time with different scenarios like the one above.
Thinking in such a way is not easy, humans are built to make fast decisions and organizations value them a lot. But the more you practice Second-Order thinking, the better your decisions will be in the end!
To read on this topic
Thinking in Systems: A Primer by Donella Meadows
Mental Models: 30 Thinking Tools that Separate the Average From the Exceptional by Peter Hollins
Systems Thinking for Social Change: A Practical Guide to Solving Complex Problems, Avoiding Unintended Consequences, and Achieving Lasting Results by David Peter Stroh
We are hiring!
Take a look into our open positions:
