The growing importance of directly responsible individuals in remote work culture

It’s really easy to get excited about a new project. But in a remote work environment, it’s even easier to find yourself weeks behind on a project and discover that nobody has taken the lead.

Long before remote work became the new normal, Apple realized this was a huge issue. In response, it developed the concept of the Directly Responsible Individual (DRI) to increase accountability across its product teams. Organizations around the world have emulated this model in the time since — and Levels is no exception.

But what exactly is a DRI? And why has this model become so critical to remote-first teams? Let’s take a closer look.

TL;DR

• A Directly Responsible Individual (DRI) can be anyone on a team who ensures that all stakeholders have the resources they need to complete a project
• DRIs are uniquely empowered to make decisions that ultimately decide the success or failure of a project
• The DRI model is incredibly important in an asynchronous culture, in which you lose in-person social interactions that might get a project back on track

What is a Directly Responsible Individual?

A DRI is, well, anyone who’s willing to step up and take responsibility for the success (or failure) of a project. While a DRI isn’t responsible for executing every facet of a project, they are charged with making decisions and ensuring that their teams have the resources they need to complete it.

At Levels, we give DRIs a directive to ship something, which we believe means one of the following four outcomes:

1. You successfully execute a project. This means that you and your team have completed a scope of work and have literally shipped something new.
2. You break the project into smaller parts. In this scenario, the DRI has defined new (and typically smaller) projects. After the DRI has assigned those projects across the team, that person has shipped a new concept.
3. You pause the project. This could be due to a lack of resources, conflicting priorities, or any other reason that the project needs to be put on hold. In this case, the DRI has shipped a clearer understanding of the resources required to complete the project.
4. You cancel the project.Sometimes shipping something means shipping nothing tangible. Instead, you’ll occasionally ship guidance for future considerations on similar projects.

The DRI is also where the proverbial buck stops. At Levels, we believe successful DRIs ship something from the list of outcomes above. We also believe that the DRI is responsible for ensuring their project stays on course and ships in a way that makes sense to everyone involved.

How is this a unique form of project management?

We alluded to this earlier, but the function of the DRI is unique because it’s not reserved for managers or team leads. Anyone is free to volunteer for the challenge — and this is especially the case at Levels.

On a weekly basis, we send out weekly requests for DRIs. To qualify, employees need to meet the following criteria:

1. They’ve already hit inbox 0 every day (which includes Threads, our internal messaging tool)
2. They have at least 10 hours of available capacity per week to take on a new project
3. Taking on a new project is not going to leave a gap somewhere else in the company

From there, our leadership team chats with each potential DRI to determine their bandwidth for taking on a project. At Levels, we leverage DRIs for specific project specs just as often as we do for ambiguous projects like a social media experiment.

We take this process seriously. Once a DRI is selected, that person is given a unique level of autonomy to get things done efficiently. And as we heard in a recent episode of A Whole New Level, this also means that a DRI will likely do very little of the actual work.

> “You might not be doing the work and you might not even be making all the decisions,” adds Ben Grynol, Head of Growth at Levels. “But you are responsible for the decisions that get made and you’re responsible for seeing through it that something gets shipped.”

Serving as a DRI can feel like high stakes. And in many cases, it adds an appropriate amount of pressure on DRIs to follow through and ship something. But as we and many other companies have seen, it’s critical to have someone in place to take accountability for both large and small projects — especially in a remote and asynchronous work environment.

Is a DRI essentially a product manager?

Since a DRI has a great deal of autonomy over a project, it would be easy to assume that people in this role are essentially product managers. When you look at a typical job description for a product manager, the differences between the two roles get even muddier.

At Levels, we recently established a couple of nuanced definitions for a DRI and product manager that we think are really important. DRIs are responsible for ensuring that a specific project ships. As we’ll explore later in this article, we employ DRIs for all types of projects, not just software or product-related initiatives.

And that’s where we’ve established the biggest differentiator between a DRI and a product manager. Product managers at Levels have the skills required to understand product-specific challenges that our customers face, develop a product vision to solve those challenges and create the strategy and roadmap that everyone across engineering and product will execute against.

We also believe that DRIs should not be put in a position where they have to learn on the job. As such, we spend a lot of time identifying DRIs that are great fits for the project(s) we’ve assigned them to oversee. On the flip side, we believe that product managers should do quite a bit of on-the-job training — and ultimately become responsible for getting the right products shipped to our users.

The types of projects DRIs oversee

When you research DRIs online, you typically find a lot of articles written by engineers or product managers. While the DRI model is popular among those teams, it’s not reserved exclusively for them. In fact, DRIs are important on virtually every project.

At Levels, DRI projects have ranged from new social media experiments, optimized approaches to shipping swag to our employees, and curating events with external speakers. Below, you’ll see an actual example of one of our curated events. You’ll notice there were a lot of speakers. Without a DRI in place, it’s difficult to see how this project would have ever shipped.

Could our swag and speaker series projects shipped without a DRI? Maybe. But these initiatives (and many others like them) would have been much more challenging without someone in place to ensure that everyone involved had the resources they needed to get the project out the door.

Why DRIs are essential in a remote and asynchronous culture

There are a lot of advantages to remote work culture. Organizations can recruit around the world to find the right talent. Employees get an unprecedented amount of flexibility over their schedules. We’ve heard these things repeatedly over the last couple of years.

What’s easy to forget though is what we lose in asynchronous environments. One of the biggest losses? The casual interactions we have with colleagues in the office — and many of us have been reminded about a project or deliverable while grabbing coffee in the kitchen.

Without these opportunities to bump into teammates, the DRI model becomes even more critical to the success of each project across your company.

> “We found that because we have such long uninterrupted work hours [as remote employees], things were just kind of falling through the cracks,” says Scott Klein, Head of Product at Levels. “[Even worse], we weren’t noticing for weeks or months at a time.”

While you might be able to overcome a lack of project management in an office setting, it’s uniquely challenging in an asynchronous environment. Klein says that while you might get verbal cues in the office that a project is on track or should be retired, it’s impossible to pick up on these nuances in a remote setting.

“[Everything] becomes a lot easier and more transparent across the entire company when there isn’t ambiguity around who the point person is for a project,” Klein continues. “[Without the DRI], projects get really muddy in a remote environment.”

How we’ve tweaked the DRI model at Levels

We’ve shared a few ways that Levels have tweaked the DRI model to suit our company. From redefining the responsibilities of the DRI to the guardrails we’ve built to support each point person, let’s unpack a few more ways we’ve customized the concept of the DRI.

A DRI buddy system

We’ve found this to be particularly helpful for new DRIs. After all, it’s a tall task to assume this level of ownership over any project — and our ultimate goal is to give DRIs the tools they need to be successful in the role.

Anyone who has served as a DRI for one or more projects is eligible to serve as a buddy. This step is optional for DRIs at Levels, but many folks across the company have leaned on their colleagues for the following:

• Help getting unstuck when they’re unsure where to get alignment or clarity from stakeholders
• Coaching and emotional gut checks to ensure that DRIs aren’t over or under communicating
• Examples of successful stints as DRIs to draw inspiration from

Identifying and documenting all stakeholders

Every DRI at Levels is required to identify all the stakeholders they anticipate working with to complete the project. We define stakeholders as people whose input is required in order to get a product shipped.

Why do we ask DRIs to do this upfront? We’ve seen several instances where the “easiest” or “best” decision from the DRI’s standpoint might create massive roadblocks that derail the timeline of the project. While the DRI accepts accountability for whether or not a product ships, stakeholders are responsible for ensuring that short-term improvements don’t lead to long-term issues.

Identifying and documenting all functional leads

As we discussed earlier, DRIs don’t do all the tactical work to get a project shipped. But one area of heavy lifting for a DRI is knowing who owns each functional area of that project.

For our product team, that means identifying and documenting engineering, design, and support leads for each project. We consider this the bare minimum for any project that impacts our members. A DRI for any project that meets these criteria needs to identify execution leads for these three areas before proceeding.

Weekly and ad-hoc reporting on outcomes

While the DRI’s ultimate goal is to ship something, we hold them responsible for reporting on the progress of their project. Once a project scope is approved, we ask DRIs to provide weekly progress updates on our Friday Forum. Typically, these updates represent major progress in design, engineering, or member adoption.

DRIs are also responsible for ad-hoc reporting when they come across a blocker or resource interruption. These updates are done directly in Threads and Notion and DRIs tag anyone who might be able to unblock the project. In extreme circumstances, DRIs are asked to send a text message to one of our executives.

Finally, DRIs on high-priority projects provide daily progress updates. Since these projects tend to impact so many employees and users, we believe frequent updates alleviate a lot of anxiety across the organization and show everyone that tangible progress is being made.

A formal debrief after the completion of each project

If a product ships, it’s time to celebrate, right? Not so fast.

That’s why we ask our DRIs to schedule debrief calls with Klein or David Flinner, Co-founder of Levels. During this recorded session, DRIs give feedback about the execution of the project and are asked for suggestions to improve the DRI process. It’s also during this call that both the DRI and someone from leadership determine if any next steps are still outstanding.

At this point, we also ask DRIs to determine whether or not to iterate on the project — continue it on for another cycle of learning — or retire it as project debt. This is a pretty nuanced task. For example, a project that we deem successful might be marked as iterative because we want to learn more, but can also be retired because the cost of continuing is too high. Likewise, a failed project could be marked as iterative because we determine that we want to learn more about what went wrong.

From here, the DRI has a few things to do before moving on to another project. First, many projects require additional follow-up with our support team to determine if they met the success criteria that the DRI defined in the original product spec. Before putting a final bow on this project, the DRI is responsible for ensuring that any remaining tasks have been assigned to other team members.

The DRI process at Levels will continue to evolve over the years. But we’ve long believed in the benefits of asynchronous work and have no plans to change that approach. As we continue to grow, it’s no secret that the DRI model will play a significant role in the success of not just our product-driven teams, but the entire business.

What Levels does—and why

Inside Levels