RACI charts are one of my favorite tools, and it has almost nothing to do with the artifact itself. A finished RACI chart is a grid with names and letters in it. Useful, sure. But the value was created before the chart existed, in the room where a team negotiated who owns what, pushed back on each other, and claimed work out loud in front of their peers. The chart is just the receipt.
Most teams that struggle with accountability don't have a documentation problem. They have a negotiation problem. Nobody has ever sat down together and worked through the full list of jobs to be done, line by line, until every one of them had a single owner. The RACI exercise forces that conversation to happen. Done well, it surfaces gaps nobody knew existed, resolves ownership disputes that have been simmering for months, and produces commitments that stick because people made them voluntarily.
Done poorly, it produces a spreadsheet everyone ignores.
The difference comes down to a handful of principles. Here's how I run these sessions.
1. Know when a RACI is the right tool
A RACI is for a team that's stuck: work is falling through the cracks, nobody knows who owns what, and the same "whose job is this" argument keeps resurfacing. It's not a tool to deploy just for the heck of it, and it's not meant to live forever. Teams change. When a new makeup of the team starts struggling with roles and responsibilities again, have the discussion again and build a new chart.
The math is simple. It's an hour for the team now that saves dozens of hours later and strengthens the team in the process. The alternative, fighting about who does what, breaks teams apart and builds resentment.
2. Start with the right facilitator
The single most important decision is who facilitates. The facilitator's job is to make sure the chart is fulsome, not to decide who does what. They keep the list complete. The team keeps the ownership.
The best facilitator is someone who understands the product and software development lifecycles well enough to help the team enumerate every responsibility that needs an accountable party, but who has no ownership stake in any of the jobs being discussed and no organizational standing over anyone in the room.
A great choice for a facilitator is anyone with facilitation experience who knows how to step back and let the team negotiate amongst themselves, speaking up only to ask questions or point out a possible gap. A Technical Program Manager (TPM) from another team works well here because they’re usually individual contributors who know how to influence without authority.
The worst possible facilitator is anyone with role power in the company like a Director, VP, C-Suite leader, in addition to anyone who directly manages someone at the table. A title that carries weight across the org changes how a room behaves and anyone with the authority to assign tasks changes the group dynamic. Team members stop negotiating as peers, ownership stops being claimed and starts being assigned, and that undermines the entire exercise.
This bar is only about who facilitates, not who's in the room. An engineering manager who also does hands-on work, and who may be the right accountable party for lines of work on the chart still belongs in the room as a participant. Managing people doesn't disqualify someone from claiming their own accountability. It only disqualifies them from running the session.
3. The fundamental rule: nobody gets assigned anything
This is the principle that produces the best results, and it's non-negotiable in my sessions. No one is assigned a responsibility. No one is assigned accountability. Every single line in the chart needs a self-selected owner.
The team should be able to push back on its individual members and negotiate who the ultimate accountable party is for each job. What can't happen is someone committing a teammate to work they haven't agreed to on their own.
There's something powerful about a person looking around the room, recognizing they're the right owner, and claiming the work in front of everyone. That public, voluntary commitment holds in a way an assignment never does. When ownership is assigned, the owner can believe it was never theirs to begin with. When ownership is claimed, it's theirs.
4. Keep the room small
The meeting should include only the people who need to claim responsibility or accountability. It should not include everyone who will be consulted or informed. Those columns get filled in, but those people don't need to be in the room, and every extra body slows the negotiation down.
There's a second reason to keep the consulted and informed parties out, and it's one most guides won't say out loud: those people don't need to know the team decided they'd only be informed rather than consulted. This document is a forcing function for a conversation, not a publication. It doesn't need to be posted anywhere, and the C and I columns are the least important part of the exercise.
There’s one exception to this rule: include someone from customer success or support. This person represents the customer in the process, and in my experience they have the sharpest view of where gaps in the work cause breakdowns later. The best choice is someone well respected amongst their peers, familiar with how the product works, and close to customer feedback. That person may not exist in perfect form at every company, so the facilitator should find the best available fit in their judgment. What matters most is that the CS person opts into the meeting rather than being “volun-told.” The exercise needs people interested in the conversation and willing to bring their perspective in a positive light.
5. One A per row. No exceptions.
Every rule so far allows for judgment calls. This one doesn't. Each job to be done gets exactly one accountable person under any circumstance.
If the team can't agree on a single accountable person for a line, that's not a signal to split the A. It's a signal to split the line. Divide the job into smaller pieces until each piece has one person who can own the outcome. Shared accountability is how work falls through the cracks while two people each assume the other has it.
One clarification that trips teams up: the accountable person can also be responsible for doing the work. An A and an R can live in the same cell.
6. Use roles, not names
The chart should stay high level, with roles like Engineer, Product Manager, Scrum Master, Marketing, etc. Specific names don't need to appear, especially for the consulted and informed columns. A simple "Marketing" at the top of a column means someone from Marketing should be consulted or informed, but it's not necessary in this exercise to name that person. Roles keep the chart durable through personnel shifts and keep the conversation focused on the work rather than on individuals.
7. Be ruthless about the consulted column
Everyone wants to be consulted. Left unchecked, the C column bloats until every decision requires a committee, and the chart becomes a map of the org's politics rather than its work.
There's one question that cuts through it: is the team willing to put this work on pause if the person who needs to be consulted isn't available? If the answer is no, that person doesn't need to be consulted. Consulted means their input is required before the work proceeds. It doesn't mean their feelings get managed.
8. Build the list before the meeting
The negotiation works best when the team arrives with the list of jobs already drafted. I have everyone contribute asynchronously before the session, adding the jobs they believe the team needs to do to complete its mandate. It doesn't have to start from a blank page, but it also shouldn't be fleshed out entirely by one person. A list written by one person reflects one person's view of the work, and the gaps in that view are exactly what the exercise exists to find.
If the pre-work doesn't happen, don't skip this step. Instead, make the first 5-10 minutes of the meeting silent while everyone fills out the list together in the document. Silent, because the moment people start talking, the loudest view of the work wins. Write first. Negotiate second.
9. When nobody claims a line
Sometimes a job sits unclaimed. Nobody volunteers, and the negotiation stalls. Resist the urge to force it. Leave the line unclaimed and schedule a follow-up meeting for a time long enough to see what happens in reality when no one claims that line.
That gap between meetings is diagnostic, and one of a few things will become clear. Someone may be filling the gap behind the scenes, possibly someone who wasn't in the original session at all, which tells the team something important about who is doing the work. Or nobody fills it, and the downstream effects show up. The follow-up conversation then has evidence to work with: who was impacted when the work didn't happen, and who stepped in when it did.
There's also a third possibility worth taking seriously: the job may not need to be done at all. Some lines turn out to be outliers for work that rarely comes up. Once the team sees that, someone often claims it because they can see the load is light.
Two more conversations belong in that follow-up. First, get precise about what the job entails, because unclaimed lines are often unclaimed due to a misunderstanding about the true scope of the work. And second, if someone has claimed the R but not the A, ask them why they're willing to do the work but not own it. The answer is almost always informative. It usually points at a missing decision right, a dependency they don't control, or a history the rest of the room needs to hear.
What success looks like
When these principles are in place, the meeting takes on a specific quality. Peers ask each other honest questions. "Wait, who reviews the release notes before they go out?" Silence. Nobody. That's a gap, and it just became visible. Someone says "I think that's mine" and someone else says "I assumed that was yours, but I've been doing it." That's a duplication, and it just got resolved. The facilitator asks "What happens between the design handoff and the first commit?" and three people give three different answers. That's the conversation the chart exists to force.
None of this shows up in the final artifact. The artifact just says who has the A. But the team that walks out of that room has a shared understanding of the work that no document alone can create.
A starting point for the conversation
I've built a downloadable RACI template to go with this article pre-filled with the jobs AI has added to product and engineering work, such as who reviews AI-generated code, who owns the eval process, who catches a hallucination before it reaches a customer, and who is accountable when an AI feature's performance drifts in production. These are jobs most teams are already doing informally, without ever deciding out loud who owns them. The template works for any team's RACI, but it's built to surface the roles AI has reshaped. The pre-filled rows aren't the answer. They're the prompt for the conversation.
The chart takes an hour to fill in. The conversation is the part worth having.