How to be better at making decisions
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):
-
Evaluation criteria, in order of priority
-
Considered options and their pros & cons each
-
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.
Other notes about Personal Growth and/or Company Building
- 🌿Developer tools startups are playing on hard mode
How do you build a business selling tools to people who can technically build anything you can?
- 🌿How I tend to my digital garden
My quests with this digital garden are to publish more and to have fun. Let's explore why I even have a digital garden and how it's going.
- 🌲1:1s are for personal connection, not project updates
My 1:1s are unusual. Here's why.
- 🌿How to have great taste
Taste is what differentiates the good from the great. So, how can I have better taste? This is my ongoing log of what I have learned.
- 🌲Being unreasonably responsive has made my projects more successful
Creators who respond to feedback quickly unlock two virtuous cycles that allow them to build better solutions more quickly.
- 🌱How to ship faster
Humans have the ability to get ambitious things done ridiculously fast. How can I get more things done quickly?
- 🌱How do you invent the future?
Innovation happens by combining things we can see and touch today in novel ways. So how can we have more things to see and touch?
- 🌱
- 🔗David Cain: Do Quests, Not Goals
I love this reframing from "goal" to "quest": "goals" feel like pressure, "quests" feel like excitement and adventure!
- 🌿How we foster deeper connections in our remote team
I believe that teams that are more connected perform better and that remote teams have worse connections. How can we improve that?
- 🌿How we make brainstorming work
Brainstorming usually fails. But, I noticed a pattern in the times that it worked exceptionally well. Here's how to make it work.
- 🌲Why I'm vigorous about giving feedback
Every day, you will find me hunting down a founder's email to send them feedback about my experience with their product. Why?