Drive clarity in Decision Making

Siddharth Ram

Published in

The CTO’s toolbox

4 min readMay 31, 2021

Nothing will slow an organization faster than a lack of clarity in decision making.

There are specific anti-patterns in decision making. Some of the worst are

Ivory Tower decision making — making a decision without involving the right people who are either impacted by the decision or have expertise in the decision. In addition to this likely being a poor decision, decisions like these piss off the team
Implicit decision making. Decisions happen because they happened, with no conscious thought being applied. This is ok at the micro level, and rarely ok at the macro level
Inadequate communication of decisions. A bunch of leaders get together, make a decision, and fail to bring the team along. Now it is their decision, not the teams decisions.

I spend a lot of time crafting how decision making happens (not just in engineering, but designing it for the org). This post is adopted from my previous blog on this topic.

Principles for decision making

High Velocity decisions over High Quality decisions

Teams often wait too long to make decisions. This is because individuals often wait for ‘sufficient information’ to make decisions. When someone has sufficient information, they have waited too long. Decisions need to be made with the information available , not with the information desired. We favor faster decision making based on current information. We find that more often than not, we make the right decision. And when we don’t, we use principle #2 below:

2. Most decisions are two way doors

Making a decision late or not making one at all is much worse than a wrong, quick, reversible decision.

Bezos wrote about two way doors 1. Most decisions are reversible: If you find you had made a mistake, walk through that door again and reverse the decision. ‘Type 1 decisions’ which are fewer by nature — must require explicit consent from an appropriate person. In our experience, almost all the day to day decisions made are two way decisions. Only a handful of risky decisions really fall in that category — and are very obvious when that is the case.

This results in decentralized decision making. Decisions are pushed further down the hierarchy, closest to where the work is done and hence with the greatest understanding of the decision. But everyone needs visibility into decisions made. So we use two constructs, the ‘DACI’ (hat tip to leadership coaching at Intuit for teaching and practicing that) and consistent communication mechanisms for the DACI.

3. Have a DACI

Plenty of material can be found on this 2 on line. In a nutshell, there is an approver (has the final say), Contributors (they participate in decision making), Informed (are notified of decisions) and finally the driver, who will drive the decision making process

4. Communicate consistently

An architecture decision record is critical to communicate and store decisions for posterity. Examples can be found here

Decisions that impact a team need to be discussed inclusively and communicated broadly. I like using the defect tracking system to track decisions. Create a Engineering decisions board in Jira or whatever tool you use for defect tracking. Each time a decision is being made, a ticket gets opened explaining what decision needs to be made, what the current proposal is and what the DACI looks like. Everyone on the team gets notified about a new Decision ticket, and can add in their own comments. When a decision is made, a mail is sent out with a formalized template explaining the rationale for the final decision, along with a ‘Black hat’ version of the decision (ie what are the downsides of the decision, potentially.) The format we use is shown at the end of this post.

5. Use the Disagree and Commit Framework

An important part of the communication process is to ensure that we bring the team along in the decision by allowing participating on it via the DACI and communication. But we always look to ensure that once a decision is made, every commits to it — even if they do not agree with it. Agreeing and not committing is sabotage. If this is happening in your org, you have a serious problem.

6. Fixed, Flexible and Free decisions

I learnt this framework from Alex Balazs, Chief Architect at Intuit. There are decisions that are free (no one is going to come tell you what editor you should be using, as a trivial example. Use of tabs though… grr). There are others that are flexible. At Inflection, engineers may use different frameworks and tools depending on the task. There is flexibility in choosing it — but an engineer cannot decide that… “I am going to write production code in OCaml because it is cool.” Finally, some things are fixed. We run all software loads in AWS, and this is fixed. A change in this requires the CTO’s approval.

Don’t take the Decision Making framework too far

Going through an architecture review decision process should be done only for things that have a broad impact — there are clear costs to using this. I encourage teams to make decisions on when it is appropriate to go through the decision process and when it is overkill. Local decisions should stay local. Teams decide when the overhead of an architecture decision record is apposite.