Important - this page is public

This page and its subpages are public.

Link to DRI Intro video

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.

Benefits of using DRI

One of the biggest benefits of using the DRI framework is that you always knows who’s ultimately in charge of moving an issue ahead.

When solving complex issues that span across multiple functions or teams, it’s easy for tasks to fall through the cracks, not progress, and left in a state where no one is pushing forward. With a DRI appointed to every task, you can always trust that the DRI is the one driving, and you don’t have to worry about what happens when an issue is stalling, or when collaboration is happening across teams.

Another situation sometimes occurs in fast-growing companies with a lot of activity. Important things get left on the table, not because people are irresponsible, but simply because they are so busy. Without a DRI, everyone might know about a task that is stalling, but they don’t really know who’s responsible for moving it forward, and will instead choose to focus on another task where it might be more clear.

The benefit of DRI in this case is more ownership than accountability. When you feel like something is your baby, then you really, really care about how it's doing. You will obsess over metrics and track down issues and rally people and want to do nice things for them when you achieve something great.

Having a DRI is also efficient for the team because you don't have fifteen people all worrying about the same things. Instead, an engineer can feel comfortable knowing that sometimes they simply show up and other people will tell them what to do, freeing them to focus on the challenge at hand. At other times, they will act as DRI and exercise more of their leadership muscles.

Empowering DRIs

Accountability and ownership as a DRI also comes with authority to make decisions. The DRI can look for information and advice, but in the end the DRI is the one who makes the decisions about the task at hand.

It is important to understand that DRIs do not owe anyone an explanation for their decisions, and they don’t have to convince other people about their decision. 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.

So how do we combine this with an open work culture?

Everyone can provide input, and decisions should be publicly made in issues or public slack channels. So everyone get’s to provide input, but no-one has the right to be considered in the decision, not even the opinion of the CEO. The decision making power ultimately rests with the DRI.

DRI and Collaboration

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.

How a DRI is selected

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 Tech Lead/Engineering Manager is the DRI for delivery. All team members are also most often the DRI for the tasks they individually accomplish.