Apple coined the term "directly responsible individual" (DRI) to refer to the one person with whom the buck stopped on any given project. The idea is that every project is assigned a DRI who is ultimately held accountable for the success (or failure) of that project.
They likely won't be the only person working on their assigned project, but it's "up to that person to get it done or find the resources needed."
The DRI might be a manager or team leader, they might even be an executive. Or, they may themselves be individually responsible for fulfilling all the needs of their project. The selection of a DRI and their specific role will vary based on their own skillset and the requirements of their assigned task. What's most important is that they're empowered. We may disagree, commit, and disagree, but we all have to achieve results on every decision while it stands, even when if trying to have it changed.
While the DRI is the individual who is ultimately held accountable for the success or failure of any given project, they are not necessarily the individual that does the tactical project work. The DRI should consult and collaborate with all teams and stakeholders involved to ensure they have all relevant context, to gather input/feedback from others, and to divide action items and tasks amongst those involved.
It is important to understand that DRIs do not owe anyone an explanation for their decisions. If you force a DRI to explain too much, you'll create incentives to ship projects under the radar. The fear of falling into a perpetual loop of explaining can derail a DRI, and cause people to defer rather than working with a bias for action.
We would much rather foster a culture where DRIs are willing to put their ideas in the open. This enables feedback from a broad range of diverse perspectives, which the DRI can take into account and choose how (if at all) it shapes their thinking.
As part of a Harvard Business School case study interview (shown above), GitLab co-founder and CEO Sid Sijbrandij spoke with Professor Prithwiraj Choudhury on various elements of GitLab's all-remote structure, including a question on DRIs.
How do we get the best of consensus organizations? When we're about to make a decision, we tell everyone. Everyone can give input.
How we keep the best of hierarchical organizations is by having a DRI — one person who will decide.
Now, there's one tricky thing here. If you make the DRI convince or explain their decision too much to all the people who provided input, you'll get projects that fly under the radar. I've seen this in a lot of companies.
Very explicitly, a DRI [at GitLab] does not have to explain why they're making a decision, and they absolutely do not have to convince other people.
So, you get to provide input, but you don't have the right to feeling heard or being considered in the eventual decision.
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.
Of course, when things do go wrong, it's also the DRI who (usually) takes the fall as was the case when Scott Forestall, then iOS senior vice president, was forced to resign after he "refused to sign the letter apologizing" for Apple's infamously error-laden Maps app redesign in 2011.
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.
At times, someone may be a DRI for an entire process or project. Because this comes with additional responsibility, there are some suggested characteristics to keep in mind when assigning the DRI. Mike Brown in his November 2015 article, Project Management – 8 Characteristics of a DRI, lists the following:
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.
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.
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 DCI (DRI, Consulted, Informed).
The Responsible and Accountable person is the DRI, the Consulted people are those whose opinions are sought, typically subject-matter experts; and with whom there is two-way communication. and Informed people are those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication. Given that Everyone Can Contribute, Informed people also includes Everyone.
The DRI should be sure to Consult with all teams that have actions to take on an initiative to ensure they have all context and that actions are appropriately divided.
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:
Examples include:
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 marker's mind. If this can't be done within a reasonable period of time, the DRI should disagree and commit.
