On this page, we have outlined how we make decisions at GitLab.
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:
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
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.
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, but it should include the following elements:
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:
