On Making Decisions
I manage software engineers and regularly collaborate with teams across our company. We need to make dozens of decisions a week, ranging from the technical (how will we solve a particular problem?) to nuts-and-bolts process (after a sale, which onboarding steps should be manual or automated?) to the strategic (what customer problems are we solving?).
Organizations should deliberately consider how they make decisions so their process will improve over time.
Without such course-correction and introspection it can be hard to explicitly connect symptoms like mounting personal frustrations, politics, and time spent in ineffective meetings to the root issue of poor decision-making.
Good decision-making is efficient, leads to good outcomes, and unites a team rather than dividing it:
- 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.
Bad decision-making may look like:
- 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.
In my experience, teams crave leaders who provide clarity about how things work. There should be an intentionally designed decision-making process that establishes when to expect a top-down, bottom-up, or cross-functional approach; and how decisions will be documented and communicated.
In this post, I will dig into patterns for making decisions, then discuss types of decisions. I’ll pause to consider the nature of “authority” and power dynamics in the workplace. I’ll end this post talking about my preferred model, which is that significant decisions are made by an ad-hoc group of respected experts whose authority derives from the team’s trust in those experts and with few enough members to permit efficient discussion.
Beware of the HiPPO
HiPPO is an acronym for “Highest Paid Person’s Opinion.” It’s unfortunately the pattern most of us think about for decision-making — that choices are handed down a pecking order. A culture of top-down decisions can rob people of autonomy and motivation. And a small cabal of HiPPOs who run the show may become a bottleneck as an organization grows. It’s important to note that a HiPPO’s effects may be unintentional, such as when a casual comment is interpreted as a mandate and takes a life of its own.
Bottom-Up Doesn’t Always Work
Grassroots decision-making can work for some localized team-level decisions but rarely works across an entire organization. Consensus can be powerful if everyone is aligned, but may grind to a halt if there are intractable differences or too large a group.
While it’s reasonable to propose majority-rule voting (simple democracy), in practice this is rarely a viable approach in a workplace because voting doesn’t make a thing true or ensure wholehearted support.
A too-large group that lacks a facilitator or urgency about making progress can easily fall prey to death by process. If anyone can propose additional research, breakout sessions, or raise nit-picks, and if too many people are involved, then it’s almost inevitable that someone will throw a wrench into a discussion which requires a follow-up meeting, and so on. If a large group is truly required to make a decision, there must be facilitators to help move the process forward.
The practical approach I’ve seen most often is for a relatively small group of people to be designated to make a decision, usually after socializing with the larger group. This must be done with the support of leadership such that when the outcome is communicated it clearly has their backing.
Is a decision reversible or irreversible?
For any decision, an essential question is whether the change could easily be undone (reversible) or would be very expensive to undo (irreversible). Most decisions are reversible; they can be undone without too much fuss, so why spend too much time debating them rather than trying them out?
Sadly, many organizations develop a culture of stakeholders coming out of the woodwork to insist on having a say, or who over-inflate the stakes of each decision such that HiPPO buy-in is continually required. This doesn’t just slow down getting stuff done, it also makes it harder to discern which decisions are truly momentous and deserving of attention rather that merely trivial. If everything is treated as a Very Big Deal, nothing is. As Jeff Bezos noted in his 1997 letter to shareholders where he introduced this framework:
As organizations get larger, there seems to be a tendency to use the heavy-weight [irreversible] decision-making process on most decisions, including many [easily reversible] decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.
A good decision-making process should consider the weight and risks to choose how much time and how many stakeholders are appropriate. I suggest reframing “reversible decisions” as “experiments” to reinforce the notion that these are simply tests. This sets an expectation that it’s OK to roll them back, and also that you should define success metrics to measure against. It is important to consider how a rollback would work, and if there are hidden costs like customer confusion or team morale.
Be aware that matters of taste may derail these discussions. Often an interminable discussion about standardizing on an approach or tool turns out to be a debate about entrenched preferences. The classic example is engineering teams squabbling about which text editor to use. As a manager, I’ve found it’s important to call out when discussions appear to move from substance to functional aesthetics.
The Authority to Make Decisions
The critical question is: who gets participate in a decision-making process? How do you establish a kind of authority that is wise and has gravitas?
Yes, a HiPPO like the CEO can simply make unilateral decisions. But this is a brittle stick that breaks when swung. If a boss regularly behaves autocratically they will lose trust, stifle honest information flow, and encourage politicking.
To make lasting decisions, you must have a nuanced understanding of the nature of authority and legitimacy, and aim to establish credibility. (It is at this point I should give credit to David Foster Wallace’s essay Authority and American Usage). Being at the top of a power hierarchy does not automatically grant authority in the eyes of your team and anyone else you interact with. You can see this shift in our language, where the definition of authority has changed from:
The right and power to command, enforce laws, exact obedience, determine or judge / A person or group invested with this power
To:
Power to influence or persuade resulting from knowledge or expert information or advice / An accepted source or expert information or advice
While authority historically has been understood as dictatorial and absolute, there has been a modern shift towards being technocratic and relative. A decision is “good” if it comes from a trusted expert — precisely because they are trusted as an authority. There may be an elitist or hierarchical element to expertise in the way that only some people get to be doctors; but there is also a democratic implication that the power granted by trust comes from the people themselves. A decision-maker must regularly earn the right of their influence by making generally good decisions and sticking to their areas of expertise.
Who gets to make decisions?
The people who ought to make decisions are the experts who have a track record of making good decisions. Their job is not just to analyze problems, but to reinforce credibility by communicating how and why they made decisions.
An organization should pick subject-matter experts to make decisions. These people should be selected on the basis of reputation and experience, not title. Sometimes the CEO or someone with hierarchical power is the expert; in this case, make it explicit that their involvement is as an expert rather than title.
A skeptical reader might ask: why should the boss care what their employees think and spend time on getting buy-in? The manager’s job is to make decisions. Employees earn a pay check, that’s how things are. Outside of narrowly circumscribed types of work, employees are being paid for their ability to make decisions and collaborate. Their belief in the validity of what they do strongly influences how well they’ll contribute to a shared outcome. Even though workplaces are structured as a power hierarchy, if decisions are made on the basis of “I am the boss” there won’t be much support and enthusiasm. A good manager knows when to step aside and empower the subject-matter expert.
A Model for Decision Making
As a software engineering manager, here are the guidelines for how I think about making decisions.
- 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.
When there is a high-stake decision that isn’t easily reversible, we should do the following:
- 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.
- 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.
- 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.
- 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.
- 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.
It’s unfortunate, but a HiPPO may pop up to second-guess things. It’s important to keep one’s cool and to insist that there be a conversation about the decision making process itself; were the wrong people in the room? Was the research not sufficient? Remind HiPPOs that they cannot be in all meetings, and ask who they would delegate. Also, if the decision is easily reversible, ask whether they are aware it’s easy to change or if they have concerns you were not aware of. Use this as an opportunity to have a frank conversation about how to improve the process itself.
There will never be a perfect decision making process at work. People are complicated and have differing incentives and ways of thinking. But we should at least try to make this a thing we can calmly talk about and iterate upon, rather than continually getting caught up in the heat of the moment around specific disagreements or finger-pointing around the lack of progress.
