Role Clarity: Who Does What (RACI)

Onboarding got a new person up to speed on how the work happens. This page answers a quieter, more corrosive question that trips up even well-run teams: who exactly is responsible for what? When that answer is fuzzy, work slips through the cracks, two people do the same thing, and people quietly resent each other for failures that were nobody’s fault in particular.

The claim of this page is simple and freeing: most of what looks like a people problem is actually a clarity problem. The teammate who “dropped the ball” often never knew the ball was theirs. The colleague who “went behind your back” may have genuinely believed the decision was hers to make. Fix the ambiguity and a surprising amount of tension simply evaporates. RACI — a small, boring-looking grid — is one of the sharpest tools for doing exactly that.

Why ambiguity feels like a people problem

Imagine a hospital ward where a patient needs a follow-up scan booked before discharge. The doctor assumes the ward nurse will book it. The nurse assumes the ward clerk handles bookings. The clerk assumes the doctor’s team raised the request. Nobody is lazy. Nobody is incompetent. Yet the scan doesn’t get booked, the discharge is delayed, and by the afternoon three professionals are irritated with each other.

Notice what happened. There was no shortage of skill or goodwill. There was a shortage of one specific thing: a shared, explicit answer to whose job is this? Ambiguous ownership produces three predictable failures, and all three read as character flaws when they are really structural gaps.

Ambiguity in ownership → what it looks like on the ground

  Nobody owns it        →  DROPPED BALL     ("I thought you had it")
  Two people own it     →  DUPLICATED WORK  ("I already did that?!")
  Unclear who decides   →  TURF CONFLICT    ("that wasn't your call")

• Dropped balls. A task everyone assumes someone else is handling. It surfaces late, usually as a crisis.
• Duplicated work. Two people, unaware of each other, build the same report, chase the same supplier, or fix the same bug. Effort is wasted and, worse, the two versions may conflict.
• Turf conflict. Someone makes a decision they believed was theirs; someone else believed it was theirs. Now it feels personal — a power grab, a slight — when it was only ever an undefined boundary.

The trap is to respond to these with people fixes: a stern word, a reshuffle, a note about “attention to detail.” Those rarely help, because the cause wasn’t the person. The cure is to make ownership explicit before the work starts. That is what RACI does.

In practice — the report nobody owned

A marketing team produced a weekly performance report. For months it was fine. Then the analyst who quietly compiled it went on leave, and the report simply stopped appearing. When the manager asked why, everyone had an answer: “I thought Priya did that.” Priya had never been formally responsible — she’d just picked it up. The task had no owner on paper, so when the informal owner left, it vanished. A one-line ownership map would have caught this in seconds.

The RACI model

RACI is a way of assigning four distinct roles to every task or deliverable. The word is an acronym for the four roles, and the whole point is that these roles are different and often held by different people.

R  Responsible  — does the actual work
A  Accountable  — owns the outcome; answers for it; exactly ONE person
C  Consulted    — gives input before/while it's done (two-way conversation)
I  Informed     — told about the result after the fact (one-way notice)

Let’s take them one at a time, because the two that get confused — Responsible and Accountable — are exactly the two that matter most.

Responsible: who does the work

The Responsible person (or people) does the hands-on work. They write the document, run the machine, make the calls, cook the dish. There can be more than one Responsible person on a task — a warehouse pick might be Responsible across three staff on a shift. Responsible answers the question whose hands are on this?

Accountable: who owns the outcome

The Accountable person owns whether the thing succeeds or fails. If it goes wrong, they are the one who answers for it — not to be punished, but because the buck stops somewhere. Crucially, the Accountable person is often not the one doing the work. A café shift lead is Accountable for the morning rush going smoothly; the baristas are Responsible for pulling the shots.

The single most important rule in all of RACI lives here: exactly one person is Accountable for any deliverable. Not a team, not “the department,” not two co-leads. One name.

Consulted: whose input you gather first

Consulted people are asked for input before or during the work, in a genuine two-way exchange. The finance lead consulted on a budget. The senior nurse consulted on a care plan. Consulting is not the same as informing — you actually wait for and use their answer. Consult sparingly; every person you consult adds delay, so consult those whose input changes the outcome, not everyone who wants to feel included.

Informed: who hears about it afterward

Informed people are told the result after it’s done — a one-way notice, no reply expected. Your manager may want to be Informed that the migration completed. A neighboring team may want to be Informed of a schedule change. Informing is cheap and prevents the “why didn’t anyone tell me?” resentment, but it is not a request for input.

The common trap — confusing Consulted with Informed

The most common RACI mistake, after having no single Accountable, is treating “Consulted” and “Informed” as interchangeable. They are opposites in direction. Consulted is input in — you ask, you wait, their view can change what you do. Informed is notice out — you tell them, and the decision is already made. Blur the two and you get one of two failures: you ask for input you never intend to use (which breeds cynicism), or you “inform” someone whose sign-off you actually needed (which blows up later). Be honest about which one it is.

The single-accountable rule

This rule deserves its own section because it is the one people resist most and need most.

Exactly one person is Accountable, or nobody truly is.

When two people are “jointly accountable,” each can, in a pinch, assume the other has it. That’s the dropped-ball ward scan again, just dressed up as shared leadership. Shared accountability is a comfortable fiction: it feels collaborative and avoids awkward hierarchy, but it removes the one thing accountability is for — a single place the responsibility rests when things get hard.

Being Accountable does not mean doing the work, being the most senior, or getting the credit. It means: if this deliverable fails, you are the person who has to explain what happened and what you’ll do about it. That is why it must be one person. You cannot hold “the group” to account; you can only hold a person.

A useful test: for any important deliverable, ask “If this goes badly, whose name comes up first?” If you can’t answer instantly, or if two names come up, you have a gap to fix.

The evidence — accountability and diffusion of responsibility

Social psychology has long documented the diffusion of responsibility — the tendency for individuals to take less personal responsibility for action when others are present, on the assumption that someone else will step in. Studies of group behavior generally find that the more people who could act, the less likely any single one does. The single-accountable rule is a direct countermeasure: by naming one person, you defeat the “someone else will handle it” reflex that ambiguity invites.

Mapping a real workflow to RACI

The tool becomes real when you lay it over actual work. You build a small grid: deliverables down the side, people across the top, and a letter (R, A, C, or I) in each cell. Empty cells are fine and expected — most people have no role in most tasks.

Here is a simplified example for launching a new menu item at a small café.

                        │ Owner │ Head Chef │ Barista │ Supplier │ Accountant
────────────────────────┼───────┼───────────┼─────────┼──────────┼───────────
Decide the new item     │   A   │     C     │         │          │     C
Cost & price it         │   A   │     C     │         │     I    │     R
Source ingredients      │   I   │     A     │         │     R    │
Train staff to make it  │   I   │     A     │    R    │          │
Update the menu board   │   A   │     I     │    R    │          │
Announce to customers   │   A   │     I     │    I    │          │

Reading the grid teaches you things at a glance. Notice that every row has exactly one A — that’s the health check. Notice that the Owner is Accountable for pricing but the Accountant does the work (R). Notice that “Source ingredients” hands accountability to the Head Chef, not the Owner — a deliberate delegation.

Now use the grid to hunt for the two failure modes:

• Scan every row for its A. A row with no A is a dropped ball waiting to happen — nobody owns it. A row with two A’s is a turf conflict waiting to happen — fix it now, on paper, where it’s cheap.
• Scan for R without A, or A doing all the R too. A deliverable where the same overloaded person is both A and R on everything is a bottleneck; a deliverable with an A but no R means someone owns an outcome with no one actually doing the work.

You don’t need software. A whiteboard, a shared doc, or a napkin works. The value isn’t the artifact — it’s the ten-minute conversation that produces it, where the ward-scan assumptions get spoken out loud and corrected before they cause harm.

In practice — the fifteen-minute grid that saved a launch

A small software team kept missing release steps — someone forgot to update the documentation, or two people both messaged customers. Before the next release, the lead spent fifteen minutes building a RACI grid for the release checklist. Two surprises fell out immediately: nobody was Accountable for the customer email (a genuine gap), and two engineers both thought they owned the database change (a genuine overlap). Both were fixed on the spot. The release went out clean — not because the people got better, but because the ambiguity got named.

Role clarity reduces politics

Here is the deeper payoff, and it connects straight back to the throughline of this book: turning a group and a goal into reliable outcomes without politics.

Office politics thrives in ambiguity. When it’s unclear who decides, deciding becomes a contest — people jockey, form alliances, and lobby, because influence is up for grabs. Energy that should go into the work goes into positioning. And the people best at that jockeying win, regardless of whether they’re right.

Make who-decides explicit and you drain the swamp. If the grid says the Head Chef is Accountable for sourcing, there’s nothing to lobby for — the decision has a home. People can still disagree (that’s what Consulted is for), but they disagree into a clear decision-making structure rather than fighting over who owns the structure itself. Clarity doesn’t remove all conflict — handling conflict is a skill in its own right — but it removes the pointless, corrosive kind that’s really just a fight over undefined turf.

This is why role clarity is a foundation, not a formality. It lets a team spend its energy on the actual problem instead of on figuring out who’s allowed to solve it.

How it connects

Role clarity works hand in hand with the other team foundations. It’s part of what turns a group into a team — a team has clear, complementary roles; a group is just people in a room. It reinforces psychological safety: when people know exactly what they own, they can speak up about it without fear of stepping on toes. And it depends on good hiring — a clear role on paper only helps if the person in it has the skills to hold it.

Try this

Pick one recurring piece of work your team does — a weekly report, a customer handoff, a release, a shift changeover — and build a RACI grid for it this week. List each deliverable down the side and each person across the top, then fill in R, A, C, and I. Do it with the people involved, not for them: the conversation is where the hidden assumptions surface. Then run the health check — make sure every row has exactly one A, no more and no less — and fix any row that has zero or two.

Reflect

1. Think of a recent “dropped ball” or duplicated effort on your team. Was it truly a people problem, or was ownership never actually clear?
2. For an important deliverable you’re involved in right now, can you name — instantly — the single Accountable person? If not, what does that tell you?
3. Where do you currently blur “Consulted” and “Informed”? Are you asking for input you don’t use, or informing people whose sign-off you actually need?
4. Is there a task where “shared accountability” is quietly acting as “nobody’s accountability” on your team?
5. Where does political jockeying show up on your team, and which undefined who-decides question might be feeding it?

Show reflections

1. The useful move is to resist the reflex to blame a person. Ask what the two or three people involved each assumed about ownership — if their assumptions differed, it was a clarity gap, and a grid would have caught it.
2. An instant, single answer means ownership is healthy. Hesitation, or two names, is the exact signal RACI is designed to expose — treat it as a gap to close, not a judgment on anyone.
3. This catches the most common RACI error. If you ask for input you’ll ignore, you’re breeding cynicism; if you “inform” someone whose agreement you need, you’re setting up a late blow-up. Name the true direction — input in, or notice out.
4. Look for “co-leads,” “the team owns this,” or “we’re all responsible.” Comfortable phrases, but each lets everyone assume someone else has it. Naming one Accountable person is uncomfortable and exactly the point.
5. Strong answers connect a specific bit of jockeying to a specific undefined decision. Where two people fight to influence a call, ask who should own it, make that explicit, and watch whether the fight loses its fuel.