On Making Decisions


Organizations should deliberately consider how they make decisions so their process will improve over time.

  • Everyone knows what was decided, how it was decided, and the reasoning so there is transparency and little room for ambiguity.
  • Decisions are made quickly by the smallest reasonable group, respecting everyone’s meeting time and areas of responsibilities.
  • People feel like their interests are represented even if they don’t participate, because they trust the people involved.
  • Top-down mandates erode morale and slow down the organization because there is a bottleneck.
  • Past decisions are frequently forgotten or overruled, which creates a sense of going nowhere.
  • Different parts of the organization don’t trust one another and insist on escalating even trivial decisions.
  • Lack of clear delegation or decision-making process leads to too many people being involved, which is slow and inefficient.
  • No decisions get made because anyone can invent bureaucratic hurdles.

Beware of the HiPPO


Bottom-Up Doesn’t Always Work

A Springfield tradition (source)

Is a decision reversible or irreversible?

The Authority to Make Decisions

Who gets to make decisions?

A Model for Decision Making

  • My primary role is to facilitate decision-making with the team, not to be the person who makes decisions. If I do need to put on my “decision-making-manager” hat or be a participant, I need to be explicit.
  • There needs to be emotional safety to be able to talk about decision making and authority. Without this, people may filter the flow of information and distrust may fester. 1:1s are a good time to ask how people felt about decisions that impacted them or their teams.
  • If a decision topic comes up, it should be captured in plain language: what is the question, and what are the options? is this reversible or irreversible? what are the stakes?
  • I want our default behavior to be that we do things instead of debating things. When there’s an easily reversible decision we should streamline our process such that if it’s not controversial then we will proceed. We ought to save our energy for higher-stake, irreversible decisions.
“Ship it squirrel” believes in making progress.
  1. Appoint a person to take a first pass at defining the problem. The output is a prose document 1–2 pages long that describes the problem, why it matters, and who is likely to be impacted.
  2. Based on the problem statement, the product manager and I should work with the team to propose a group of experts who will make the decision (I’m deliberately avoiding the word “stakeholder” because it’s overused in business-speak, and does not always mean an active and knowledgeable contributor). As a general rule of thumb, there should be at least 3 people so there can be a discussion, but no more than about 8 people or it will get bogged down. This group should be socialized across the company. I generally frown on standing committees who approve things (e.g. a technical review board), instead preferring to pull together an ad-hoc group.
  3. Appoint someone to do research and write up a proposal. I recommend a technical spec for implementation or technology choices. The proposal should include options and a recommendation. There should also be a description of success and how we’ll measure it, such that we can later know whether it worked out. This document is broadly shared for a period of time for comments.
  4. Schedule a time for group discussion. Beforehand, define how the decision will be made. My preference is a variant of consensus: that the group will proceed with a course of action unless someone is strongly opposed. Very high-stake decisions that alter a company’s trajectory might be discussed by a group before the CEO or division head will make a call — and everyone should know this walking in.
  5. Once a decision is made, it must be documented in a way that can be easily discovered later. I suggest saving a decision record and also sending a large group email that broadcasts what has been decided, the group who was involved, and a link to the details.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chuck Groom

Chuck Groom


Consulting CTO open to projects. I’m a serial entrepreneur, software engineer, and leader at early- and mid-stage companies. https://www.chuckgroom.com