A RACI matrix example is easiest to understand when you follow one decision as a company grows. Take a single, high-stakes call — approving a software release — and map it at three team sizes: a 5-person startup, a 20-person scale-up, and a 100-person enterprise. The decision never changes. What changes is who holds the R, the A, the C, and the I, and how many people can quietly stall the whole thing before the build ever ships.
Key takeaways
- The release approval decision stays identical at every size; the letters around it move as headcount grows.
- Exactly one person should hold A at every size. Two names in the Accountable box means nobody is accountable.
- At 5 people one person can hold A and R; at 20 that split becomes real; at 100 it usually breaks.
- The two failure modes worth checking for are too many C's and an A who is never in the room to decide.
The decision we're mapping: "ship it"
Every company that writes software has this moment. The build passes testing, the branch is merged, and someone has to say the release goes out today. It is a good decision to map because it repeats constantly, it carries enough weight to attract opinions, and it crosses engineering, product, support, and sometimes legal.
Write the decision at the top of the page in one sentence — "Approving a production release" — then build the matrix around that sentence, not around your org chart. That is the mistake most first drafts make: they assign letters to roles instead of to a decision, and the grid ends up describing a department rather than a call that has to get made.
A RACI matrix example at three team sizes
| Team size | Accountable (A) | Responsible (R) | Consulted / Informed (C / I) |
|---|---|---|---|
| 5-person startup | Founder or CTO | The same founder, or the one engineer who built it | Everyone else is I; C is empty |
| 20-person scale-up | Head of Product | Engineering lead who owns the release | QA and Support are C; Sales is I |
| 100-person enterprise | VP Engineering, on paper | Release manager | Security, legal, platform, data, support, marketing, compliance — all C |
Scale 1: five people, one name in two boxes
At five people you don't have an org chart, you have a group chat. The person who built the release is usually the person who decides it goes out. That is fine. In RACI terms, they hold both R (does the work) and A (answers for the outcome), and everyone else is I — they get told.
The only rule that matters at this size is the one people break later: one A. Not two, not "the team." If the founder and the second engineer both consider themselves accountable for a release, you will find out at the worst possible moment, usually at the point where nobody wants to be the one who says stop.
At five people the C column is usually empty, and that is correct. There is nobody to consult who isn't already in the room.
Scale 2: twenty people, the split becomes real
At twenty, the person doing the release work is rarely the person who answers for the product going out. So the letters separate: an engineering lead becomes R, the head of product becomes A, and the C box finally has legitimate occupants — QA, support, and whoever owns the customer relationship.
The failure mode here is consultation creep. Someone gets added to the release review because they would like to know, and the matrix quietly records them as C. Then their calendar becomes a dependency. The test for a C is simple: would their objection change the decision? If yes, they are a C. If they would just like a heads-up, they are an I.
At this size the A also starts attending every review "just to be safe." That is the beginning of the bottleneck. The A does not need to be in the room. The A needs to be reachable when the room cannot agree.
Scale 3: a hundred people, where the matrix breaks
At a hundred people the enterprise version of this matrix usually grows to nine or ten boxes, and two things go wrong at once.
The first is too many C's. Security, legal, platform, data, support, marketing, and compliance all have a legitimate interest in a release, so all of them get a C. Nobody meant any harm. But a row of C's means every release waits on seven calendars, and one silent objection stalls the entire thing. Consultation is supposed to improve the decision. It is not supposed to hand seven people a veto they never asked for.
The second is an A who is never available. The VP of Engineering is the accountable name on the document. The VP is also in three time zones and hasn't been in a release review in months. In practice the release manager is deciding, but the release manager doesn't have the authority, so every close call escalates to someone who can't answer today. That is not accountability in the RACI sense. It is a decision with a title and no owner.
Both failures show up the same way: releases take longer than the work inside them, and no single person can tell you who actually said yes.
What to do when the flags come up
Cut the C column down to the people whose objection would genuinely change the outcome, and move everyone else to I. That is not a demotion — being informed is a real role, and it costs the release nothing. The free generator at https://tools.exiuss.com/raci-matrix flags both problems automatically so you can see the row of C's before it becomes a schedule.
Then fix the A. Either the VP is genuinely reachable for release decisions, or someone else holds the A with the authority written down. A delegate without authority is just a delay with a name on it. And if one person legitimately holds A and R on a small team, write AR — don't split it across two names to make the grid look tidy.
Build your own version in one sitting
You can draft this on a whiteboard, but the rule check is what eats the afternoon. List your roles, list your tasks, then click a box to cycle through blank, R, A, AR, C, and I. The engine drafts a first pass of who is Responsible, Accountable, Consulted, and Informed, flags where the matrix breaks RACI rules, and lets you write the SOP behind each task — a few lines becomes a full standard operating procedure. When it reads right, export it as PDF, CSV, or text and put it where the team will actually see it.
Run this at 5, at 20, and at 100. The matrix is not a document you write once. It is a snapshot of how decisions get made at your current size, and it needs a new snapshot every time the size changes.
Quick checklist
- Name the one decision you're mapping, not the team or the department.
- Put exactly one A in place and confirm that person can actually decide today.
- Assign R only to people who touch the work.
- Move every C whose objection wouldn't change the outcome into I.
- Give the A a reachable delegate with real authority, or change the A.
- Re-export the matrix whenever the team changes size.
Start with the release decision that keeps landing on you. Map it at your current size, check it against the rules, and export it — the free RACI Matrix Engine is at https://tools.exiuss.com/raci-matrix.