In Homerun Technologies we strongly foster autonomy and we believe that the freedom engineers have in making technical decisions plays a key role in it.
Some decisions, though, are hard to make because they are unstructured and require us to have extensive knowledge of the environmental factors which might be uncertain and dynamic. For this reason, we do not always have all the necessary knowledge to make a decision. In those cases, it would be wise if we validated our decision with our Tech Lead.
The question is: how do we know when to make an autonomous decision or validate it with someone? Well, that depends on the kind of decision we are talking about. In particular, we can distinguish between strategic, tactical, and operational decisions.
🔴 Strategic decisions are major choices of actions and are likely to influence the business in the mid/long term. In case of strategic decisions, it is recommended we validate this kind of decision with our Tech Lead.
🟡 Tactical decisions act within the constraints set by the strategic decisions and might influence the business in the mid/long term. In this case, we are free to choose whether to validate this kind of decision with our Tech Lead or proceed with full autonomy.
🟢 Operational decisions are routine decisions that do not require a lot of evaluation, analysis, or in-depth study. This kind of decision does not usually influence the business in the mid/long term, so we are fully autonomous in making such decisions.
But how can we know if we are facing a strategic, tactical, or operational decision? Well, we can use the following flowchart to get help with that.
Now, to better understand the flowchart, let us go through the following definitions:
Adding code to the codebase inevitably means increasing its complexity. This increase could be trivial or non-trivial. The former can be easily digested by the team. The latter needs an extraordinary amount of energy and/or time to get digested. A non-trivial complexity increase could be nasty because it might hurt the speed of the onboarding process for new Engineers and on the team's agility and velocity in general.
An example of a decision that might add non-trivial complexity is introducing a tech tool not listed in our Tech Stack.
Other examples might be:
Decisions can be thought of as doors we walk through.
But what makes a decision reversible or irreversible? The estimated cost of reverting that decision in the future - mostly in terms of time and effort - makes it reversible or irreversible. So, we can say that a decision is irreversible if the cost of reverting it is too high to sustain for the business.
Examples of irreversible decisions might be:
This one-way door / two-way door decision framework encourages a thoughtful approach to decision-making. Reversible (two-way) decisions should be made quickly, as they carry low risk. On the other hand, irreversible (one-way) decisions require deeper analysis and consultation to avoid costly mistakes. Correctly classifying a decision as one-way or two-way prevents overthinking reversible decisions and ensures sufficient attention is given to those that have long-term consequences.
Critical parts of our product are features and services that are essential for the business. We can also say that without them the business would fail.
Some Examples of critical parts of our product might be:
If we are uncertain about which parts of our product are critical, we can talk about it with our QA Engineers, Product Managers, or Tech Leads.