Disagree and commit

Decisions

Decision making is an integral aspect of how companies and teams function. In software technology based companies almost every project involves a multitude of fairly complex decisions that need to be made. Often these are at various impact levels spanning product to technical domains and even planning. Within technical areas too there are broad architectural decisions on how a system can fit into existing architectures, or code related decisions like what code formatting styles are to be followed.

For effective decision making, a fairly well defined process is described in this university course page It covers problem identification, analyzing options, making a choice and final review.

Disagree

In real life, most interesting decisions do not have clean options. Since the beginning of this year itself I've been part of 3 major decisions where the options and data have not been that clear. I've been a participant as a primary stakeholder in one, passive observer in another and a secondary stakeholder in another. I follow the principle of Disagree and Commit when it comes to decision making and strongly recommend it.

When having conflicting options, typically there are some unknown scenarios involved, or personal biases that cause conflict of weighting of pros/cons between options. Stakeholders should add more data or evidence to help consider the options. However disagreement on interpreting the evidence if it is available is still possible. How different groups interpret data is based on priorities and past experience in healthy teams. Personal advancement or team politics can also be strong motivators though not explicitly mentioned in decisions.

Most technical people reason based on analytical arguments and hence look for rational arguments in decisions. However many decisions are based on irrational beliefs or tacit knowledge by a leader.

Commit

If decisions are not made because of conflicting options, then you end up with analysis paralysis. This typically happens when there are multiple committees that need to arrive at a consensus. I strongly favor giving the team that owns the major execution the primary responsibility for the decision. Failure should have implications too. For projects, there should be a feedback loop with checkpoints to validate assumptions behind the decision. Unfortunately for high impact decisions made at high levels I do not typically see the evidence behind the calls or the accountability either.

I have a strong bias for action, and hence favor making progress rather than stalling. In the worst case, choosing the wrong option might lead to losses, but in-action is also a costly option.

The management principle of Disagree and Commit allows individuals to disagree and analyze tradeoffs for various options while a decision is being made; but once a decision has been signed off then everybody must commit to implementing the decision. Introduction of this principle is attributed to Andy Grove the legendary CEO of Intel who has authored many books and articles on management. OKRs were also popularized by him. These techniques show how teams who work towards the same direction can have a big impact compared to split organizations working in different directions.

For frameworks on making decisions, I'll probably expand on DACI and RFC in the future.