Culture and decision making
Culture has an outsized impact on a company, and for tech companies where investment dollars go primarily to engineering, this is even more so. It even results in silly phrases like ‘Culture eats strategy for breakfast” which is enthusiastically repeated in Silicon Valley tech circles. What the heck does that mean? That it is really import to have culture, but you can make do without strategy? Of course not. You need both.
The first post in the Blog was specifically about strategy and tactics: This post is about the equally important topic of culture.
Each organization has a culture. If you do not have a defined culture, a company will mimic the proclivities of the founder. Facebook has a hacker culture: Google is more academic: Intuit is famously customer obsessed. All this can be traced to the founder.
Statements on culture start with a Vision for the company: The values of the company that support the vision: the customer benefits that we always keep in mind: The metrics we track: How we think about contributions to the larger community. I am proud to be a part of Inflection, where all this is written down and shared with employees - as examples, Values and community impact. Values reflect baseline expectations. Integrity is one and it is a base expectation. However, there still more to be said about culture and further definitions needed. As a case in point, this post will discuss decision making.
Decision Making
This often tends to be a reason for a lack of velocity. The larger an organization, the more likely there is dysfunction in decision making, often devolving to a dilbert-esque “let’s have a pre-meeting for the decision meeting.” To make rapid decisions at Inflection, we adopted a few principles, which resulted in faster 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:
Most decisions are two way doors
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.
The 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
Consistent Communication
Each decision is communicated broadly. At inflection, we use our defect tracking system widely for software defects, as well as a workflow tool for decisions. 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.) Hat tip to Luu Tran (now at Amazon) for pioneering this at Intuit. The format we use is shown at the end of this post.
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.
Fixed, Flexible and Free
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.
Jira Format for decision tickets
DACI
Driver - Approver - Contributors - Informed -
Context
explain what decision needs to be made
Decision The decision that is being proposed. This is changed as people contribute their ideas to the decision
Rationale
The reasoning behind the decision made
Black Hat
The downsides of this decision
1: https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm
2: https://www.productplan.com/glossary/daci/