On Capturing the reasoning behind decision-making, a method that works

How I Came Across the Idea

I was watching a documentary about a German company called Neumann that makes microphones. They have been making microphones since 1928, and the engineers who worked on the early models kept notes on how they developed the microphones.

For example, they would come up with Prototype #1, test it, and then make changes based on the test results. The engineers documented the reasons for every change they made. They would then repeat the same process for Prototype #2, and so on.

How did they benefit from this process?

Now, 98 years later, engineers at that company have a detailed record of all the things that did not work. Whenever they come up with a new idea, they can check the notes to see whether an engineer tried something similar before and whether it was successful.

When I sat down to write the first draft of this article, I ended up writing an article with a different purpose: I ended up with a draft about notetaking. After a couple of reviews, I returned to my original note only to discover how much I drifted from the original idea. If I didn’t have that written note, and the process of going back to original notes when making decisions, I would have lost the entire idea.

This article will help you understand why you need to document the logic behind decisions and design a simple process for documenting how and why decisions were made during a project.

What to Document

1. Failures

Keeping a record of things that have failed, and documenting how and why they failed, can be painful but also extremely useful both for the project you’re working on now and for any future projects.

2. Why Changes Were Made

Just like designing a microphone, creative work usually happens in iterations. Keeping track of changes and the reasons behind them will be helpful later. You might put a project on hold for a month, two months, or even a few years. It will be much easier to track why the project is at its current state and why and how decisions were made. This will save you a lot of time that otherwise you would spend to restart the project.

For example, when working on developing a website, I like to keep copies of the different drafts I come up with. This allows me to retrace my steps if necessary and avoid repeating ideas that I have already tried and found ineffective. An example of that is a website that went from having 9 different sections in the homepage to having only 3. The documentation included why we decided that we only needed these 3 sections for this website homepage.

3. Improvements and Additions

Whenever you go back to something you have already finished and make improvements or additions, documenting those changes can be very helpful. This would also be considered a type of “why did I make that decision?” note. It helps you keep track of why changes or improvements were made.

4. Lessons Learned

This is a common practice in project management. Whenever you finish a project, write down the lessons you learned throughout the project.

Some examples from my most recent notes include:

I discovered that I cannot effectively do creative work and administrative work at the same time. I should either delegate one of them or dedicate separate days or even weeks to each type of work.
I failed to plan adequately for formatting and pagination requirements. I assumed I would stick with the original template but later realized that the template did not account for many elements that emerged during development. Next time, I will budget more time for template revisions, formatting, and pagination. I will also document changes to the requirements, and the reasons behind these changes.

How to Document

Since we’re discussing creative projects broadly, it is difficult to come up with a single system that works for every type of project. Instead, let’s establish principles that can be applied universally.

Principle 1: Notes should stay attached to the project while remaining easy to find, review, and track.

For example, if you’re writing a story, a chapter, or any other form of written work, your documentation might include:

The different versions the chapter went through before reaching its final form (saved in one folder, clearly named).
Notes embedded within the final document.
A separate file containing an outline of the chapter, along with a timeline of versions and major changes made to each version.

Principle 2: Think what the future you would need to know about what you’re doing now.

Since you probably know yourself very well, you need to document decisions in a way that makes it easier for your future self (or another person) to understand the notes. The pitfall here is usually making assumptions about what your future self knows about the project and what they will have already forgotten 2 weeks after they finished the project or put it on hold.

Principle 3: Choose the easiest, simplest method.

Whatever method you choose to document your decisions, keep it simple – unless you’re building a submarine or a rocket. Avoid productivity optimization traps.

An Example from My Own Work

Several years ago, I wrote a book on music theory for guitar players. A few years later, I noticed some mistakes in the book. They kept bothering me until I finally decided to work on a second edition. I made a list of everything I wanted to improve:

Correct mistakes
Improve graphics
Improve language and flow
Improve formatting for better readability

I also wrote down why I thought the graphics were weak and what I needed to do to improve them.

Now I have a simple document that I can revisit once the second edition is complete to check whether I have addressed everything I originally intended to do. I can also record any additional changes I made that were not part of the original plan. For example, I deleted some content because I realized it was not relevant to the book. My documentation for that decision was the following: what sections I deleted, and why. I also kept the text that I deleted in a separate document because I might need it in a future project.

If I ever decide to work on a third edition, I will have Editions 1 and 2 available for comparison, as well as a document outlining the changes I made in Edition 2. I will also have the bits and pieces I did not use in this project that might turn out to be helpful for a future project.

Principle 4: how much is too much

Finally, note-taking and documentation are valuable, but they need limits.

You do not want to spend most of your time documenting rather than creating. A useful rule of thumb is that decision documentation should never take more time than the planning or execution of the project itself.

Depending on the type of project, planning may take the largest share of time, followed by execution. Documentation should support both of these activities rather than become a project of its own.

Conclusion

Documenting decisions is not about documenting what we did, but why we did it.