Contents
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. |
| Maturity stage | Organisations transitioning from startup informality to scaled operations. The shift from 30 to 100 employees is the classic inflection point. Processes that worked through osmosis now need explicit structure. The RACI is often the first governance tool that growing companies adopt — and for good reason: it's the simplest one that actually works. |
| Stakeholder diversity | Projects involving external partners, agencies, or cross-company collaborations where assumptions about who owns what are almost guaranteed to diverge. A RACI built jointly with an external partner at project kickoff prevents the "we assumed you were handling that" conversation at the deadline. |
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. | Each row should represent a task that takes 1–10 days and has a single clear deliverable. If it takes an hour, it's too small. If it takes a quarter, break it down. |
| Static matrix, dynamic project | The RACI is built at kickoff and never updated. Scope changes, new hires, departures, and shifting priorities make the original matrix fiction within weeks. Teams stop referencing it. The tool dies not from misuse but from neglect. | Schedule a RACI review at every major milestone or scope change. Assign someone (yes, with an R) to maintain the matrix. |
| Cultural mismatch | In high-context cultures or organisations with strong consensus norms, the RACI's insistence on a single Accountable person can feel confrontational or hierarchical. Teams fill in the matrix to satisfy a process requirement but continue making decisions by consensus, rendering the A designation meaningless. | Adapt the tool: some teams use RAPID (Recommend, Agree, Perform, Input, Decide) which distributes decision-making more explicitly across consensus-oriented steps |
| Bureaucratic theatre | The matrix becomes a compliance artifact rather than a working tool. Teams spend hours debating whether someone is C or I on a low-stakes task. The overhead of maintaining the matrix exceeds the coordination cost it was supposed to eliminate. This is the tool eating itself. | Only build RACI matrices for processes where role ambiguity has caused real, documented problems. Not every project needs one. If the team is small and aligned, a verbal agreement is fine. |
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
RACI Matrix for the enterprise pricing tier launch. Each cell assigns exactly one role — R (Responsible), A (Accountable), C (Consulted), or I (Informed). Note: exactly one A per row, and the CEO column was deliberately trimmed from 7 C's to 2 during validation.
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.
Mental model
Reversible vs. Irreversible Decisions
Jeff Bezos's Type 1 / Type 2 distinction maps directly onto RACI design. Irreversible decisions (Type 1) deserve a senior A and multiple C's. Reversible decisions (Type 2) should have the A pushed as low in the organisation as possible, with minimal C's. The RACI should reflect this asymmetry — not treat every row identically.
Mental model
Situation-Behaviour-Impact
When RACI assignments create friction — someone feels excluded, someone is overloaded — use SBI to address it directly. "When you were marked as Informed rather than Consulted on the pricing decision [Situation], I noticed you started attending the meetings anyway [Behaviour], which added a week to the timeline [Impact]." The RACI surfaces the structural issue; SBI resolves the human one.
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 appliedSpotify 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 surfacedThe 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 factorWhat made Spotify's application distinctive was the recognition that the RACI needed to be temporary. 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
01
A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute (7th Edition, 2021)
Reference guideThe 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.
02
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.
03
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.
04
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.
05
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.
Decision Tools Library — Browse by phase
Why this matters next
mental modelsLeverage
Eisenhower Matrix applied the Leverage mental model
mental modelsScale
Eisenhower Matrix applied the Scale mental model
mental modelsQuality
Eisenhower Matrix applied the Quality mental model
mental modelsEnvironment
Eisenhower Matrix applied the Environment mental model
mental modelsCost
Eisenhower Matrix applied the Cost mental model
mental modelsInflection Point
Eisenhower Matrix applied the Inflection Point mental model
Continue exploring
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.