DRI & Written Norms

DRI (Directly Responsible Individual) is the simplest — and arguably most powerful — responsibility model. Originated at Apple under Steve Jobs, it has only one rule: for any given thing, exactly one named person owns it. No matrix. No roles. Just: this is yours. Paired with written-first norms (inspired by Amazon's 6-pager culture and GitLab's handbook practice), DRI becomes the organizing principle of mature async-first organizations.

This subtopic covers the specific mechanics of making DRI work in writing-heavy environments, and the written norms that prevent it from degenerating into blame assignment.

Origin

DRI at Apple

The DRI model was institutionalized at Apple in the early 2000s during Steve Jobs's second tenure. The concept was simple: in any meeting, any document, any project, the "Directly Responsible Individual" is named next to each item. If you see your name next to a deliverable, it is yours to ship — not to coordinate, not to share, to ship. Coordinating with others is part of your job; ownership does not diffuse.

The model became widely known outside Apple through accounts like Fortune's "How Apple Works" (2011) and Adam Lashinsky's Inside Apple (2012). It has since been adopted at companies like Stripe, Square, Asana, and many smaller tech companies that appreciate its ruthless simplicity.

Written Norms at Amazon & GitLab

Amazon's ban on PowerPoint (2004) was a written-norm move. GitLab's 2,000-page public handbook is the largest single artifact of written-first culture. Both reflect the same underlying claim: writing scales; meetings don't. In a 1,000-person company, meetings can only ever coordinate tiny subsets; writing can be accessed by all.

The DRI Model

The Rule

For any thing that needs to happen, name one person. Full stop.

The "thing" can be:

- A decision  (who decides)
- A deliverable  (who ships)
- A process  (who owns it)
- A question  (who finds the answer)
- An escalation  (who resolves it)
- A document  (who maintains it)
- An incident  (who runs the response)

Why One Person

Two owners = zero owners. When responsibility is shared:
  - Each assumes the other will handle it
  - Neither is accountable when it fails
  - Neither has clear decision authority
  - Decisions take longer because of coordination overhead

The DRI can collaborate, delegate, and consult. They can build a team. But when the buck stops, it stops at them, by name.

What the DRI Does

The DRI:
  - Shapes the problem
  - Makes or escalates decisions
  - Drives to completion
  - Communicates status
  - Is accountable for outcomes

The DRI is NOT:
  - The only one working on it
  - A dictator
  - Isolated from input or dissent
  - Immune from escalation

What Good DRI Culture Looks Like

1. Every initiative has a named DRI, visible in writing.
2. The DRI has authority proportional to their accountability.
3. The DRI is supported (mentorship, resources, escalation paths).
4. Changes to DRI are explicit, not drift.
5. DRIs can say no; they have strategic leverage, not just
   operational responsibility.

Tech & Company Example: DRI Assignment

Project: Migrate from MySQL to Postgres across 20 services.

Poor DRI (diffused):
  "The platform team will lead the migration, with the backend
   team supporting, and individual service owners handling their
   own cutover."

Result: nobody is accountable for the overall timeline. Each
service cuts over on its own schedule; some never do.

Better DRI (named):
  Overall DRI:            Priya (staff engineer, platform team)
  Per-service DRIs:       Each service's tech lead
  Data verification DRI:  Jordan (data engineering)
  Rollback plan DRI:      Sam (SRE)

  Priya's job: hold the overall schedule, unblock per-service DRIs,
  escalate when services slip.

  Per-service tech lead's job: land their cutover by the agreed date.

  If the program slips, the question is clear: "What did Priya do to
  unblock the slipping service?" and "Why did that service's lead
  miss their commitment?"

With named DRIs, problems surface early because someone owns noticing them.

Written Norms

DRI works best in a written-first culture. Here are the specific norms:

The Doc Is the Decision

Principle: A decision does not exist until it is in writing.

In practice:
  - Decisions made in meetings are recorded within 24h.
  - The record is in a known, linkable location.
  - The decision is a named document (ADR, memo, handbook page),
    not a Slack message.

Written Before Sync

Principle: If a meeting is needed, the context/proposal is written
           and distributed beforehand.

In practice:
  - Agendas are required, not optional.
  - 24-hour minimum distribution window.
  - If people haven't read, the meeting starts with silent read
    (Amazon-style) or is rescheduled.

Linkable Everything

Principle: Every decision, process, and norm has a linkable URL.

In practice:
  - Handbook pages, not tribal knowledge.
  - "Where's the rule on X?" has an answer everyone can find.
  - New hires can onboard by reading, not by interrogating colleagues.

Public by Default

Principle: Within-company communication defaults to public channels;
           DMs and private docs are exceptions.

In practice:
  - Public Slack channels preferred to DMs.
  - Shared drives preferred to personal drives.
  - Repositories open internally even for code not your own.
  - Exceptions: HR, compensation, legal, genuinely private matters.

Low-Context Writing

Principle: Writing assumes the reader is not in the last 10 conversations.

In practice:
  - Explicit titles, not context-dependent ones.
  - Named people, not pronouns.
  - Date stamps on decisions ("as of 2026-04").
  - Linked background, not inlined summaries.

Opt-In Notifications

Principle: The cost of notification falls on the sender, not the
           recipient. Default: no notification.

In practice:
  - Channels people can join, not add-to-everyone.
  - Tags used intentionally, not reflexively.
  - Status and focus time respected.

DRI + Written Norms in Action

A typical workflow combining DRI and written norms:

1. Problem identified by anyone.

2. DRI named for the problem (self-appointed, assigned, or
   volunteered).

3. DRI writes a proposal doc (1-pager to RFC depending on stakes).
   The doc names:
     - The problem
     - The proposed solution
     - Alternatives considered
     - DRIs for sub-components
     - Timeline and decision date

4. Doc is published to a public channel with "feedback by [date]".

5. Stakeholders comment async. DRI incorporates or explicitly
   rejects feedback (with reason).

6. On decision date:
     - DRI makes the call (if the decision was delegated to them).
     - Or DRI escalates to the decision owner.
     - Or a 30-min meeting (if async discussion hasn't converged).

7. Decision recorded in an ADR. DRI is named. Timeline is committed.

8. DRI drives execution. Weekly async updates in the public channel.

9. If blocked, DRI escalates in writing (not in a hallway).

10. On completion, DRI publishes a closeout doc: what was done,
    what was learned, what's now true in the world.

This workflow is what "async-first with DRI" looks like in practice. It replaces coordination meetings with artifacts, and replaces ambiguity with named ownership.

When It Works

Teams and orgs with strong writing culture
Distributed teams where sync is expensive
Engineering-heavy orgs where decisions benefit from durability
Fast-moving teams that need clear ownership to avoid paralysis
Any environment where "who's on this?" is a frequent question

When It Does Not Work

Cultures that penalize autonomy — If DRIs cannot actually make decisions, DRI is a lie. Needs authentic delegation.
Organizations that don't read — Writing that no one reads is worse than useless. Cultural shift required.
Low-trust environments — DRI concentrates risk on one person. If the culture blames individuals rather than systems, people avoid DRI assignments.
Flat consensus cultures — Some cultures explicitly value shared decision-making. DRI needs to be layered carefully or it feels authoritarian.

Common Failure Modes

DRI-Specific

Phantom DRI — Named DRI who doesn't actually have authority or engagement. Formal but hollow.
Overloaded DRI — Same person as DRI on 8 things. Effectively no DRI on any of them.
Moving DRI — DRI changes every two weeks as work reshuffles. Never stable enough to hold accountability.
DRI as Scapegoat — Using DRI assignments as pre-assigned blame. People avoid DRIs. System becomes defensive.
DRI-Without-Support — Named DRI with no mentor, no escalation path, no resources. Set up to fail.
Dictator DRI — DRI interpreted as "I decide everything, don't consult." Bad decisions result from lack of input.

Written-Norm Specific

Write-Only Culture — Things are written but nobody reads them. Handbook grows, nothing improves.
Wall-of-Text Norms — Writing is verbose and unreadable. Effective async requires disciplined writing.
Handbook Tyranny — Every decision requires a handbook update before it can move. Overhead exceeds benefit.
Obsolete Docs — Handbook gets out of sync with reality. Readers stop trusting it. Culture regresses to tribal knowledge.
Documentation Without Decision — Things are discussed in docs but never converged on. Infinite comments, no close.
Public Everything (Including Harmful) — Making everything public without privacy distinctions causes real harm in specific cases (HR, compensation, personal issues).

Cross-Cutting

Async-as-Passive-Aggressive — Using written channels to avoid confronting someone synchronously on something that genuinely needs sync.
Async-as-Blame — "I wrote it in the doc, you should have read it" — used to justify lack of coordination or communication.
Plausible Deniability — Written trails are used to cover self rather than advance work. People write for the record, not for readers.
Handoff Gap — Written handoff from A to B is incomplete; B starts work missing critical context A assumed was obvious.

RAPID, DACI, RACI — Matrix-based alternatives to DRI; more structure, more overhead. Appropriate for cross-functional decisions.
Apple DRI — The canonical DRI; the simplest possible model.
Stripe written-culture — Stripe is famous for written-first culture with DRI overlay; their engineering blog occasionally describes this.
GitLab Iteration — GitLab's flavor of async-first writing + DRI; publicly documented.
Amazon 6-pager — Written-decision culture with clear single-thread leader per program.
Shape Up (Basecamp) — Appointments a DRI-like figure for each "pitch" that gets funded in a cycle.