Directly Responsible Individuals (DRI)

Directly Responsible Individuals (DRIs) at GitLab own particular projects, initiatives, or activity.

What is a directly responsible individual?

Apple coined the term “directly responsible individual” (DRI) to refer to the ultimately accountable for the success or failure of a specific project, initiative, or activity. Originally coined by Apple, this approach ensures clear ownership and eliminates ambiguity about decision-making authority. Key principle: The DRI has final decision-making power but should consult and collaborate with relevant stakeholders to gather input and divide tasks effectively.

Empowering DRIs

  1. DRIs do not owe explanations for their decisions to avoid analysis paralysis
  2. They should welcome input from others but are not required to convince or justify their choices
  3. This prevents projects from “flying under the radar” due to fear of endless explanation cycles

Collaboration

  1. DRIs must consult with all relevant teams and stakeholders
  2. They should gather context, input, and feedback before making decisions
  3. While empowered to decide, they should leverage team expertise and judgment

DRIs and our Values

At the end of the day, it’s about results and efficiency. DRIs work conceptually because they leave no room for ambiguity about who has the final say on all questions that arise within a project or team.

Assigning one, ultimately responsible person to a project might seem to impair our ability to collaborate effectively at first glance, but that’s misleading. The DRI should be wholly invested in their assignment and welcome collaboration in order to succeed. While they’re empowered to make all final decisions, they should know how and when to trust in the experience and judgment of their teams and peers.

Characteristics of a Project DRI

DRIs are most often assigned at the task-level. For example, when building a new product feature the Product Manager is the DRI for the prioritization and the Engineering Manager is the DRI for delivery. As managers of one GitLab team members are most often the DRI for the tasks they accomplish.

The DRI is also part of a team, a team needs to be motivated and aligned on achieving the steps to get to success. The DRI will also be responsible for making sure the team gets there.

Communication and feedback

A DRI should be able to articulate the objectives, check progress and give and receive feedback. This will ensure the DRI can change direction or plan ahead to avoid any setbacks.

At GitLab we communicate and work asynchronously, you can read more about it on this page.

One thing to consider when a DRI needs to give or receive feedback is that they may not be the actual manager of the other members of the team.

Giving or receiving feedback is tough and we have looked at this in our previous Guidance on Feedback Training. See also GitLab’s guide to communicating effectively and responsibly through text.

DRI, Accountable, Consulted, Informed (DACI)

Different organizations use different methods of assigning responsibility; one of the most popular is the RACI Matrix, which outlines who the Responsible, Accountable, Consulted, Informed people should be on a decision or project.

GitLab’s implementation of a DRI for decision-making means that we have evolved the RACI matrix to DACI (DRI, Accountable, Consulted, Informed).

DRI (Directly Responsible Individual): Identifies one person who owns the outcome and has decision-making authority Focuses on accountability and speed of execution GitLab-specific concept that emphasizes individual ownership The DRI is empowered to make decisions and drive results Reduces decision-making bottlenecks by having clear ownership

DACI: A framework for clarifying roles and responsibilities

  • DRI: This is the person ultimately accountable for the successful completion of a specific task, decision, or project. They own the outcome and are the point person for that particular effort.
  • Accountable: The person who is ultimately answerable for the completion and success of the task. There should be only one person accountable for each task and it’s often the same as the DRI.
  • Consulted: These are individuals whose opinions and expertise are sought and valued before a decision or action is taken. They provide input and feedback, but they are not ultimately responsible for the outcome.
  • Informed: These individuals are kept in the loop about the progress and decisions related to a task or project, but they don’t necessarily need to be actively involved in the decision-making process. They are kept informed of the progress and outcome.

This framework helps avoid confusion and ensures that everyone understands their role and level of involvement. It’s a way to distribute responsibility and keep the project moving forward efficiently.

Circumstances Requiring the Rare Need for Approvals

There are circumstances where we do approvals for coordination or have a decision maker who is not the DRI. These are extremely rare. It is the responsibility of the DRI to recognize the need for this and to continue to move the project forward. Most of these circumstances will happen in instances in which initiatives:

  • Involve 3-or-more functions
  • Could have a large financial impact
  • Could present significant risk to the business
  • Have business reputation considerations
  • Have multiple success considerations (for instance, increase iACV through a product change AND maintain customer NPS)

Examples include:

  • A large cross-functional initiative that has significant reputational or financial implications for the GitLab and its users, such as a pricing initiative
  • The rollout of a major policy change that requires multiple functions to align on a coordinated response (for example, legal, marketing, finance), such as changes to the Terms of Service

In these instances, another person may own the final decision, but this doesn’t mean that key process steps should be skipped and other key stakeholders shouldn’t be involved in ensuring a successful outcome. If a DRI is not considering key stakeholder feedback, executing without adequately planning for success, and saying, “the E-Group approved this,” it is worth pausing and considering whether key steps are being missed or additional items should be considered. The DRI is still responsible for successful execution once a decision is made. If the DRI disagrees with a decision, it is this person’s responsibility to make a compelling case to the decision maker in order to change the decision maker’s mind. If this can’t be done within a reasonable period of time, the DRI should disagree and commit.