Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Making Decisions

  1. You are here:
  2. Handbook
  3. Leadership
  4. Making Decisions

Intro to making decisions

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

Making decisions

  1. We use our values, and particularly our values hierarchy, to guide the decisions we make.
  2. We combine the best of both hierarchical and consensus organizations. Hierarchical organizations have good speed but are bad at gathering data, leading to people saying yes but not doing it. Consensus organizations are good at gathering data but lack speed, leading to projects happening under the radar. We split decisions into two phases. The data gathering phase has the best of consensus organizations, where everyone can contribute. The decision phase has the best of a hierarchical organization, the person that does the work or their manager decides what to do.
  3. If you apply consensus in both the data gathering phase and the decision phase you lose speed and you get decisions that try to stay under the radar so there are fewer people to convince.
  4. If you apply hierarchy in both the data gathering phase and the decision phase you lose valuable input.
  5. Providing input but then not being part of the decision making phase is counterintuitive, you feel ignored. We'll have to accept that people listened to us but don't owe us an explanation to have fast decisions based on everyone's input.
  6. At GitLab, decision making is based on an informed and knowledgeable hierarchy, not on consensus or democracy. Voting on material decisions shows a lack of informed leadership.
  7. Make data driven decisions but 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."
  8. When making decisions, explicitly acknowledge the quality/quantity of the data that is available for the decision. Resist using poor data to justify judgement calls. It is ok to make a judgement call with limited data, but make sure that is known.
  9. When analyzing trends, never show cumulative graphs because they always look up and to the right even if business is bad.
  10. Be aware of your unconscious biases and emotional triggers.
  11. We don't have project managers except for working with external organizations. Individual contributors need to manage themselves. Not everyone will be able to do this effectively and fit our organization. Making someone responsible for managing others will cause negative effects to the results of the people that can manage themselves. If you manage yourself you have a much greater freedom to make decisions, and those decisions are based on deep knowledge of the situation. We want to retain the people that can handle that responsibility and therefore we can't retain the ones that struggle. Assigning a project manager/coordinator/case manager/etc. to something is an indicator that something is wrong and we are picking the wrong solution. 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 adopt to their style of working to make it successful. Also working along organizational boundaries is much harder to begin with.
  12. The person that does the work makes the decisions, they are the Directly Responsible Individual (DRI). They should listen to the data and informed opinions of others to arrive at their decision. Part of making good decisions is knowing who has good information and/or experience that informs that decision. Once a DRI has made a decision, Disagree, commit, and disagree
  13. A DRI may make a decision that results in (and is hence the cause of) negative feelings, but it is important to remember Collaboration is not consensus and People are not their work. While others are invited to contribute data and informed opinions during the decision making process, the DRI is not responsible for how they feel. When contributing supporting information to making a decision, it is the responsibility of the contributors to do so with data, use cases, historic examples, etc and not personal opinions or attacks.
  14. Short way to phrase this: 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).

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

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, but it should include the following elements:

  1. Options considered: what alternative approaches were considered, including the one that you recommend
  2. Recommendation: justification for why your preferred path was recommended over others. When apporopriate and possible, this should include a recommendation grounded in data
  3. 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 yes, revisit items and 1 and 2.

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
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
View page source — Edit in Web IDE — please contribute. Creative Commons License