Responsibility Matrices: RACI, DACI, RAPID & DRI

Responsibility matrices answer the question every project eventually faces: who exactly is on the hook for this? Without a shared answer, decisions stall, work falls through the cracks, and accountability diffuses across the team. This subtopic covers the four most common matrices in tech companies — RACI, DACI, RAPID, and DRI — each tuned to a different type of work.

Decision lifecycle: roles, artifact selection by stakes, async review, and recorded decision

Origin

RACI — Originated in project management in the 1950s-60s, formalized in the Project Management Institute (PMI) body of knowledge. Widely used in consulting, ops, and large-program management.
DACI — Developed at Intuit in the 1980s specifically for product and software decisions. More lightweight than RACI and better tuned to fast-moving environments.
RAPID — Created by Bain & Company for complex decisions with many stakeholders. Designed to separate decision rights from input rights, addressing the "too many cooks" problem in big organizations.
DRI (Directly Responsible Individual) — Popularized by Apple under Steve Jobs. The most minimal of the models: one name per thing, full stop.

Each model is a reaction to a specific organizational failure mode. Together they cover most of the useful ground.

The Frameworks

RACI

R - Responsible: Does the work
A - Accountable: Owns the outcome (one person only)
C - Consulted:   Gives input before decisions
I - Informed:    Notified of outcomes

Classic RACI is built as a matrix of tasks vs. people:

| Task                     | Priya | Sam  | Jordan | Leadership |
|--------------------------|-------|------|--------|------------|
| Design the API           | A     | R    | C      | I          |
| Implement the backend    | A/R   | R    | -      | -          |
| Security review          | I     | I    | A/R    | -          |
| Launch announcement      | C     | C    | -      | A/R        |

Key rule: each row must have exactly one A (Accountable). Multiple A's are the #1 RACI failure mode.

DACI

D - Driver:   Drives the decision forward, sets agenda, owns the process
A - Approver: Makes the final call (usually one person)
C - Contributors: Provide expertise, input, options
I - Informed:  Notified of the decision once made

DACI is better for decisions (vs. RACI which is better for tasks). The Driver is not the Approver — this is the key distinction.

Example: Migrating from REST to gRPC

D: Staff engineer (runs the eval, writes the RFC, calls the meeting)
A: VP Engineering (makes the final call to adopt or not)
C: Backend lead, SRE lead, Mobile lead (each gives input)
I: Rest of the engineering org (notified once decided)

RAPID

R - Recommend: Proposes the option(s)
A - Agree:     Must agree for the decision to stand (veto power)
P - Perform:   Executes the decision
I - Input:     Provides information and opinions
D - Decide:    Makes the final call

RAPID decouples who decides from who can block, which is essential for decisions that cross functional boundaries.

Example: Launching a product in a new country

R: Product lead      (recommends go/no-go and scope)
A: Legal, Compliance (must agree — regulatory veto power)
P: Engineering, Ops, Marketing (execute if greenlit)
I: Sales, CS, Finance (provide market intel, cost input)
D: GM or CEO         (makes the call)

The power of RAPID is the "A" — it names the blockers explicitly so they are engaged early rather than surprised late.

DRI (Directly Responsible Individual)

DRI: One named person, per thing, full stop.

No matrix. No roles. Just: for any given thing, there is one person whose name is next to it, and that person owns it until it is done.

Example:
  - Login page redesign:     DRI = Sam
  - SLO dashboard v2:        DRI = Jordan
  - Q4 launch messaging:     DRI = Priya

DRI is the minimum viable responsibility model. It works best when everyone understands that "DRI" includes coordinating with others — it is not a license to go solo.

How to Choose Between Them

Situation                                     Best fit
------------------------------------------------------------
Long-running project with many tasks          RACI
Single technical or product decision          DACI
Cross-functional decision with stakeholders   RAPID
Fast-moving team, flat org                    DRI

Meta-heuristic: the cost of the framework should not exceed the cost of the ambiguity it removes. A 3-person startup using RAPID for every decision will grind to a halt. A 300-person org relying on DRI alone will have chaos.

How to Use It

Apply these rules regardless of which model you use:

1. Write it down. A matrix that lives in someone's head is no matrix.
2. Name people, not titles. "The PM" is ambiguous; "Priya" is not.
3. Publish it where the affected people will see it.
4. Revisit it at milestones. Roles change as projects evolve.
5. No role for a person = remove them from the list entirely.

Tech & Company Example

A mid-size SaaS company is deciding whether to move from AWS to GCP.

Framework selected: RAPID (cross-functional, high stakes, multiple potential blockers)

R (Recommend):   Platform team (staff engineer + platform PM)
A (Agree):       Security (data-residency), Finance (cost), Legal (contracts)
P (Perform):     Platform team + each product team for their services
I (Input):       SRE, Data, Product leads of each vertical
D (Decide):      CTO, with CFO sign-off on the spend

Process:
  Week 1-3: Platform team runs analysis, drafts RFC
  Week 4:   "I" and "A" groups give input/agreement in RFC threads
  Week 5:   CTO reviews, D-level decision made
  Week 6:   "I" group notified, migration plan published

The critical move: Security, Finance, and Legal were engaged as "A" (agreement required) from week 1. Without that, any of them could have blocked the decision in week 5 and burned the whole process.

When It Works

Projects or decisions spanning multiple people, teams, or functions
Any work where ambiguity about ownership is already causing friction
Onboarding new team members (the matrix shows them who does what)
Compliance-heavy environments where audit trails matter

When It Does Not Work

Routine work with well-established ownership
Teams smaller than ~5 people (overhead > value)
Highly creative or exploratory work where roles genuinely fluid
Situations where the matrix becomes a substitute for actual conversation

Common Failure Modes

Multiple Accountables/Deciders — Diffused accountability is worse than none. Force the group to pick one.
Matrix as CYA — Using the matrix to assign blame rather than enable work. Signals low trust; fix the trust problem, not the matrix.
Ghost roles — Listing someone as Informed who never actually gets informed. Set up the notification flow when you create the matrix.
Stale matrices — A matrix created at kickoff that does not match reality three months in. Revisit at each major milestone.
Role confusion — People interpreting "Consulted" as "has veto power" (it does not) or "Informed" as "ignored" (it is not).
RACI on tiny teams — A 4-person team does not need RACI; it needs a 10-minute conversation.

RASCI — RACI + "S" for Support (people who help but do not own)
CAIRO — Adds "O" for Omitted (explicitly excluded, to prevent drift)
RACI-VS — Adds Verifies and Signs
ARCI — Same roles as RACI, different letter order
PARIS — Participant, Approver, Reviewer, Input, Sign-off

There are many variants. Pick one model per team and stick with it. The cost of switching between models is often higher than the benefit of the "better" model.