Autonomous decision-making in Software Engineering
July 21, 2021   ·  3min

In ProntoPro we strongly foster autonomy and we believe that the freedom Engineers have in making technical decisions plays a key role in it.

But some decisions are hard to make because they are unstructured and require Engineers to have extensive knowledge of the environmen­tal factors which might be uncertain and dynamic. For this reason, Engineers do not always have all the knowledge necessary to make a decision. In those cases, it would be wise if they validated their decision with a more Senior Engineer.

The question is: how do Engineers know when to make an autonomous decision or validate it with someone? Well, in ProntoPro that depends on the kind of decision we are talking about. In particular, we 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. We invite Engineers to validate this kind of decision with their Chapter Lead.

🟡 Tactical decisions act within the constraints set by the strategic decisions and might influence the business in the mid/long term. Engineers are free to choose whether to validate this kind of decision with their Chapter Lead or proceeding in 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. Engineers are fully autonomous in making such decisions.

But how can Engineers know if they are facing a strategic, tactical, or operational decision? Well, we created the following flowchart to help them with that.

Now, to better understand the flowchart, let us go through the following definitions:

  • Decisions implying a non-linear complexity increase
  • Irreversible decisions
  • Decisions impacting core domains

Decisions implying a non-linear complexity increase

Adding code to the codebase inevitably means increasing its complexity. This increase could be linear or non-linear. 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-linear complexity increase could be nasty because it might have a negative impact on the speed of the onboarding process for new Engineers and on the team's agility and velocity in general.

Examples of a non-linear complexity increase might be:

  • Changing a widely used team’s standard (e.g. the way API endpoints get validated).
  • Picking a new programming language for a new service.
  • Adding a new vendor for handling a given responsibility.

Irreversible decisions

As Jeff Bezos states in one of Amazon's shareholder letters, decisions could be compared to doors.

Reversible decisions are doors that stay open after we walk through them. We can change our minds and go back if we do not like what is on the other side of the door.

Irreversible decisions are doors that automatically get closed when we pass through. That makes it hard/impossible for us to change our minds and revert our actions.

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:

  • Defining Architecturally Significant Requirements; requirements that have a measurable effect on the system’s architecture.
  • Introducing a breaking change to an internal library widely used in our ecosystem.
  • Implementing an abstraction for many use cases.

Decisions impacting core domains

Our product and system can be described as a set of domains, where a domain can be seen as a sphere of knowledge, influence, or activity. Domains can be classified into core and non-core ones.

Core domains are domains that are essential for the business. We can say that without them the business would fail.

Having a clear list of core and non-core domains makes it quite easy to determine if a decision has a core impact on the business or not.


In ProntoPro we believe that autonomy in decision-making is key to having happy and productive teams. In this article, we shared the practice we follow to foster autonomy in the decision-making process.

Do you have tips, doubts, or curiosities about this practice? Or do you maybe want to share with me the way you handle decision-making in your organization? If so, please, reach out on LinkedIn. I'd love to hear from you.

Happy decision-making everyone! 🤜🤛