Clarify who is Responsible, Accountable, Consulted, and Informed for each decision or task

How does RACI Matrix work?

RACI Matrix provides a step-by-step process for evaluating your options and making a structured decision. Follow the guided steps above to work through the tool with your specific situation.

When should you use RACI Matrix?

Use RACI Matrix when you face a decision that would benefit from structured analysis rather than gut instinct. It is particularly valuable for high-stakes or irreversible decisions where the cost of being wrong is significant.

RACI Matrix: How to Use It (Decision…

RACI Matrix: How to Use It (Decision… | Faster Than Normal

Use this when decisions stall because nobody knows who actually owns them. The RACI Matrix assigns exactly one Accountable person, clarifies who does the work, who gets consulted, and who simply needs to know — eliminating the ambiguity that turns collaborative organisations into slow ones.

Section 1

What This Tool Does

The most expensive word in organisational life is "we." We need to decide on the pricing model. We should align on the product roadmap. We'll figure out the vendor contract. Every time a team says "we" when they mean a decision or a deliverable, they've created a vacuum where ownership should be. And vacuums don't stay empty — they fill with meetings, email threads, passive-aggressive Slack messages, and the quiet assumption that someone else is handling it. Three weeks later, nobody has handled it. Or worse, two people have handled it differently, and now you're reconciling conflicting outputs while the deadline evaporates.

This is not a problem of laziness or incompetence. It's a structural failure. When organisations grow past the point where everyone can see what everyone else is doing — roughly 8 to 12 people, depending on the work — implicit coordination breaks down. The founding team that once operated on shared context and hallway conversations discovers that shared context doesn't scale. New hires don't know who owns what. Cross-functional projects create overlapping jurisdictions. Matrix structures, designed to increase flexibility, instead create dual reporting lines where accountability dissolves into a fog of dotted lines and "shared ownership," which is a polite way of saying no ownership at all.

The RACI Matrix addresses this with blunt specificity. For every task, decision, or deliverable, it assigns each stakeholder exactly one of four roles: Responsible (does the work), Accountable (owns the outcome and has final authority — exactly one person per row), Consulted (provides input before the decision), or Informed (notified after the decision). The mechanism is a simple grid — tasks on the vertical axis, people or roles on the horizontal axis, one letter per cell. The core cognitive shift is forcing the team to distinguish between involvement and ownership — and to accept that most people, for most decisions, should be merely Informed rather than Consulted. That distinction, once made explicit, eliminates roughly 60–70% of the unnecessary meetings and approval loops that plague growing organisations.

The tool traces its lineage to the responsibility assignment matrices used in project management since at least the 1950s, formalised in various PMI and PRINCE2 frameworks. The specific RACI acronym gained widespread adoption in the 1980s and 1990s as organisations grappled with the coordination costs of matrix management structures. It's not glamorous. It's not intellectually novel. It is, however, one of the few management tools that reliably converts organisational confusion into operational clarity within a single working session — provided you're willing to have the uncomfortable conversations it surfaces.

Those conversations are the real product. The matrix itself is just a spreadsheet. The value is in the moment when two directors both claim they're Accountable for the same deliverable and have to resolve it in front of the team. Or when a senior leader discovers they've been marked as "Informed" rather than "Consulted" and has to articulate why their input is actually necessary — or accept that it isn't. The RACI doesn't create alignment. It reveals misalignment that was already there, hiding behind vague language and assumed consensus.

Section 2

How to Use It — Step by Step

Instructions on the left. Worked example — a Series B SaaS company launching a new enterprise pricing tier — on the right.

Step 1 — List

Enumerate every task or decision in the process

Start with the deliverables, not the people. What are the discrete tasks, decisions, or milestones that must happen? Be specific enough that each row represents a single action with a clear completion state. "Pricing strategy" is too vague — it's actually five or six distinct tasks. "Set list prices for each tier" is a task. "Approve final pricing for board presentation" is a decision. If you can't define what "done" looks like for a row, break it down further. Aim for 10–25 rows for a typical project; more than 30 signals you're operating at too granular a level.

Worked example

Enterprise pricing tier launch

The team identifies 12 key tasks: (1) Conduct competitive pricing analysis, (2) Define feature packaging per tier, (3) Build financial model for revenue impact, (4) Set list prices, (5) Design discount authority framework, (6) Update billing system configuration, (7) Create sales enablement materials, (8) Brief customer success on migration path, (9) Draft customer communications, (10) Legal review of new terms, (11) Approve go-to-market plan, (12) Launch and monitor adoption metrics.

Step 2 — Identify

List every person or role involved across the process

Use roles rather than names when possible — "VP Product," "Head of Sales," "Finance Lead" — so the matrix survives personnel changes. Include everyone who currently touches the process, plus anyone who should be involved but isn't. The column headers are your cast of characters. Typically 5–10 roles. If you have more than 12 columns, you're probably including people who should be Informed via a status update rather than tracked in the matrix.

Worked example

Stakeholder roles

Seven roles identified: CEO, VP Product, Head of Sales, Finance Lead, Engineering Lead, Marketing Lead, Legal Counsel. The team debates whether to include Customer Success as a separate column or fold it under Head of Sales. They keep it separate — CS has distinct responsibilities in the migration path. Updated to eight columns with CS Lead added.

Step 3 — Assign

Fill every cell with R, A, C, I, or leave blank

Work through each row and assign roles. The iron rules: exactly one A per row (if two people are Accountable, nobody is), at least one R per row (someone must do the work), and the A can also be the R but doesn't have to be. C means their input is sought before the decision — a two-way conversation. I means they're told after — a one-way notification. Blank means they have no involvement in that task. Resist the urge to make everyone C on everything. Every C you add is a meeting you're creating. Every I you convert to a C is a veto you're implicitly granting.

Worked example

Assigning the pricing rows

Row 4 — "Set list prices": VP Product is A (final call), Finance Lead is R (builds the model and proposes prices), Head of Sales is C (input on market positioning and deal dynamics), CEO is C (strategic alignment), Engineering Lead is I, Marketing Lead is I, CS Lead is I, Legal is blank. The Head of Sales initially pushes to be A on pricing. The team discusses: Sales owns revenue targets, but pricing architecture is a product decision. VP Product retains A. This is exactly the conversation the matrix is designed to force.

Step 4 — Validate

Stress-test the matrix for structural problems

Scan for five red flags. (1) Any row with no A — an orphaned task nobody owns. (2) Any row with two or more A's — diffused accountability. (3) Any column that is R or A on nearly every row — an overloaded bottleneck who will become the project's constraint. (4) Any column that is C on nearly every row — a person who has inserted themselves into every decision, creating approval gridlock. (5) Any row where the A has no authority to actually make the call — a mismatch between the matrix and the real org chart. Fix these before publishing the matrix.

Worked example

Spotting the bottleneck

Scanning the completed matrix reveals that the CEO is marked C on 7 of 12 rows. That means seven tasks require a conversation with the CEO before they can proceed. At a Series B company, the CEO is already the scarcest resource. The team reclassifies: CEO stays C on "Set list prices" and "Approve go-to-market plan" — genuinely strategic decisions. The other five rows shift CEO from C to I. The CEO agrees, noting: "I want to know what's happening, but I don't need to weigh in on the billing system configuration." Five fewer meetings on the CEO's calendar. Five fewer bottlenecks in the project timeline.

Step 5 — Publish

Share the matrix and use it as a living reference

The matrix is worthless if it lives in a slide deck from the kickoff meeting that nobody opens again. Post it where the team works — the project wiki, the top of the shared channel, the first page of the project brief. Reference it when confusion arises: "Per the RACI, you're I on this — here's the update. Sarah is A, so she'll make the call." Revisit the matrix when scope changes, when people join or leave the project, or when you notice the same coordination failure happening twice. A RACI that isn't updated when reality shifts becomes a fiction that erodes trust in the tool.

Worked example

Living document in practice

The team pins the RACI to their Notion project page. Two weeks in, the company hires a new Head of Pricing — a role that didn't exist when the matrix was created. The VP Product updates the matrix: the new hire becomes R on rows 1, 3, 4, and 5, taking over the analytical work from Finance Lead (who shifts to C on those rows). The A assignments don't change — VP Product still owns the outcomes. The matrix absorbs the org change in a 15-minute update rather than a week of confused handoffs.

Section 3

When It Works Best

✓

Ideal Conditions for the RACI Matrix

Dimension	Best fit
Team size	Cross-functional teams of 5–15 people where implicit coordination has started to fail. Below five, the overhead isn't worth it — everyone already knows who does what. Above 15, you likely need multiple RACI matrices for sub-workstreams rather than one massive grid.
Organisational structure	Matrix organisations, cross-functional projects, and any structure where people report to one leader but work on projects led by another. The RACI makes the implicit power dynamics of matrix management explicit — which is precisely why matrix organisations resist it.
Decision type	Recurring processes and multi-step projects where the same roles interact repeatedly. One-off decisions don't need a matrix; a quick conversation suffices. But a product launch with 12 workstreams running in parallel over 8 weeks? That's where ambiguity compounds and the RACI pays for itself many times over.
Conflict pattern	Teams experiencing repeated symptoms: decisions revisited after they were supposedly made, duplicated work discovered late, stakeholders blindsided by outcomes they weren't consulted on, or chronic "I thought you were handling that" moments. These are all symptoms of role ambiguity — the specific disease the RACI treats.

Section 4

When It Breaks Down

⚠

Failure Modes

Failure pattern	What goes wrong	What to use instead
Accountability without authority	Someone is marked A on a task but lacks the organisational authority, budget, or political capital to actually make the call. The matrix says they own it; the org chart says they don't. The result is a person who is nominally accountable but functionally powerless — the worst of both worlds.	Validate each A assignment against real decision rights; escalate mismatches to leadership before publishing
Consulted creep	Everyone wants to be Consulted. It feels important. It preserves optionality. But every C is a synchronous dependency — someone who must be engaged before the work can proceed. A matrix where six people are C on every row isn't a clarity tool; it's a consensus machine that will grind the project to a halt.	Apply a hard rule: no more than 2–3 C's per row. Force the question: "Does this person's input materially change the decision, or do they just want to know?"
Granularity mismatch	Tasks defined too broadly ("manage the launch") make the assignments meaningless — who is R for "manage the launch"? Tasks defined too narrowly ("send the Tuesday status email") create a 200-row matrix nobody maintains. The tool collapses at both extremes.

The most dangerous failure mode is Consulted creep, because it's self-reinforcing and invisible until the project is already behind schedule. Here's the mechanism: a stakeholder who should be Informed requests to be Consulted. It seems reasonable — they have relevant expertise, and including them feels collaborative. So you upgrade them to C. Now they expect to be in the meeting. Their input introduces a new consideration. The decision takes longer. Another stakeholder sees that the first one was consulted and requests the same status. Within two project cycles, every decision requires a meeting with six people, three of whom add no information the Accountable person didn't already have. The project timeline stretches. Nobody can point to the moment it went wrong because each individual upgrade from I to C was defensible. The cumulative effect is paralysis.

The protection is simple and uncomfortable: when someone requests C status, ask them to articulate the specific input they would provide that the current C's cannot. If they can't, they stay at I. This conversation is awkward. It implies that their opinion isn't needed. That's exactly what it means, and the RACI only works if you're willing to say so.

Section 5

Visual Explanation

Section 6

Pairs With

The RACI is a role-assignment tool, not a decision-making framework. It clarifies who decides, not how to decide. The tools around it determine whether the right people are making the right calls in the right way.

Use before

Eisenhower Matrix

Before building the RACI, use the Eisenhower Matrix to triage which tasks and decisions actually warrant formal role assignment. Urgent-and-important work needs a RACI. Important-but-not-urgent work might. Not-important work doesn't need a matrix — it needs to be eliminated or delegated without ceremony.

Use before

Issue Trees

When the project scope is ambiguous, an Issue Tree decomposes the problem into discrete, mutually exclusive components. Each terminal node of the tree becomes a candidate row in the RACI. This prevents the common failure of building a matrix around vaguely defined tasks that nobody can actually complete.

Use after

Confidence Determines [Speed](/mental-models/speed) vs [Quality](/mental-models/quality)

Once the RACI identifies who is Accountable, that person still needs to decide how to decide. High-confidence, reversible decisions can be made fast with minimal consultation. Low-confidence, irreversible decisions warrant pulling in every C on the matrix. The RACI tells you who; this framework tells them how much rigour to apply.

Use after

Pre-Mortem

After assigning roles, run a Pre-Mortem on the RACI itself: "It's three months from now and this project failed because of role confusion. What went wrong?" Teams will surface the accountability gaps, bottleneck risks, and Consulted-creep patterns that the matrix didn't catch on first pass.

Section 7

Real-World Application

Spotify — scaling autonomous squads without losing coordination

The scenario

By 2012, Spotify had grown to roughly 30 engineering teams ("squads") organised into tribes, chapters, and guilds — the now-famous Spotify Model. The structure was designed to maximise autonomy: each squad owned a feature area end-to-end, from design through deployment. The problem wasn't building features. It was the seams between squads. When a user-facing change required coordination across three squads — say, a new payment flow touching the subscription squad, the checkout squad, and the platform infrastructure squad — nobody was clear on who owned the cross-cutting decision. Each squad had autonomy within its domain. Nobody had explicit authority across domains.

How the tool applied

Spotify didn't adopt a single company-wide RACI — that would have contradicted the autonomy model. Instead, they used lightweight RACI-style agreements at the tribe level for cross-squad initiatives. When a project spanned multiple squads, the tribe lead would facilitate a session to assign A, R, C, and I roles across the squads involved. Critically, the A for cross-cutting decisions was typically assigned to a single squad lead — not the tribe lead — to keep decision authority close to the work. The tribe lead was usually I, not A. This was a deliberate inversion of the instinct to escalate accountability upward.

What it surfaced

The RACI sessions repeatedly revealed a specific pattern: squads that owned platform infrastructure were being Consulted on nearly every cross-squad project, creating a bottleneck that contradicted the autonomy model. The infrastructure squad's lead was spending 60–70% of their time in consultation meetings rather than building. The RACI made this visible in a way that anecdotal complaints hadn't. The fix was to convert most of those C assignments to I — the infrastructure squad published API contracts and documentation, and other squads consumed them asynchronously rather than synchronously consulting on every integration.

The non-obvious factor

What made Spotify's application distinctive was the recognition that the RACI needed to be . Each cross-squad RACI was scoped to a specific initiative and dissolved when the initiative shipped. There was no permanent, standing RACI for the organisation. This prevented the tool from calcifying into bureaucracy — the exact failure mode that autonomous-team cultures fear most. The RACI was treated as scaffolding: erected when coordination was needed, removed when the building could stand on its own. Most organisations that adopt the RACI do the opposite — they create permanent matrices that accumulate rows and columns until they become the very bureaucratic overhead they were supposed to eliminate.

Section 8

Analyst's Take

Faster Than Normal — Editorial View

The RACI Matrix is the organisational equivalent of a property deed. Nobody finds it exciting. Nobody frames it on the wall. But when there's a dispute about who owns what, it's the only document that matters. The tool endures — across industries, across decades, across management fads — because the problem it solves is permanent. Humans in groups will always default to ambiguous shared ownership unless forced into specificity. The RACI is that force. Its simplicity is a feature, not a limitation. Any tool that requires a training session to use has already failed at the job of clarifying roles.

The failure mode I see most often is what I'd call the democracy trap. A well-intentioned leader, wanting to be inclusive, marks nearly everyone as Consulted on nearly everything. The matrix looks collaborative. In practice, it creates a system where every decision requires scheduling a meeting with six people, three of whom will cancel, one of whom will raise a tangential concern that delays the decision by a week, and one of whom will later claim they were never properly consulted despite attending the meeting. The RACI's power comes from the I designation — from the willingness to tell competent, senior people that their role on a given task is to receive an update, not to provide input. That's an act of organisational courage, and most leaders flinch from it.

The highest-leverage modification: count the C's per column, not just per row. Most RACI guidance focuses on ensuring each row has exactly one A. That's necessary but insufficient. The real diagnostic is scanning each person's column and counting how many times they appear as C. If someone is Consulted on more than 30–40% of the rows, they are a structural bottleneck — every project that needs their input is competing for the same calendar slots. Either their expertise needs to be documented and distributed (so others can self-serve), or the tasks need to be restructured so their input is embedded earlier in the process rather than required as a gate. The column view, not the row view, is where the RACI reveals the organisation's actual constraints.

Section 9

Top Resources

A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute (7th Edition, 2021)

Reference guide

The PMBOK is where the Responsibility Assignment Matrix — the formal name for what most people call the RACI — is codified as a standard project management practice. The 7th edition integrates it into the broader framework of stakeholder engagement and team performance domains. Dense, comprehensive, and the closest thing to an authoritative primary source for a tool that emerged from practice rather than a single inventor.

The Hard Thing About Hard Things — Ben Horowitz (2014)

Book

Horowitz doesn't discuss the RACI by name, but his chapters on organisational design — particularly the sections on "accountability vs. creativity" and the mechanics of scaling a management team — articulate exactly why role clarity tools become essential as companies grow past 50 people. His insight that "the wrong organisational design causes people to fight" is the best articulation of the problem the RACI solves. Read Chapters 5 and 6.

Measure What Matters — John Doerr (2018)

Book

Doerr's account of OKR implementation at Google and Intel reveals the complementary relationship between goal-setting frameworks and accountability structures. OKRs define what needs to be achieved; the RACI defines who does what to achieve it. Without clear role assignments, even well-crafted OKRs degrade into shared-but-unowned aspirations. Read Chapters 4–7 for the practical mechanics of pairing objectives with ownership.

Team of Teams — General Stanley McChrystal (2015)

Book

McChrystal's account of restructuring Joint Special Operations Command in Iraq is the best case study on when the RACI's linear accountability model breaks down — and what replaces it. In rapidly shifting environments, rigid role assignments create response-time delays that adversaries exploit. His "shared consciousness, decentralised execution" model shows how to preserve clarity of purpose without the rigidity that makes traditional RACI matrices brittle under pressure.

An Elegant Puzzle: Systems of Engineering Management — Will Larson (2019)

Book

Larson's treatment of engineering organisational design is the most practical modern guide to role clarity in technology teams. His frameworks for sizing teams, defining ownership boundaries, and managing cross-team dependencies are the RACI applied at the systems level. The chapters on "work that matters" and "close out, solve, or delegate" provide concrete methods for deciding who should be Accountable versus merely Informed on any given initiative.

RACI Matrix

Continue exploring

What This Tool Does

How to Use It — Step by Step

Enumerate every task or decision in the process

Enterprise pricing tier launch

List every person or role involved across the process

Stakeholder roles

Fill every cell with R, A, C, I, or leave blank

Assigning the pricing rows

Stress-test the matrix for structural problems

Spotting the bottleneck

Share the matrix and use it as a living reference

Living document in practice

When It Works Best

Ideal Conditions for the RACI Matrix

When It Breaks Down

Failure Modes

Visual Explanation

Pairs With

Real-World Application

Spotify — scaling autonomous squads without losing coordination

Analyst's Take

Top Resources

This connects to...

Continue exploring

More like this, in your inbox

What This Tool Does

How to Use It — Step by Step

Enumerate every task or decision in the process

Enterprise pricing tier launch

List every person or role involved across the process

Stakeholder roles

Fill every cell with R, A, C, I, or leave blank

Assigning the pricing rows

Stress-test the matrix for structural problems

Spotting the bottleneck

Share the matrix and use it as a living reference

Living document in practice

When It Works Best

Ideal Conditions for the RACI Matrix

When It Breaks Down

Failure Modes

Visual Explanation

Pairs With

Real-World Application

Spotify — scaling autonomous squads without losing coordination

Analyst's Take

Top Resources

This connects to...