Second-Order Thinking
Second-order thinking, which relies on thinking of long-term consequences of decisions, becomes a critical skill to learn as we grow our scope or ownership of a problem space.
This past week, I had to review past decisions from people no longer at the company, which after further research, only partially dwelled in the long-term consequences. What this meant in the present was that I needed to uncover the past context and unwind the decision because otherwise, it would happen again. After documenting the various options, I need to talk with leadership and explain why we need to change strategy; even if we have short-term pains, we won't have to think about the risk similarly.
As I've grown in the staff engineer path, explaining long-term improvement plans has become an important aspect to call out when talking with leadership about possible solutions to be implemented.
What is second-order thinking?
In summary, second-order thinking is a mental model where we take a decision and its consequences and ask ourselves, "And then what happens?".
When we take a group of options and look at their long-term consequences, some decisions have long-lasting benefits that compound over time. Conversely, some options that appear attractive in the short-term might have negative effects over time. What this allows us is the ability to choose options beyond short-term gains better.
I've encountered multiple decisions that needed to be revised because we sometimes go with options that either confirm our biases or are within our control area.
Difference with first-order thinking
Generally, first-order decisions are the ones that are easy or fast to implement; regardless of their long-term consequences, they're the obvious thing to do right now.
Over our tenure at a company, we've all made decisions without thinking about the long-term consequences or come across decisions we should have considered. Like when you're new at a company, it is easy to notice places where something seems off, or we're stuck with a process that worked for some time, but over time it produces a lot of overhead for everyone. After you've spent some time at a company, long enough to encounter the consequences of your past decisions, you'll start to notice and consider these long-term consequences.
As my current role includes thinking across multiple teams and domains, I need to track where decisions of this kind are being made and potentially conclude that we need the short-term "pain" to get the long-term gains.
How do we train ourselves in this second-order thinking?
Writing is my medium of choice, and I generally use it to list all options whenever we come across a solution that needs to be implemented.
If we come across something like we have multiple services that serve data to the front end, like in the BFF pattern. We might ask ourselves:
- Why do we need to think about this now?
- How does this impact other teams?
- How it aligns with larger company goals?
- What got us here?
We might want to standardize these via a unified façade because current maintenance has become problematic. Or we might want to consider something like GraphQL backend for all of these. But we might not have the expertise in-house, which implies either training or hiring for that skill. What would these options bring us long-term?
After writing down the several options, their outcomes, and their consequences. I generally go iteratively over the second or third level of consequences. I look for options with positive second and third-level outcomes, even if their first-level is not.
I guide myself with how much impact I can yield and outcomes that compound over time.
Your turn!
Let me know if you know about this second-order thinking. Are you currently applying it at work? Have you had to revise past decisions from other people? Or even your own?
Happy Coding!
website | twitter | github | linkedin | mastodon | among others