Apple directly responsible individual practice
Use as a lens · Secondary reconstruction
A high-interest ownership idea with practical value, but one that should be presented with sourcing caution and translated as a lens, not as a proven Apple play you can copy from one page.
Best opened when
Teams that need sharper ownership language without overclaiming a famous company’s method.
This is an editorial translation of a weaker public record, not a claim of a fully documented canonical method.
What to steal first
The idea that one named person is accountable for moving a decision or deliverable to closure — not a team, not a committee, one person. That distinction is the useful part. Everything else is context.
What not to copy
DRI as a naming exercise in an organisation that doesn't back individual accountability with individual authority. Naming a DRI and then overriding them in committee produces accountability theatre, not clarity.
Closest move
Core claim
Sourcing note: The DRI concept is widely attributed to Apple but thinly documented in primary sources. This page is a translation based on secondary accounts — Ken Segall's Insanely Simple and Ken Kocienda's Creative Selection — not a claim of a fully documented canonical Apple method. The accountability logic described here holds regardless of its exact Apple lineage.
The Directly Responsible Individual concept is one named person who is accountable for a specific decision or deliverable reaching closure. Not the person who does all the work — the person who ensures it gets done and can answer, at any point, for its current state and direction.
The problem DRI addresses is the accountability diffusion that happens through politeness. In most organisations, "the team is responsible" is a sentence that protects everyone and commits no one. When something stalls or fails, the investigation involves figuring out who was supposed to own it — and the answer is usually "it fell between teams." DRI is the specific rejection of that pattern: one person, named, visible, responsible.
What transfers to any context is the accountability logic, not the Apple implementation. The useful move is applying the DRI question — "who is the one person responsible for this?" — to decisions and deliverables where ownership is currently distributed or unclear. What doesn't transfer is the cultural scaffolding that made it hold at Apple: deep leadership technical depth, small meetings by design, and a review culture that held individuals to account directly.
The accountability gap DRI addresses: Before DRI language — the team is responsible for the product launch. In the next status meeting, three people give partial updates from different angles. Nobody can answer "are we on track?" with confidence — the answer is always "we need to check with X." When something goes wrong, the investigation involves figuring out who was responsible. The answer is usually that it fell between teams.
After DRI language — Sarah is the DRI for the product launch. In any meeting, Sarah can speak to the full status because she's been tracking it. If she can't answer, she knows immediately who to call. When something goes wrong, the first question is "what did Sarah know and when?" — which creates a fundamentally different accountability dynamic.
DRI only produces the second scenario when the organisation also gives Sarah the authority to act on what she knows. Without that authority, she has accountability without power — which produces anxiety and game-playing rather than clarity.
Use it in a session
You leave with
One named person per decision or deliverable, with explicit clarity on what they own, what authority they have to act, and what the escalation path is if they can't get what they need to fulfill the responsibility.
First failure point: Naming a DRI and then overriding them in committee. If the DRI's decisions can be reversed by a group that didn't participate in making them, the DRI label is symbolic. Accountability without authority is not accountability — it's exposure.
What good looks like
How it worked there
Based on secondary accounts, the DRI concept at Apple operated inside three organisational conditions that are rarely present together elsewhere.
First, meetings were small by design. Ken Segall describes a culture where only the people who needed to be in a meeting were there — DRI supported this by making it clear who had what responsibility. Large meetings diffuse accountability by design; DRI requires the opposite.
Second, leadership evaluated work directly. When the person reviewing your work has the technical depth to assess it themselves, individual accountability is meaningful. In organisations where leadership evaluates by committee or relies on summaries, the DRI accountability chain breaks because nobody at the top can actually hold the DRI to account.
Third, the review culture rewarded individual craft. Both Segall and Kocienda describe a design and engineering culture where individual contribution was recognised and individual accountability was normal, not punishing. DRI fits naturally inside that culture. In cultures where political protection requires distributed responsibility, naming a DRI creates a target rather than a commitment.
What not to copy · Failure modes
Naming a DRI without giving them authority: The most common failure. The DRI is named and receives accountability for the outcome, but cannot make decisions about scope, resources, or priorities without committee approval. The label creates exposure without power. The DRI learns quickly that the accountability is real but the authority is not — and either escalates everything (because they can't actually decide) or avoids accountability (because the system penalises them for outcomes they couldn't control).
Using DRI to avoid the harder conversation about authority: In politically complex organisations, naming a DRI can feel like a resolution when it's actually a deferral. The naming happens, everyone nods, and the underlying authority question — who can actually make the decision that matters here — stays unresolved. When the DRI tries to exercise their accountability, the authority gap surfaces. The first time the DRI makes a call someone disagrees with, the committee convenes and the DRI discovers that 'responsible' meant 'to blame if it goes wrong,' not 'empowered to decide.'
Confusing DRI with contributor clarity: DRI answers 'who is accountable?' It does not answer 'what does everyone else do?' In teams where contributor roles are unclear, naming a DRI makes one person accountable for coordination failures they can't actually solve. DRI works best when paired with explicit clarity about what the DRI owns versus what others contribute — otherwise the DRI inherits all accountability for a system they don't control.
Weak signals to watch for
Closest Waypoint move
Primary route
Use this when the room needs a more grounded view of influence, ownership, and who actually moves the work.
Use this when you need a single named accountable person and can accept making informal influence visible in ways that may surface existing political structures.
situation
Use the situation route when missing ownership is blocking executive decisions in practice.
Sources and confidence
Secondary reconstruction
Apple
Ken Segall
Ken Kocienda
Reviewed by Discovery Waypoint Editorial Team · 2026-04-04
Apple