A Note on Decision Making

Shooting from the Hip

When I started my career, I didn't think much about decision-making frameworks—or even know they existed. Decisions were something I made quickly, often by relying on the information at hand and sprinkling in a bit of gut instinct. Looking back, this worked out for a couple of reasons.

Firstly, I was pretty good at diving deep into technical problem spaces, which meant I usually understood the pros and cons of the options in front of me. Secondly, the stakes were low. My decisions mostly affected me or systems directly under my control, so the consequences of a bad call were manageable. I could fix things myself before anyone else was affected.

For example, I once needed to decide on and carry out a migration away from a discontinued, managed GraphQL service. The platform I was working on used this service for its database and API layer and needed alternate solutions. At the time I decided, planned out and attempted at least four different migration approaches before arriving at a suitable solution. I was the only person working on the project and so I could control the whole migration process. Although I chose the wrong approach a few times the impact was minimal as I could quickly revert and retry.

As a side note, that discontinued GraphQL service still had a powerful ORM, which then became its own standalone project. You may know it today as Prisma.

Discovering the Decision Type Framework

Things changed when I started leading a team. Suddenly, my decisions had broader implications. They took longer to make because I felt I needed a full understanding of the problem space in order to make a good decision every time. And when decisions took too long to make, it sometimes felt like not deciding at all, which often had its own consequences.

I started researching this topic and stumbled upon Jeff Bezos' 1997 letter to shareholders. If you haven't read it, I highly recommend reading the original text. One section, in particular, was exactly what I was looking for, paraphrased:

There are two types of decisions:

1. Type 1 decisions – These are high-stakes and hard to reverse. They require careful consideration and intentional effort to make well. They require a comprehensive process.
2. Type 2 decisions – These are low-stakes and easy to reverse. If you get them wrong, you can quickly revert or pivot and try something else, leveraging the new learnings from your previous attempt. They require a lighter process.

Armed with this framework, I sped up my decision-making by spending significantly less time on Type 2 decisions. The success rate stayed high because I could easily identify when I chose wrong and immediately pivot. Whether it was choosing new technology, formulating cloud migration plans, software architecture or handling tricky personnel issues, this approach worked wonders.

The Importance of Context

However, as my scope and collaborative reach grew further (I was now leading a team of leaders), I found that the success rate of my decisions began to drop, and I couldn't figure out why. This was quite jarring. I had a huge amount of success applying the framework for many years. I also evangelised the framework and my reports were experiencing the benefits of applying it to their own decisions. So why wasn't it working as well anymore?

The problem was context—or more accurately, the lack of it. I was classifying decisions as Type 1 or Type 2 based on my own perspective and capabilities. This made sense earlier in my career when I was directly involved in execution. But now, being several layers removed from the front lines, I didn't always have the full picture.

There were times when I thought a decision was Type 2 and encouraged a team to move quickly, only to see them struggle with the fallout of a poor choice for months afterwards. It was easy for me to see the path to pivot or reverse a decision because I simply had more problem solving experience. Without that experience, those decisions became Type 1 for those teams.

Going back to the example from earlier, I'd completed many migrations by this point and I could easily tell when a migration would be a difficult Type 1 or an easy Type 2, and if it was a Type 2 I knew how to easily revert and pivot to a different approach. But that knowledge and experience takes time and learnings from failure to acquire, and my teams were still developing these skills. For them, deciding on a migration approach was more often than not a Type 1 decision, and difficult to reverse. Should I have spent more time and effort bridging those skill gaps in the teams? Probably.

Gaining Decision Context

Over time, I realized that every decision lives within its own unique "decision space." Understanding this space is critical. It's not about going back to trying to understand every detail of the problem space, because that isn't scalable. I can't possibly gain the knowledge and skills to carry out every possible database and API migration in the future. Instead, it's about asking questions that improve your mental model of the system, for example:

• What system(s) does this decision exist in and impact?
• Who are the people involved, and what are their capabilities, or task-relevant maturity?
• What goals are the people involved optimising for?
• How might individuals' motivations shape their behavior and subsequently shape the system's behavior?

In our example, does the team have strong migration experience? What other systems are impacted by the migration? Is the team incentivised to complete the migration efficiently?

Answering these questions helped me gain the context I needed to make better classifications, which led to better decisions. My success rate improved, though it's still a work in progress. Fortunately, decision-making is a skill that improves with practice, and I'm optimistic that I'll keep getting better.

Final Thoughts

No decision-making process is foolproof. Even with the best frameworks and context, some decisions will turn out poorly. But that's a Note for another day. For now, my main point is that good decisions come from good, well-suited processes. And well-suited processes start with understanding your decision space.