The DRI concept works phenomenally well.

Note, it’s just that — a concept. A simple tool to make ownership clear and point people with questions to the right place. It’s not a process or framework for project management.

With DRIs on everything from major initiatives to bug reports, a lot of questions of ownership are cleared up. In the minority of cases, it’s about accountability after something went wrong. The MobileMe screwup is one of those few examples where something goes poorly and then someone gets fired. More frequently, having a DRI helps you in the following situations:

• When solving a complex, cross-functional engineering issue, you want a DRI who is responsible for driving the team’s sleuthing until the issue is solved. Often this is an engineering lead or an engineering program manager. Say it’s mostly a mechanical engineering issue with a little bit of HW involved. Then usually a PD (product design) engineer will be the DRI, and they will work with the HW engineers to resolve the problem. If something keeps failing on the prototype testing lines, then you could have a TPM (test program manager) as DRI, working in conjunction with the Apple engineering teams, testing equipment vendor, and contract manufacturer teams.
• When it’s unclear who’s got the ball and what should be happening, everyone trusts that the DRI is driving. When you trust your DRI, you don’t have to worry when you don’t see any recent activity about that issue. You assume that they have figured out a dependency and are waiting on that to happen first, or that they are working on something behind-the-scenes that will prove useful. This is not only reassuring to other people working on the same issue, but it also helps cross-functional management gain clarity on who *exactly* is driving what. It’s not just “the marcomm team,” it’s a specific person.
• When everyone knows that something is important, but no one feels like it’s their responsibility to see it all the way through. In a fast-growing company with tons of activity, important things get left on the table not because people are irresponsible, but just because they’re really busy. The benefit here 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.

Obviously, I am a huge fan of the DRI model. It’s one of the most valuable, practical things I learned at Apple, and it’s a tool we use at Flipboard when it seems helpful.

Flipboard’s a startup, and we don’t have nearly as many formal processes as Apple does. Here’s how we have DRIs: We have a cross-functional team working on Android (frontend, backend, QA, product manager, marketing, design, BD, account management) with the eng lead as overall Android DRI. Similarly, we have a cross-functional team working on international, with a BD lead as the informal DRI. Neither of those people could do their jobs without the help of many other functional teams. But it helps to have a single DRI to call out an important piece of the big-picture we’re missing, to drive something to completion, and to be responsible for strategic decisions along with our CEO.