Why?

Apple coined the term “Directly Responsible Individual” (DRI) to ensure that for every project or feature, there’s one person ultimately accountable — someone who either gets it done or finds the resources to do so. This is what's known as the directly responsible individual (DRI)

The DRI can be anyone on the team — engineer, designer, or even a PM. It’s less about title and more about ownership. This person steps beyond task delivery to consider the “work around the work” — coordination, clarity, quality.

With the support of engineering leadership, the DRI is empowered to make decisions, resolve conflicts, and drive progress. They act as a tie-breaker when needed, but more importantly, they’re the glue ensuring impact.

Done well, this fosters a culture of accountability, where engineers are trusted to think beyond Jira tickets and take true ownership.

How?

A good place to define the DRI’s scope is within a Product Requirement Document (PRD) or a Request for Comments (RFC). These docs provide the canvas where the DRI outlines:

• What is being built

• Why it matters

• How it will be executed

• Key decisions and trade-offs

I will have a post in due course on how these may look but in principle this should be the one stop shop where the DRI has the space to articulate the how of what is being built and the decisions they've made to come to that conclusion.

The DRI should also be responsible for keeping stakeholders aligned — through regular updates, async check-ins, and surfacing risks early. This builds trust and confidence across the org.

Most importantly, the DRI should feel confident escalating blockers, navigating trade-offs, and collaborating across teams to keep things on track.

Let's look at a concrete example:

We assigned a mid-level engineer as DRI for revamping the CI pipeline. They didn’t do all the work, but they owned the outcome — aligning with platform engineers, triaging flaky tests, and communicating status to the team.

This minor mindset shift of "owning the outcome" is really important, it allows people to feel empowered to own the delivery of their impact to the business.

What now?

Start small. Try assigning a DRI for a single project and observe how it affects clarity and momentum. Before rolling it out widely, align the team on what this role is — and what it isn’t. You can even bake it into your team canvas to make it explicit.

DRIs are a small shift with big leverage. Next, we’ll look at how governance models and decision logs can support this kind of empowered ownership.

Bonus checklist

Here’s a default checklist I’ve used before — a solid baseline for what a DRI should own during a project.

🔹 Work before the work

• DRI is explicitly assigned and documented (e.g. in the PRD or RFC)
• Goals, scope, and success criteria are clearly understood
• Stakeholders are identified and aligned
• Risks or unknowns are surfaced early — a lightweight risk register works great here (more on that soon).
• Communication plan is agreed (e.g. weekly async updates, standups, Slack channel)
• Rollout plan is documented and a rollback in the event of an issue

🔹 Execution Phase

• Owns the roadmap and delivery milestones
• Makes decisions or escalates blockers proactively
• Keeps documentation updated (decisions, changes, status)
• Shares regular updates with stakeholders (sync or async)
• Ensures cross-functional alignment (e.g. design, product, data, infra)

🔹 Ensuring future technical and product health

• Project wrap-up shared with stakeholders (e.g. post-launch writeup or demo)
• Captures key decisions, learnings, and tradeoffs in a Decision Log or Postmortem
• Reflects on what went well and what could improve — brings that feedback into future DRI efforts (a dedicated retro can help here)