Decision utils (utilities) Part #2

When I first started my journey with programming the only tool I had was Java. I always liked the back-end engineering, so this felt like a good choice and I used it like hammer. I mean it. The first front end task that I did was with the use of good old Spring MVC (Java) framework. Let's be honest, the result was not astonishing and programming front end with Java and XML was... not the most pleasant experience I ever had. Then a couple of years later I was in a project, where React was used for the UI (User Interface). This was a way better experience.

I am not saying that Java, JavaScript or React is a golden rule for all of our problems, but having a tool belt full of options is. This is why expanding knowledge and skill set is mandatory, so we can stay on top of our game.

Today we approach this by continuing the decision utils listing, here is a link for the part #1. As a reminder in this series the assumption is to collect knowledge related to the decision making in a short form.  

Ask the expert/community

Given there is a decision to be made, but there is no, or little domain knowledge, there are two options. First a decision maker can take time, do research and become knowledgeable. Second - ask someone who already has the knowledge (plus experience).

It is worth to remember that learning stuff takes time, that sometimes can be used for other activities. That’s why doing an extensive research for problems, non-directly related to the business may be less efficient (or cheaper) than getting an external expertise. This can take a form of asking people on stack-overflow, reaching out to experts in a LinkedIn network, or looking for a dedicated discord server (AWS has an official one dedicated to support of amplify)

Explore scenarios

When considering options it is sometimes useful to play out the scenarios, to explore what actually needs to happen to get full benefits from a decision. An example scenario would be to choose the right programming language for a given problem, by asking a question: “what has to be done, so java (or X) can be used in our project?”

• There is a need to hire new java developer
• There is a need to add maven artifactory to the company workflow setup
• There is a need to set up a security check mechanism in the new pipeline, so it’s in line with company standards

Exploring all the options in the same way gives a better, broader understanding on the real impact. Then comparing the options and picking the winner is also easier.

Problem articulation

This technique helped me on a number of occasions. There are situations when it is hard to make a decision, because we do not fully realize why we face a particular problem and why a decision is actually required. An attempt to articulate the problem can help in identifying the actual pain points and expectations. From practical point of view I can say for myself that pouring it down on paper, helps in the problem exploration, increases the coverage, helps in getting a different and broadens the perspective. There is also a benefit of having the write up later down the road, when there is a need to evaluate the decision. It helps in understanding if the context has changed and if a decision can be challenged and changed. On the other hand it is also easier to collaborate and get feedback on a written form. It can take any form, like a design document, miro board, or an ADR (Architecture Decision Record, used by AWS to track decisions).

Blameless post-mortem

In case of a production incident, there is a need to fix the problem as soon as possible, but to there is also a need to understand it, to build security blocks to avoid recurrence. A blameless post-mortem fosters a culture where people can actually learn from mistakes and organizations can improve the product, by addressing real live scenarios. This technique comes from Google, here is more detailed write up.

Roadmap

It is easier for every team member to navigate in the organization, when they have at least a vague roadmap. In the lack of it, every single decision can drift the organization in different directions, making the process less efficient, or counterproductive, than it could be otherwise. Sometimes preparing a roadmap, can be an overwhelming task, considering the amount of unknowns, especially in a startup. The feeling of uncertainty is real. However it is better to have something, then nothing. A founding engineer, or leader, has to have a vision for the product. Otherwise the work can come down to extinguishing fires. In regards to teams, there is a strong need to communicate the roadmap over and over again, as the more we talk about it, the clearer the roadmap gets for everybody.