The Solo Developer's Guide to Decision Making

During my time at Trello we heavily leveraged DACIs and implementation specs to make decisions. These are documents that are designed to communicate changes that you want to make to a product (more on that later). As a solo developer I never considered using these tools to help me build my product because I always saw them as primarily a communication tool. Why would I need to communicate with myself? I can keep it all in my head…

Recently I’ve been working on a big architectural decision for my (currently unnamed) data modeling tool. I found myself writing code, then scrapping it and re-writing it a different way, and then scrapping it and re-writing it again. It was frustrating. Normally I’m good about planning out work in my head and using intuition and experience to do the work. This work is particularly hard to keep in my head though, and I’ve never solved this unique problem before. There are a lot of different considerations and multiple possible ways to go about it. This reminded me of some of the other benefits of the decision making tools I learned at Trello.

The value of writing your decision down

Even if you’re not working with anyone else, there’s still a lot of value of writing out your thinking around decisions. Here are the biggest benefits for me.

1. The act of writing forces me to think about the problem in new ways.
2. I’m more confident in my decisions if I have a document that shows the careful thought that I’ve put into them.
3. My future self can come back and look at the document to remind me of why things were done a certain way.
4. The document forces me to be able to explain the problem in a way that others can understand.
   • This also gives me an easy way to ask for help from my other developer friends so that I can get their perspective on the decision (thanks Beau!)

How does it work?

The goal here is to make a good decision with as much information as you can get in a reasonable amount of time. I write decision docs, which are a light-weight version of the DACI. Here is how I do it:

1. Write down the problem that you are trying to solve. Try and explain it as if the person who’s reading is a potential customer but they know nothing about your product. Try and be concise, get to the root of the problem with as few technical details as possible.

2. Describe any additional information that may be relevant for making the decision that wasn’t included above.

3. List out the possible solutions that you’ve thought of. Be open minded about which one to choose. Be open to other solutions that aren’t in this list as well.

4. List out the criteria that you’ll use to make your final decision.

5. Put together a decision matrix that connects your possible solutions with your criteria. It might look something like this:

   Possible Solution	Criteria 1	Criteria 2	Criteria 3
   Possible Solution 1	🟢	🔴	🟢
   Possible Solution 2	🔴	🟡	🟠
   Possible Solution 3	🟢	🟠	🔴

6. Evaluate each solution on all of the different criteria. The decision matrix is good for looking at this at a high level in a visual format, but I also like to do this with words too.

7. Make a decision. After it’s all been laid out it should be clear which trade-offs you are making and why.

DACIs and Implementation Specs

DACIs and Implementation specs help with two different (and equally important) parts of the decision making process. The DACI helps you to make a good decision. The implementation spec helps you to execute effectively once you’ve made that decision. Today we focused on how to make the decision. In future blog posts I’ll cover the implementation spec and show real life examples of both from my project. If you don’t want to miss those 🎉 subscribe below 🎉!

DACI is an acronym for driver, approver, contributor, informed and it’d a tool for making (usually product) decisions. They are a tool for helping you to make decisions effectively. The acronym stands for the different people that are involved in making the decision and if you’re curious about each one you can read about them in detail here.

An implementation spec is a technical document that describes how you will make the change. It may include pseudo code as well as details about changes to API endpoints, database schema, UI, etc.

That’s a wrap for today! Hope you found it useful.