Category :

My Decision Making Process

Over the years, I’ve developed a decision making process based on researching psychology, decision-making literature, and my own personal experience. Several people have commented that my procedure for making decisions often leads to very good choices very quickly, and in some cases it’s helped them make a decision in minutes or hours that they were agonizing over for weeks. The core idea is to figure out which pieces of information are essential at any moment in time, and focus your effort on those.

The Process

  1. Have a list of concrete alternatives.
  2. Pick one alternative as the default, then compare alternatives two at a time.
  3. Form a tree of decisive considerations.
  4. Focus on getting the information needed to solve the decisive considerations in order, until a clear winner emerges.
  5. Replace your default with whichever alternative was better, then compare it to the next option.

Example: Choosing Between Jobs

For step (1), alternatives like “work at Google” or “don’t work at Google” are bad, options like “work as a software engineer at Google”, “work as a data scientist at Sciencely”, or “continue searching for jobs” are much better.

Then you’d pick one somewhat arbitrarily as the default–say “continue searching for jobs”, and compare it to one other option. It’s important to take just two options at a time, because this makes comparison dramatically easier.

To form a tree of decisive considerations, think about things that would be definite deal breakers, or definite acceptance criteria. If Sciencely requires you to use Windows, and you absolutely can’t stand working on anything except ArchLinux, that’s probably not the job for you. A tree of considerations might look like this:

  1. If the job requires Windows, definitely no
  2. Otherwise, if the job requires relocating, definitely no
  3. Otherwise, if the job pays below minimum salary requirements, definitely no
  4. Otherwise, if the job looks like it will help you learn crucial skills substantially faster, definitely yes

…and so on. You don’t have to know what the answers to the decisive considerations are at the beginning, the point is that laying this out will help you figure out what to do next. If you have a tradeoff–for example, you’d be willing to use Windows if the job paid twice as much as anything else–then you can reframe condition 1 as “If the job requires Windows and pays less than twice as much as the next best job, then definitely no.”

Once you have this list, focus on figuring out the information you need to settle the decisive considerations, in order. You’d ask about Windows first, and don’t bother exploring the rest of the details. You go on until you’ve either hit a decision, or exhausted the tree. In case you exhaust the tree, add more branches.

While this process looks fairly long written out, it’s often very quick because there’s a clear decisive consideration. For example, I chose which college to attend in about 2 minutes doing this–while there was a huge flood of possible information I could have looked at, it became very clear that there was just one decisive consideration that ruled out almost every option.

Why does this work?

Having multiple alternatives avoids a very common decision-making mistake, which is decisions of the form “take the job or don’t take the job.” One is much more concrete, easier to visualize, and easier to get information on, so people will almost always end up taking the concrete alternative, and usually end up regretting it.

The second benefit of this approach is that it accounts for the fact that humans have limited working memory, so your mental performance tends to drop off rapidly the more items you hold in you head. By doing things like comparing only two alternatives at a time, the number of things you have to pay attention to is greatly reduced.

Another important factor is that the tree of decisive considerations reduces what can seem like very complex values problems to relatively objective questions which can be answered with information. This makes it very easy to narrow in on the actions you need to take.

Finally, this process makes it easier to change your mind if some of your information was wrong. If you were originally going to pick Google over Sciencely because of the Windows issue, but then you find out that they’re willing to change what systems they use, that can very easily update your decision. On the other hand, if you made a decision in a more intuitive way by taking in lots of information and going with whatever feels best, it can be very hard to incorporate new data.

Categories: Focus, Productivity

2016 Focus: Output

Every year, I like to pick one thing I’d particularly like to improve, in order to guide my goals and actions. My focus this year is on increasing the quantity of my output, which includes things like machine learning/programming work, math learned, writing published, talks given, and advice sessions. Broadly speaking, I plan to devise and test ways of doing things differently in order to achieve similar results in less time. I’ll focus mostly on finding principles and methods that work across multiple domains, although they’ll likely be somewhat specific to me.

Why quantity instead of quality?

People often worry about a quality/quantity tradeoff, but I don’t think that’s actually that common. For the most part, I expect changes that improve the speed of my work to improve the quality as well, due to having more iterations and faster feedback cycles. Plus, thinking about quantity is much more likely to lead to insights I haven’t had yet, while in many ways I’ve hit diminishing returns thinking directly about quality.

What results do I expect?

It depends on the domain, but there are probably several cases where I can double or triple my output over the next year. I’ve tried this in a few specific cases and seen significant results, and there’s probably a lot more low-hanging fruit. In addition, many of these types of improvements compound, so it only takes a small number of successes for a significant, permanent improvement.

Approaches I don’t expect to work

Deadlines and other methods of “forcing” output are other common recommendations, but I’ve mostly had negative results with things like this. While I can work something like 10%-20% faster by being stressed and “trying hard”, I’m usually a lot less creative in this mode, and over the course of a week I produce more if I’m calm.

Practice might provide some benefits, but it’s unlikely to hit the scale of improvements I’m looking for.

Outsourcing and delegation currently seems unlikely to work, largely because I’ve already picked a bunch of low-hanging fruit there, and most of the things I want to do more of are very specific to me.

Approaches I plan to try

At a high level, I’m mostly focusing on systematic changes to my workflow, or improving the processes I use to generate specific results. For example, Rachel Aaron has written about how she dramatically increased her writing output by paying close attention to her process and figuring out several ways to improve it.

Here are some things I plan to try:

Working Backwards

This consists of defining what the output should look like in fairly specific detail before starting in implementation. I do this to some extent already, but I plan to go a lot farther, particularly by designing several sub-components and milestones before I start implementing.

In data science, this involves starting by designing what my data flow, objects, and pipelines should do in great detail before building the processes to implement them. Currently I tend to stop after just designing the data structures that serve as an interface to the outside world, e.g. other applications or machine learning algorithms, and then I start working on implementing them. Instead, I plan to go one step further and design the intermediary tables or objects required in the process of creating the main object.

Defining clear end conditions for a piece of work

When I started college, I had no specific plan for studying for tests. I would just study whenever I had free time, until it was time for the exam. This was very inefficient–it would often lead to far too much studying for one exam and not nearly enough for another. To get past this, I started studying in a way that consistently checked what I understood and what I didn’t, and then I would stop once I understood everything on the exam.

Similarly, creative work like writing or preparing talks is often subject to Parkinson’s law–it’s easy to just keep working until there’s a deadline. To avoid this, it’s critical to have a definition of what counts as done. It doesn’t necessarily have to be a perfect definition, but it should be something pretty objective, such as “I’ve revised the essay twice” or “I’ve gotten feedback from three people.” In software, this could involve writing tests at the beginning, having all tests pass, and having someone review your code.

Uncertainty Reduction

If you spend an hour beautifully perfecting the wording of an essay only to throw out the whole paragraph afterwards, then all the time you spent polishing was wasted. It would have been much better to nail down the layout, then focus on getting it to the point where you’d be willing to show it to others. The broader lesson here is to figure out the piece of a project that has the highest uncertainty, and start iterating there, and do this sequentially until the project is done.

Updating on Difficulty

A mistake I frequently make: I consider several approaches, pick the one that seems best, and start working on it. Over the days, more and more information is revealed that makes it clear the approach will take substantially longer than expected–no one finding is damning, but altogether they mean a different path would definitely be better. At this point, I should re-evaluate and switch to an alternate approach…but I usually don’t. I have a few different ideas for how to fix this, including talking to people about my work regularly and doing weekly reviews.


Often I find that I’m not doing the optimal thing because it doesn’t seem like fun. For example, I enjoy writing code, and I don’t particularly enjoy writing tests, so I’ll tend to write tests much later than I should.

When this happens, I find it’s helpful to remind myself why I want to complete the project. I’m usually not just working on projects for fun–they relate to my external goals such as learning new things, earning money, or improving the world around me.

Categories: Focus, Learning, Productivity