Making Decisions

Intro to making decisions

On this page, we have outlined how we make decisions at GitLab.

Making decisions

GitLab’s values are the guiding principles for our business. They inform hiring, performance management, and promotion assessments. They also guide other decisions that we make. At times, values may be in conflict. To address this, GitLab has a values hierarchy. At the top of this hierarchy is “results”. While items higher in the hierarchy don’t always override items lower in the hierarchy, this structure guides team members as they weigh decision making alternatives.

GitLab has a decision making process that avoids the short falls of hierarchical and consensus organizations. Hierarchical organizations can make decisions quickly, but aren’t great at gathering data. This leads people to say “yes,” but have relatively low follow through on their commitments. Consensus organizations are good at gathering data but lack decision making speed. This can lead to projects happening under the radar.

To avoid the undesirable outcomes of hierarchical and consensus organizations, GitLab splits decisions into two phases:

1. A data gathering phase in which folks are actively asked to contribute data and perspectives that can inform decision making. This has the benefits of consensus organizations: everyone can contribute and decision makers benefit from more available data.
2. A decision phase in which an informed individual can make a decision without getting an approval from others. Voting on material decisions shows a lack of informed leadership. The decision phase has the benefit of hierarchical organizations: the person that does the work or their manager decides what to do, so decisions can be made quickly.

These phases don’t work if you take a full consensus or hierarchy approach. If you apply consensus in both the data gathering phase and the decision phase, you lose speed. Decisions also stay under the radar as team members try to limit the amount of folks they need to buy-in. If you apply a hierarchy approach in both the data gathering phase and the decision phase, they lose valuable input. We can allow others into our kitchen, because we can always send them out. Inviting people to give input is much easier if you retain the ability to make a decision by yourself.

GitLab’s two phase decision making approach depends on aligned team member expectations and clear roles. Contributors can feel ignored when they provide input, but are not included in the decision making progress. They have to accept that the decision maker listened to them, but doesn’t owe them an explanation. Otherwise, you lose decision-making speed. To develop this level of trust, you need clear accountability and expectations for the decision maker.

At GitLab, each decision has an assigned Directly Responsible Individual (DRI). This is the person who leads the work, including data gathering, and makes the decision. The DRI analyzes the data and weighs different options. This requires the DRI to assess the validity and biases of different perspectives and the relevance and strength of data. The DRI should actively seek out input from folks who have meaningful data or experience in the subject area.

The DRI should have the level of seniority and knowledgeability required to gather information and make decisions. While this will vary with the complexity and potential impact of a decision, a DRI who is well matched to the ask gives team members confidence in an informed and knowledgeable hierarchy. Team members will be more confident that their feedback has been considered and more likely to agree or disagree and commit with a decision.

At GitLab, DRIs can make decisions that other team members disagree with. We say that collaboration is not consensus and people are not their work. A DRI may make a decision that results in (and is hence the cause of) negative feelings, but the DRI isn’t expected to make the popular decision and the person, the DRI, is not the decision that has been made. The DRI should consider input and make an informed decision, but the DRI is not responsible for how people feel. Once a DRI has made a decision, team members are asked to disagree, commit, and disagree.

If good decision-making appears complicated, that’s because it is and has been for a long time. Let me quote from Alfred Sloan, who spent a lifetime preoccupied with decision-making: “Group decisions do not always come easily. There is a strong temptation for the leading officers to make decisions themselves without the sometimes onerous process of discussion.”

• Chapter 5: Decisions, Decisions of High Output Management by Andy Grove

Why DRIs, not project managers

DRIs are not project or program managers unless they are team members who work with external organizations. Everyone at GitLab should be a manager of one. Team members need to develop their daily priorities to achieve goals. Individual contributors need to manage themselves. Self-leadership is an essential skill for all team members. If you manage yourself you have a much greater freedom to make decisions, and those decisions are based on deep knowledge of the situation. Folks who cannot be a manager of one struggle at GitLab. Assigning a project manager/coordinator/case manager/etc. to something is an indicator that something is wrong as DRIs should be equipped to manage their work. The notable exception to this is working with external organizations, for example in the Professional Services organization. External organizations don’t have our style of working so we need to adapt to their style of working to make it successful. Also working along organizational boundaries is much harder to begin with.

Tips for folks who are contributing to decisions

1. Use data, use cases, and historic examples when you contribute information.
2. Do not use personal opinions or attacks.
3. Encourage participation from others who may have useful data to share.

Tips for DRIs in making decisions

1. Make data-driven decisions.
2. When analyzing data for a decision, focus on growth and trends. Most of the time cumulative graphs shouldn’t be used because a standalone cumulative chart can be misleading as it goes up even if growth is flat or declining. If you must show a cumulative graph always include growth and trends on the same slide.
3. Be aware of your unconscious biases and emotional triggers.
4. When making decisions, explicitly acknowledge the quality/quantity of the data that is available for the decision. Resist using poor data to justify judgment calls. It is ok to make a judgment call with limited data, but make sure that is known.
5. Consider environments that do not allow reliable data collection. According to research by the Harvard Business Review, “experience and knowledge of leaders in the subject matter still outperforms purely data-driven approaches.”

Decision Proposals for Collaborating and Communicating

Decisions that require input, buy-in, or awareness of others should be accompanied by a brief, documented proposal. This can be captured in an agenda, issue, or Google Doc. Proposals should include SPADE Decision Making components. At GitLab, we should share the following:

1. Setting
   1. Precisely define the “what.” What decision is being made? What is the scope of the decision? Does this impact the product, the platform, or the entire company? Be as specific as possible.
   2. Be clear on the “when.” Explain the why of the “when.” Why that date? Why that duration?
   3. Explain the “why.” Clearly establishing the why is the key to the setting.
   4. Why is this smallest and fastest? A statement on how you are taking an iterative approach. Otherwise said, could this decision be broken into even smaller parts? If not, why not?
2. People
   1. Note who was consulted in the decision and proposal alternatives. Documenting who was involved and their role in the decision (consulted or DRI). This helps the team visually see if we have been inclusive in the data gathering phase.
3. Alternatives
   1. What alternative approaches were considered, including the one that you recommend? This is also a section to link designs or other external documentation.
4. Decision
   1. Which alternative or option was chosen? This should be updated following DRIs decision.
5. Explain
   1. Details for your recommendation. Justification for why your preferred path was recommended over others. When appropriate and possible, this should include a recommendation grounded in data.

We have an issue template that captures these elements: https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/issue_templates/decision-template.md.

E-Group Conversation on Making Decisions

GitLab E-Group and the Learning and Development team discussed strategies on making decisions as part of the CEO Handbook Learning Session.

Topics covered include:

1. Living our Transparency value when making decisions
2. How to improve our ability to Iterate
3. Applying the GitLab values hierarchy in making decisions
4. How the DRI enables decisions making
5. When to use consensus when gathering information and when to use hierarchy when making decisions
6. Importance of making team members feel safe when making decisions
7. Why team members making the most mistakes are likely to be the highest performers
8. Making decisions in the face of uncertainty