9 Steps for Making Technical Decisions

Every problem, technical or not, can be solved in many ways. If you are a problem solver, you have to decide which method to use for the problem at hand. As a software engineer, you work on technical problems every day, and you make technical decisions all the time, from naming variables to choosing architectures.

1. Identify the problem

This is the most important step, because nobody wants to solve a problem they don't really have. Find the root cause, not just the symptoms. A handy tool for this is the 5 whys root cause analysis.

2. Define what success looks like

Success conditions are measurable results that tell you the solution is acceptable. They are important later, when you review and analyze your decision. So they must be things you can actually measure.

3. List the possible solutions

Now that you know the problem, you need to know how to solve it. Gather the information directly related to the problem. Look at how other people solved the same problem before. Then make a list of possible solutions.

4. Identify priorities

Priorities are the things that matter more than others. Define what is important from every perspective: for the business, for the security team, for the developers, and so on. Priorities help you weigh the pros and cons of each solution.

5. List the risks, pros, and cons of every solution

Now research and dig deeper into the details of each solution. Make a list of pros and cons for each one. Try not to be biased toward a specific technology or solution, and be as objective as you can. Your analysis should be based on facts, not opinions.

6. Decide

After listing the solutions and collecting the facts, you are ready to weigh the pros and cons and pick the most appropriate solution, again based on the facts.

7. Plan and act

Now you have everything. Make a plan to reach your goal and start working on it.

8. Review

No decision is perfect, and we all make mistakes. Keep reviewing the results even after you decide. Don't be afraid to admit a mistake. Act on it fast, analyze your decision again, and redo the whole process from the beginning if needed.

9. Document your decision

Document the whole process and share it with the team. It's always better to have one place for decision logs, like ADRs (Architecture Decision Records), so anyone can find out why the team decided something.