editione1.0.3
Updated March 23, 2023You’re reading an excerpt of The Holloway Guide to Remote Work, a book by Katie Wilde, Juan Pablo Buriticá, and over 50 other contributors. It is the most comprehensive resource on building, managing, and adapting to working with distributed teams. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, 800 links and references, a library of tools for remote-friendly work, commentary and future updates, and a high-quality PDF download.
For the purpose of decisions in a business context, there are four general models most organizations use (whether they’re aware of it or not).
Command. Decisions are made by someone in a position of authority with no involvement from anyone else.
Voting. A group discusses options and then calls for a vote. The majority vote decides.
Consensus. A group discusses until everyone agrees on a decision.
Consult. A person making a decision invites input from others but ultimately makes, and is responsible for, the decision.
We’ll walk through the basics of each model and highlight ways these can vary in remote situations.
Commands happen when individuals with authority decide on behalf of the group, without space for question or discussion. This form of autocratic decision making has a place when decisions need to be made without consulting other team members. Examples include when individuals need to make decisions on behalf of the organization based on the goals that already have been set for the organization; or in cases of emergency, when any decision is better than no decision and someone needs to make the call.
importantHowever, we don’t recommend the use of command decisions in modern organizations beyond specific cases like these because it’s been found to reduce productivity and is not conducive to supporting a distributed, autonomous workforce. If you are a leader or manager that has relied on this decision-making style, we urge you to consider evolving away from it so you can build a more collaborative and effective culture.
Command decision making is in direct conflict with key remote-team values like transparency, autonomy, and trust. When individual contributors understand how their work connects to the overall mission, and are free from having to constantly ask for approval, they can enable the company to move faster by making good decisions without waiting for people to be available in real-time. A simple framework can be defined for everyone to understand when they are empowered to decide. GitLab’s guide on how to spend company money is an excellent example of empowering individuals to decide.
Voting (or vote-based decision making) is a form of decision making in which people in a group indicate their choice, and the decision is made based on the highest percentage of votes. A vote is decided by either a specific majority (for example above 50%, or two-thirds) or a plurality model, in which the choice that gets the largest number of votes, wins.
Voting can be useful when the outcome of the decision needs to be representative—say, when to hold a company retreat—or when all options to be considered have the same weight—for example, choosing the codename for a new release, or deciding between different options for a logo.
For some things, you might be able to take a vote by raising hands in a synchronous meeting, or you can use tools like Doodle to survey the availability of individuals for a meeting or an event like an offsite. Slack supports different poll tools to help teams vote, too.
Beyond these more perfunctory types of decisions, voting isn’t a terribly useful decision-making method for knowledge work in general, much less for remote teams.
Consensus decision making is a decision-making process whereby a group making a decision develops, discusses, and then decides together on a course of action. In order to proceed, everyone must agree on the decision outcome, but dissent and debate are allowed during the decision-making process.
Consensus decision making, unlike voting, requires that no one opposes the decision being made. While this can sound like an appealingly inclusive practice, it can lead to what management expert Peter Drucker calls the “consensus trap,” whereby a lack of consensus leads to inaction. The consensus trap emerges from a few possible scenarios, where it seems like everyone agrees, but in fact they don’t:
The majority of people in the group disagree, but keep quiet for social or political reasons.
No-one wants to assume full responsibility; either the decision is too important, or they don’t agree with the proposed outcome.
People just want the meeting to be over and done with.
One commonly espoused way to avoid the consensus trap is a method called “disagree and commit.” Active debate and disagreement about the decision at hand is encouraged, but in the end, the goal is for people who disagree to still commit to the final decision. This approach encourages participants to place the good of the whole group above their own individual preferences.
importantConsensus decision making can happen largely asynchronously through shared collaborative documents and forum or chat discussions, but if you find the team in this “disagree and commit” situation and there is someone on the team that requires convincing before committing, the process may benefit from synchronous presence.
The consensus trap is a specific form of a common consensus decision-making problem called groupthink.
Groupthink is a phenomenon when a group desires harmony and avoids conflict, leading to dysfunctional decision making stemming from a lack of critical inquiry and debate.
Groupthink often leads to quick, but mistaken consensus on a decision, either because external pressures are forcing a quick decision, or because the team lacks the psychological safety to raise issues and have healthy debate as part of the decision-making process.
cautionIf you don’t have clear goals, established values, and a high-trust remote environment where people have the psychological safety to raise concerns or dissent, consensus decision making is very likely to fail.
story “Consensus-based decision making can be appealing when you want to make sure that everyone’s voice gets heard, but be aware of potential pitfalls. If you have someone who is very change-averse, or a couple people with different approaches, these disagreements can effectively keep any consensus from being reached. This can make it nearly impossible to bring about any kind of meaningful change. If one person with a tendency to say no can keep an entire team from moving forward, this might be a sign that it’s time to look at different decision-making strategies.” —Ryn Daniels, Senior Software Engineer, Hashicorp
This decision-making method requires the input of others in order to reach a decision, but ultimately places the responsibility of deciding on a single person. For example, an HR leader may share a draft of the paid time-off policy with the company to get their thoughts, but this doesn’t mean everyone needs to agree with it or even that the leader will incorporate their input. Additional data and the experiences of others can help inform a decision, but the decision is still made by a single party who also bears the responsibility of the outcomes. (In extreme cases, people with authority can choose to override a decision if they identify increased business risk for which they are ultimately responsible.)
The practice of code reviews is a way of consulting others to make a decision about software. Every line of code a software engineer writes is a decision made on behalf of the team. When engineers share these decisions with their peers or others, they are looking for feedback. Code reviews done well allow for informed, distributed decision making.
In remote organizations, this consulting decision-making method can be synchronous or asynchronous. The HR leader can book a meeting for the entire company to share the new policy, and engineers can also schedule a window to host a review of their code in real-time. The collection of feedback can be fast, but it requires presence, which is costly in distributed teams.
Alternatively, there are asynchronous communication channels that are tailored for collecting contextual feedback. The HR leader could rely on collaborative documents like Dropbox Paper or Google Docs that have built-in comment functionality for people to give their feedback in line. This way, they can limit who edits the policy, while still asking for input on their decision. Software engineers use specialized software for code reviews—like GitHub, Bitbucket or GitLab—where code can be commented on and changes can be managed. Lawyers use a similar method when they redline documents.
Using written methods to collect input for consult-based decision making has a number of benefits:
Time zone agnostic. Using written documentation for feedback allows it to be collected independent of people’s locations or time zone.
More accessible and easier to manage. For example, asking 50 people their thoughts about a vacation policy in a meeting would be unwieldy and time consuming, and thus is less desirable than collecting their input in a document or spreadsheet.
Provides an artifact. Written documentation records the decision and how it was reached, and allows teams to review the process down the road. People who miss out on the decision, like new hires, can understand the input that was considered and the context that led to a decision.
Tracked and iterative. Writing down decisions allows teams to track steps along the way to making the decision. In the case of software and code reviews, teams can track versions of software iterations and code releases, and can refer back to them in case anything goes wrong.
This method of decision making has become so useful that teams have developed specialized processes to support it in distributed workplaces.
A Request for Comments (or RFC) is a written proposal that defines the methods, behaviors, and associated technologies for how the internet functions. An RFC is intended to solicit input, and occasionally peer review, for making a decision distributed across a number of people or decision-making bodies.
RFCs can be traced back to the origins of the internet, as an early form of communication and commentary related to ARPANET.* Open-source communities that need to make decisions on the future of their projects also use RFCs in the open to manage this process, and to decide asynchronously.
Some notable examples are the Rust and the Ember RFC repositories. The Rust community also wrote a book to help contributors navigate this process. Juan Pablo Buriticá wrote about what he learned implementing RFCs in his teams, hosts a template in GitHub, and has a real-world example of a proposal to his team.
Amazon famously combines asynchronous input and synchronous decision making in a process that is known as “six-pagers.” Before anyone schedules a decision-making meeting, they must draft a document (more than a page or two; typically no more than six) that clearly outlines the ideas behind the decision to be made. Amazon intentionally uses this instead of the classic PowerPoint presentation. In an annual letter to shareholders, CEO Jeff Bezos argues that the narrative structure of a good memo forces better thought and understanding than a slide-based presentation, which gives permission to gloss over ideas. A good six-page memo takes time and iteration to get right, he argues:
Often, when a memo isn’t great, it’s not the writer’s inability to recognize the high standard, but instead a wrong expectation on scope: they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more! The great memos are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two.
There’s not much documented on this process, but former Amazon employees have written about it, including some dos and don’ts when writing these documents. Brittain Ladd wrote about his experience with this process as well.
Without a proven, organization-wide approach, there may be, at best, isolated pockets of high-quality decision making where individual leaders have elected to take a rigorous, transparent approach. Otherwise, the organization is at the mercy of the biggest bias of all: the perception that it is good at making decisions.Larry Neal, former Manager of Decision Analysis, Chevron; and Carl Spetzler, CEO, Strategic Decisions Group*
The selection of leaders and method of decision making depend on the structure and purpose of each organization. Which to choose depends both on the desired outcomes, and on the given group’s ability to operate in different ways to collaborate toward a common goal.
Without the relative organizational context, we can’t help you answer who decides, but we can underscore how important this is for you to answer and document for your team. Lack of clarity in decision making will lead to challenges in your organization. When a worker doesn’t know whose responsibility it is to make a certain decision, the resulting block will hold up their work until they can find out who needs to make the decision.