HomeBlog › Process
Process

Everyone's Responsible, So No One Is: A RACI Matrix That Sticks

TL;DR
  • A RACI matrix maps four roles to every task: Responsible (does it), Accountable (owns it), Consulted (gives input), Informed (gets told).
  • The single rule that makes or breaks it: exactly one Accountable person per row. Two A's means nobody owns it.
  • Build it with the team in the room, not alone at your desk. The disagreements that surface are the whole point.
  • A RACI says who. It only changes behavior when the steps behind each task are actually written down somewhere people can find them.

A product team I worked with shipped a feature with a broken pricing page live for nine hours. Afterward, the post-mortem turned up the real cause in about two minutes. The PM thought the engineer was running the final go/no-go check. The engineer thought the PM owned it. Both were "responsible." Neither was accountable. So the page went out, nobody pressed the button that would have caught it, and a customer found the bug before the team did.

That's the exact failure a RACI matrix is supposed to prevent. And it's also the failure a badly built RACI quietly causes, because most of them mark three people "Responsible" on the risky row and leave the owner blank.

A RACI matrix is a simple grid: tasks down the side, people across the top, and a letter in each cell saying what role that person plays. Done well, it ends the "I thought you had it" conversation before it starts. Done as a box-ticking exercise, it's a colorful spreadsheet that everyone nods at in the kickoff and nobody opens again. Here's how to build the first kind.

Why most RACI matrices change nothing

I've seen plenty of these charts, and the ones that fail tend to fail the same handful of ways.

They get built alone. A project lead fills in the whole grid at their desk, presents it as finished, and treats any pushback as a threat to the plan. But the conversation is the value. When you assign roles in a room, you find out the data team didn't know they were on the hook for the migration, and you find it out now instead of during the migration.

Every row has two or three A's. Sharing accountability feels collaborative and generous. It's neither. It's how you recreate the broken-pricing-page story, where two owners each assume the other is watching.

Everyone is Consulted on everything. Marking a stakeholder "Consulted" feels polite, so the column fills up. Now a five-step task needs sign-off from nine people and moves at the speed of the slowest inbox. Every C you add is a small tax on every decision.

It's made once and never touched. The team reorganizes, someone leaves, the process shifts, and the chart still names a person who changed teams two quarters ago. A RACI that doesn't match who actually does the work teaches people to ignore it.

Common mistake: Treating the matrix as the deliverable. The grid is just a record of decisions you made together. If you skipped the deciding-together part, the grid is decoration.

What R, A, C, and I actually mean

The letters are easy to recite and easy to misuse. The difference between Responsible and Accountable is where most teams go wrong, so it's worth being precise.

R Responsible Does the work. Can be more than one person. A Accountable Owns it. Signs off. Exactly one per task. C Consulted Gives input before you act. Two-way. I Informed Told after the fact. One-way.
Four roles, two of them often confused. The whole system holds together on the rule that A is always exactly one person.

Responsible is the person doing the hands-on work. A task can have more than one R if several people genuinely share the doing. Write the support reply, run the script, draft the contract.

Accountable is the single owner. They sign off, and if it goes sideways, they're the one explaining what happened. On small tasks the R and the A are the same person. On bigger ones they split: an engineer is Responsible for the fix, the team lead is Accountable for the decision to ship it. There is always exactly one A.

Consulted means you actively ask for their input before you act, and you wait for the answer. It's a two-way conversation. Reserve it for people whose input actually changes what you do, not everyone who likes to be in the loop.

Informed means you tell them once it's done. One-way, no reply needed. This is where most "Consulted" people actually belong. Legal doesn't need to weigh in on the wording of every release note; they need to know it went out.

How to build a RACI matrix in five steps

The method is short. The discipline is in step two and step four, where it's tempting to take the easy answer.

1. List the tasks that actually need an owner

Not every micro-step. Pick the ten to fifteen decisions and deliverables where confusion shows up: approvals, handoffs, the moment work crosses from one team to another. Frame each as a real thing that gets done — "approve the refund," "publish the help article" — not a vague area like "communication."

2. Put the roles across the top, not the names

Use job roles, not people's names. "Support Lead," not "Priya." People change seats; the chart shouldn't break every time they do. It also keeps the conversation about the work instead of about personalities.

3. Fill in one A per row first

Before anything else, go row by row and name the single Accountable owner. Doing the A column first forces the hard call early, while everyone's still in the room. If a row has no obvious owner, you've found a gap that would have bitten you later. If it has two candidates, you've found a turf question worth settling now.

4. Add R, then be stingy with C and I

Mark who's Responsible for the doing. Then add Consulted and Informed sparingly. For every C, ask: does their input genuinely change the outcome, or do they just want visibility? If it's visibility, they're Informed. This single filter keeps your process from drowning in sign-offs.

5. Walk every named role through their row

Read the chart back to the people in it. "Support Lead, you're Accountable for the escalation call and Consulted on the refund. Sound right?" Watch for the flinch. Every surprised face is a misalignment you just caught for free. This is the same move that makes an documented process stick: it isn't real until the person doing it agrees it's real.

Pro tip: Read the matrix down each column too, not just across each row. A person with R on twelve tasks is a bottleneck waiting to happen. A person with nothing but I everywhere probably doesn't need to be on the chart at all.

A copy-paste RACI template (with example)

Steal this. Tasks down the left, roles across the top, one letter per cell. Here it is filled in for a customer-offboarding process, so you can see what "one A per row" looks like in practice.

RACI matrix: Customer offboarding

TaskAccount MgrSupportFinanceEng
Confirm cancellation requestARI
Process final invoiceCA R
Export customer dataICA R
Revoke account accessIIA R
Send offboarding summaryA RIII

Read it: every row has exactly one A. R = does the work, C = asked first, I = told after, – = not involved. Blank columns of I's are a hint to drop a role from the chart.

To make your own, swap in your tasks and roles and keep three rules in front of you: one A per row, an R on every row (someone has to do it), and a hard look at every C before it stays. If a row ends up all I's and no R, the task has no doer and the process will stall there.

Pro tip: Keep the whole thing on one screen. A RACI that scrolls is a RACI nobody reads. If you can't fit it, you've listed steps instead of decisions, or you've added roles that should have been Informed by email instead of columns in a grid.

The mistakes that turn a RACI into wallpaper

Beyond the build itself, a few patterns reliably kill a RACI after launch.

Assigning roles by politics, not by work. Giving a senior stakeholder an A on a task they'll never actually own keeps the peace in the meeting and changes nothing on the ground. The chart has to match who really does the work, or people route around it.

Confusing a RACI with a plan. The matrix says who, not when or how. It pairs with a timeline and with the actual procedures. On its own it can tell you the owner of "deploy the release" without anyone knowing the deploy steps.

Letting it drift. Put an owner and a review date on the chart itself, the same way you would for any SOP. When the team changes shape, the RACI is the first thing that goes stale, and a stale one is worse than none because it looks authoritative while being wrong.

Going too granular. If your rows read like a step-by-step list — "open the dashboard," "click export" — you've built the wrong artifact. Those are work-instruction steps. A RACI sits one level up, at decisions and deliverables. The steps live in the guide the owner follows.

From chart to actually doing the work

Here's the part most RACI guides skip. A finished matrix tells the Account Manager they own "send the offboarding summary." It does not tell them what goes in the summary, which template to use, or where the data comes from. So the new Account Manager who inherits that A still pings the team channel asking how to actually do it. The confusion didn't disappear. It moved from "who" to "how."

A RACI is only as good as the documentation sitting behind each owned task. The owner needs a real, step-by-step guide they can open and follow. That pairing — one clear owner, plus the exact steps for what they own — is what turns a chart into behavior.

This is the gap WriteHow is built to close. Once your RACI names the owner of a task, you record yourself doing that task once, and WriteHow drafts a step-by-step guide from the recording: ordered steps, screenshots, and annotations, with sensitive details auto-blurred. You review and approve it before anyone sees it, so the AI does the tedious first draft and you keep the final say. If your owners sit across regions, the same guide can be published in 50+ languages without rebuilding it. The RACI says who owns "export customer data." The guide shows that owner exactly how, even on their first day in the role.

Build the matrix with the team in the room. Name one owner per row. Be ruthless about the Consulted column. Then write down the steps behind each owned task so the chart actually changes what people do. That's the difference between a RACI matrix that sticks and one that ends up as wallpaper in a kickoff deck nobody reopens.

Where to go nextIT & Ops documentationWriteHow pricingWriteHow vs Tango

Frequently asked questions

What does RACI stand for?
RACI stands for Responsible, Accountable, Consulted, and Informed. Responsible is the person who does the work. Accountable is the single owner who signs off and answers for the outcome. Consulted are the people whose input you actively seek before acting. Informed are the people you tell once it's done. It's a way to map who plays which role on every task in a process.
Can a task have more than one Accountable person?
No, and this is the rule that matters most. Each row should have exactly one A. The moment two people share accountability, each assumes the other has it, and the outcome falls through the gap. You can have several people marked Responsible on a task, but only one person can own it. If you can't pick one A, that's a real disagreement to settle, not a formatting choice.
What is the difference between Responsible and Accountable?
Responsible is who does the hands-on work. Accountable is who owns whether it gets done right and answers for it afterward. Often the same person is both, especially on small tasks. On bigger ones they split: an engineer is Responsible for shipping the fix, the team lead is Accountable for the call to ship. The test is simple. If it goes wrong, the Accountable person is the one explaining why.
When should I use a RACI matrix?
Use one when a process crosses teams and ownership is fuzzy: launches, incident response, onboarding, audits, anything where 'I thought you had it' shows up. For a task one person does end to end, a RACI is overkill. The signal you need one is recurring confusion about who decides, who's looped in, and who just gets a heads-up.
How is a RACI matrix different from a process map?
A RACI matrix answers who. A process map answers what happens and in what order. They're complements. The RACI tells you the one owner for 'approve the refund'; the process map and the underlying step-by-step guide tell that owner exactly how to do it. A RACI with no documented steps behind it just relocates the confusion from 'who' to 'how.'

One owner is half the job

Name the owner with a RACI, then let WriteHow turn a single recording into the step-by-step guide they follow — screenshots, auto-blur, and 50+ languages. AI drafts it, you approve it.

See how WriteHow helps
TD
Tanvi Deshmukh · Growth Marketer at WriteHow
Writes about process documentation, operations, and the unglamorous work that keeps teams aligned.