Making decisions is a core part of my job. As a software engineer, the decisions are technical; as a CEO, the decisions are strategic. Either way, I’m making decisions all the time.

So, how do I get better at it?

Below is an ongoing log of what I have learned + my decision log template based on those learnings. If you know of any other techniques, please tell me about them!

Write it down

Writing is thinking. Whether or not other people are involved in making this decision, writing down your basic line of thinking about the decision will make any gaps in your decision-making much more obvious.

This doesn’t have to be verbose, but it does have to include a few basics (see my decision log template below):

1. Evaluation criteria, in order of priority

2. Considered options and their pros & cons each

3. Preferred option and why

Put the evaluation criteria first!

I’ve noticed that people are often implicitly discussing differences in the evaluation criteria and their relative priorities but don’t/can’t speak to it explicitly, which slows discussions down significantly. People often harp on and on about the pros and cons of certain options vs. other options without being able to clearly nail the root of the difference in their opinion.

Explicitly state the evaluation criteria in order of priority first thing in your doc. That way, if people disagree with them, they can speak to it explicitly. I’ve found that this makes a huge difference in the quality and, thus, speed of these conversations; they end up sounding something like this:

Oh wait, you think a great user experience is more important for this feature than fast performance? That explains why you prefer option 2! I actually think fast performance is much more important because users will rarely interact with this feature directly but instead use the API most of the time, which is why I was in favor of option 1.

Yes! Let’s get to the bottom of the difference in opinion immediately 🔥

Share it with one person

After you write it down, share it with (at least) one person. They might have valuable feedback (or not), but even more than that, as Paul Graham says:

Just as inviting people over forces you to clean up your apartment, writing something that other people will read forces you to think well.

So, make sure your decision log is something that at least one other person will read—even if it’s somebody who has no context, like a parent or significant other.

Reflect with the benefit of hindsight

Another reason writing your decisions down is important is that it enables you to reflect later.

You can (and should!) look back at your decision logs months or even years later and assess what you got right and wrong with the benefit of hindsight to learn from your decisions.

For example, after choosing RethinkDB as our database at Spectrum, I realized in hindsight that I totally missed the most important evaluation criterion (community size) and highly overvalued another evaluation criterion that wasn’t actually that important. (real-time support)

Since then, I have applied these learnings to all my future decisions: I have never overlooked community size as an evaluation criterion for a foundational technology choice again.

Get deliberate practice from poker?

I haven’t personally started doing this yet, but I heard Tobi Lütke talk on a podcast about how he gets deliberate practice, which is the best way to learn, for his decision-making skills:

I make strategic decisions, for my job at the company. For most of these strategic decisions, I hope I do well, but I only find out a couple years later. […] But if I sit down for an evening of poker, I make these decisions every hand.

[…] doing that will change your mind, and your brain, and help you be prepared for situations you could never predict.

I might have to start playing poker!

Template: Decision log

Finally, this is the decision log template that I personally use, which takes all the above learnings into account to guide me down the pit of success without me having to think about it:

# [short title of problem]

## Context and Problem Statement

[Two to three sentences.]

## Evaluation Criteria (ordered by priority)

1. 

## Considered Options

### [option n]

* Pros & Cons:
  * 

Does/doesn't meet criteria and why: yes/no

## Decision Recommendation

Recommend option: "[option x]", because [justification].

Extended template for use at work

For more formal use cases (e.g., at work), I have sometimes used this extended template with extra fields and explanations. The overall structure is the same.

# [short title of problem]

* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Links: [list all the related links] <!-- optional -->

## Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

## Evaluation Criteria (ordered by priority)

1. [criteria 1, e.g., a force, facing concern, …]
2. [criteria 2, e.g., a force, facing concern, …]
3. … <!-- numbers of criteria can vary -->

## Considered Options

### [option n]

[example | description | pointer to more information | …] <!-- optional -->

* Pros & Cons:
  * Good, because [argument a]
  * Good, because [argument b]
  * Bad, because [argument c]
  * … <!-- numbers of pros and cons can vary -->

Does/doesn't meet criteria and why: yes/no

## Decision Recommendation

Recommend option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion evaluation criteria | which resolves force force | … | comes out best (see below)].

### Expected Positive Consequences <!-- optional -->

* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …

### Expected Negative Consequences <!-- optional -->

<!-- Every decision has tradeoffs and negative consequences. Which ones can we already foresee if we chose the perceived best option? -->

* [e.g., compromising quality attribute, follow-up decisions required, …]
* …

Credit: I adapted this template based on what I learned from using it in practice.