Apple's DRI: The Simple Rule That Eliminates Confusion and Drives Accountability

You’re in a meeting at Apple.

The agenda has 12 items.

Next to each item is a name.

iOS notification improvements: Sarah Chen

Battery optimization: Marcus Rodriguez

App Store review process: Jennifer Wu

That name isn’t the person who does all the work.

It’s the person who is directly responsible for that outcome.

One person. Completely accountable.

Not a committee. Not a team. One person.

If it succeeds, they get credit. If it fails, it’s on them.

No shared responsibility. No diffusion. No confusion.

This is Apple’s DRI model: Directly Responsible Individual.

It’s arguably the simplest and most powerful concept in this entire list.

What Is DRI?

DRI = Directly Responsible Individual

The rule:

Every project, every initiative, every decision, every meeting agenda item has exactly one person who is accountable for the outcome.

Not:

• “The engineering team is responsible”
• “We’ll figure it out as a group”
• “Everyone owns this”

But:

• “Sarah is the DRI for this project”
• Clear, singular accountability

How Apple Uses DRI

In Meetings

Apple’s meeting agendas look like this:

Weekly Product Review
Date: Feb 21, 2025

1. iOS 18 notification system          DRI: Sarah Chen
2. Battery life improvements            DRI: Marcus Rodriguez
3. App Store policy updates             DRI: Jennifer Wu
4. AirPods firmware bug                 DRI: David Park
5. Marketing campaign Q2                DRI: Lisa Thompson

Notice:

Every single item has a name next to it.

That person:

• Knows they’re accountable
• Comes prepared
• Makes decisions
• Owns the outcome

No ambiguity. No “we’ll take this offline.”

If there’s no DRI, the item doesn’t go on the agenda.

In Projects

Traditional companies:

“The team will redesign the checkout flow.”

Who’s responsible?

• Product manager?
• Tech lead?
• Designer?
• All of them?
• None of them?

Apple:

“Marcus is the DRI for checkout redesign.”

Now everyone knows:

• Marcus makes final calls
• Marcus coordinates the team
• If it’s late, Marcus is accountable
• If it’s great, Marcus gets credit

In Cross-Functional Work

The problem with cross-functional work:

Multiple teams, unclear ownership.

Example:

A new feature requires:

• Backend engineering
• iOS engineering
• Design
• Product management
• QA

Who’s responsible?

Traditional answer: “It’s a cross-functional effort.”

Translation: No one is responsible.

Apple’s answer: “Sarah is the DRI. She coordinates everyone, makes trade-offs, owns delivery.”

Sarah doesn’t do all the work. But she’s accountable for the outcome.

The Psychology Behind DRI

Why “Everyone Is Responsible” Fails

Classic study (Latané & Darley, 1968):

Researchers staged emergencies (smoke, someone having a seizure).

Finding:

When ONE person was present, they helped 85% of the time.

When MULTIPLE people were present, individuals helped only 31% of the time.

Why?

Diffusion of responsibility: “Someone else will handle it.”

The same thing happens in organizations:

“Everyone owns quality” = No one owns quality.

“Everyone owns customer experience” = No one owns customer experience.

The DRI model eliminates diffusion.

Why Single Accountability Works

With a DRI:

• Decisions get made (one person decides)
• Progress is trackable (ask the DRI)
• Accountability is clear (no finger-pointing)
• Outcomes improve (skin in the game)

Real-World Examples from Apple

Example 1: The iPhone Launch

The story:

When the iPhone was being developed, Steve Jobs assigned Scott Forstall as the DRI for iOS.

Not: “The software team will build the OS.”

But: “Scott, this is yours. iOS succeeds or fails on you.”

What this meant:

• Forstall coordinated with hardware, design, product
• Made tough trade-offs (cut features to hit deadlines)
• Took heat when things went wrong
• Got credit when iOS became legendary

One person. Clear accountability.

Example 2: App Store Guidelines

Every policy decision has a DRI.

Example:

“Should we allow apps to access user location in the background?”

Traditional company:

• Committee discusses
• Stakeholders weigh in
• Consensus takes months
• No clear decision

Apple:

• Jennifer is DRI for App Store privacy policies
• She gathers input
• She makes the call
• Decision is final

Fast. Clear. Done.

Example 3: Bug Fixes

Apple’s bug tracker:

Every bug has a DRI assigned.

Not: “Someone should fix this.”

But: “David, this crash in Safari is yours.”

David:

• Owns the investigation
• Coordinates with QA and infra teams
• Makes the fix
• Ensures it’s deployed

No orphaned bugs. Every bug has a human attached to it.

How DRI Eliminates Common Problems

Problem 1: “Who’s Handling This?”

Without DRI:

“Hey, what’s the status of the API migration?”

“Uh, I think Engineering is working on it?”

“Which engineer?”

“Not sure. Let me ask.”

With DRI:

“Hey, what’s the status of the API migration?”

“Ask Marcus. He’s the DRI.”

One question. One answer.

Problem 2: Decisions That Never Get Made

Without DRI:

“Should we support dark mode?”

“Let’s discuss in next week’s meeting.”

Next meeting: “Let’s get more input.”

Next meeting: “Let’s table this for now.”

Months pass. No decision.

With DRI:

“Should we support dark mode?”

“Sarah is the DRI. Sarah, what’s your call?”

“Yes. We ship it in Q2.”

Done.

Problem 3: Finger-Pointing

Without DRI:

Launch goes badly.

“Why didn’t QA catch this?”

“Why didn’t Engineering fix it?”

“Why didn’t Product prioritize it?”

Everyone blames everyone. No one takes ownership.

With DRI:

Launch goes badly.

“Marcus was the DRI. Marcus, what happened?”

No ambiguity. Marcus owns it.

(Note: This doesn’t mean blame. It means clarity. Marcus can explain root causes, but accountability is clear.)

Problem 4: Slow Progress

Without DRI:

“We need to decide on the database schema.”

“Let’s schedule a meeting.”

“Let’s get consensus from all stakeholders.”

“Let’s revisit next sprint.”

Weeks of delay.

With DRI:

“We need to decide on the database schema.”

“Marcus is the DRI. He’ll decide by EOD tomorrow.”

Fast.

DRI ≠ Doing All the Work

Common misconception:

“DRI means you do everything yourself.”

Wrong.

DRI means you’re accountable for the outcome, not that you do all the work.

Example:

Project: Redesign the search feature

DRI: Sarah

Team:

• 3 engineers
• 1 designer
• 1 product manager

Sarah’s role:

• Coordinate the team
• Make final decisions on trade-offs
• Ensure it ships on time
• Own the outcome

Sarah doesn’t code it all herself.

But if it’s late or buggy, it’s on Sarah.

If it’s great, Sarah gets credit.

How to Implement DRI in Your Company

Step 1: Start with Meetings

Action:

For every agenda item, assign a DRI.

Before:

Agenda:
1. Discuss API performance issues
2. Review Q2 roadmap
3. Update on hiring

After:

Agenda:
1. API performance issues          DRI: Marcus
2. Q2 roadmap review              DRI: Sarah
3. Hiring update                  DRI: Jennifer

What changes:

• Marcus knows he needs to prepare
• No one else can say “not my problem”
• Decisions get made faster

Step 2: Assign DRIs to Projects

Action:

Every project gets one DRI.

Example:

Rule:

If there’s no DRI, the project doesn’t start.

Step 3: Make It Visible

Put DRIs everywhere:

• Project tracking tools (Jira, Linear, Asana)
• Wiki pages
• Slack channels (channel description: “DRI: Sarah”)
• Meeting agendas
• Email threads

Why:

Makes accountability impossible to ignore.

Step 4: Clarify What DRI Means

Train your team:

DRI means:

• You make final decisions
• You coordinate the team
• You own the outcome
• You’re accountable (not blamed, but accountable)

DRI doesn’t mean:

• You do all the work
• You ignore input
• You have unlimited authority
• You take the fall for system failures

Step 5: Leadership Models It

Executives should be DRIs too.

Example:

This shows:

DRI isn’t just for junior people. It’s for everyone.

Common Mistakes

Mistake 1: Multiple DRIs

Wrong:

“Sarah and Marcus are co-DRIs for this project.”

Problem:

This is just shared responsibility with a fancy name.

Right:

“Sarah is the DRI. Marcus supports.”

One person. Always.

Mistake 2: DRI Without Authority

Wrong:

“You’re the DRI, but you need VP approval for every decision.”

Problem:

If they can’t make decisions, they’re not truly responsible.

Right:

“You’re the DRI. Make decisions within these guardrails. Escalate only when needed.”

Give DRIs real authority.

Mistake 3: Blame Culture

Wrong:

“The project failed. Fire the DRI.”

Problem:

This makes people avoid being DRIs.

Right:

“The project failed. What did we learn? What should the DRI do differently next time?”

Accountability ≠ Blame.

Mistake 4: No DRI for Small Stuff

Wrong:

“We don’t need a DRI for small tasks.”

Problem:

Small tasks still fall through the cracks.

Right:

“Even small tasks have a DRI. Takes 5 seconds to assign. Saves hours of confusion.”

Mistake 5: DRI Is Always the Most Senior Person

Wrong:

“The VP is always the DRI.”

Problem:

Bottleneck. VP can’t scale.

Right:

“The DRI is whoever is best positioned to own this outcome.”

Junior engineer can be DRI for a bug fix.

Senior exec can be DRI for company strategy.

Assign based on fit, not rank.

What About Shared Work?

Common pushback:

“Our work is collaborative. We can’t have one person responsible.”

Response:

Collaboration and accountability aren’t opposites.

Example:

Project: Redesign homepage

Team:

• Designer (creates mockups)
• Frontend engineer (implements)
• Backend engineer (API integration)
• Product manager (defines requirements)

Who’s the DRI?

Option A: Product manager

PM coordinates, makes trade-offs, owns delivery.

Option B: Frontend engineer

Engineer owns implementation, coordinates with PM and designer.

Either works. Just pick one.

The team still collaborates.

But one person is accountable.

DRI in Different Contexts

In Startups

Perfect fit.

• Fast decisions needed
• Clear ownership critical
• Everyone wears multiple hats

Example:

Even with 5 people, assign DRIs.

In Large Companies

Still works, but needs structure.

• More DRIs (more projects)
• Clearer escalation paths
• Document decision-making authority

Example at 500-person company:

Each DRI may have sub-DRIs reporting to them.

In Open Source

DRI model is everywhere in successful open source projects.

• Linux kernel: Linus Torvalds (DRI for releases)
• Subsystems: Each has a maintainer (DRI for that subsystem)
• Features: Each PR has an owner

Not a committee. Clear owners.

The Broader Principle

DRI is simple:

One person. Clear accountability.

But it’s based on a deeper insight:

Clarity drives performance.

When everyone knows:

• Who’s responsible
• Who makes decisions
• Who to ask

Things move faster. Confusion disappears. Work gets done.

DRI is a forcing function for clarity.

Comparing DRI to Other Models

DRI vs. RACI Matrix

RACI:

• Responsible
• Accountable
• Consulted
• Informed

Problem with RACI:

Separating “Responsible” and “Accountable” creates confusion.

DRI simplifies:

One person is both responsible and accountable.

DRI vs. Team Ownership

Team ownership:

“The backend team owns the API.”

Problem:

Who on the team?

DRI:

“Marcus owns the API. He coordinates the backend team.”

Clearer.

DRI vs. Committees

Committees:

“The architecture committee will decide.”

Problem:

Slow. Consensus-driven. No single throat to choke.

DRI:

“Sarah is the DRI for this architecture decision. She’ll gather input and decide.”

Faster.

Key Takeaways

• DRI = Directly Responsible Individual - One person accountable
• Every project, meeting item, decision has a DRI - No exceptions
• DRI doesn’t mean doing all the work - Means owning the outcome
• Eliminates diffusion of responsibility - No “someone should handle this”
• Fast decisions - One person decides (with input)
• Clear accountability - No finger-pointing
• Simple and powerful - Easy to implement, massive impact
• Works at any scale - Startups to large enterprises

Most management concepts are complex.

OKRs. Scrum. Matrix organizations. Holacracy.

DRI is the opposite.

It’s one simple rule:

Every outcome has exactly one person who is accountable.

That’s it.

No frameworks. No certifications. No consultants needed.

Just clarity.

And clarity is powerful.

Implement DRI today:

1. Pick 3 ongoing projects
2. Assign one person as DRI for each
3. Make it visible

Watch what happens.

Decisions get faster.

Confusion disappears.

Work gets done.

Because everyone knows who’s responsible.

And that changes everything.