HIVE80lab — Ops notes

RACI matrix template: stop asking who owns this

One page. Every recurring decision in the business, four letters per row, one name per letter. The cure for the meeting that ends with “so… who’s actually doing this?” Works best next to the role-permission matrix (what each role may touch) and the decision log (what was decided and when).

RACI assigns every decision four roles: R — the one person who does the work; A — the one person who owns the outcome and can settle the row (accountable); C — the short list consulted before the decision; I — the short list informed after it. It takes thirty minutes to build and saves an hour a week for as long as the team exists. The template below is tuned for small teams, where the textbook version quietly fails: nobody has one job, so “R” written as a department means nobody does the work.

The four letters, defined once

LetterMeansThe small-team correction
R — ResponsibleDoes the workExactly one name. Never a team, never “marketing”. If two people are genuinely both doing it, it is two rows.
A — AccountableOwns the outcome; settles disagreementsOne person, and a person. On a team under twenty, A and R may be the same human for most rows — that is not a violation, it is speed.
C — ConsultedGives input before the decisionTwo-way, time-boxed. A name on C owes an opinion by a date; a C that never answers stops being consulted and becomes an I.
I — InformedTold after the decisionOne-way, batched. No consent required, no veto. If being informed feels bad, they should have been C — and C has a deadline.

The five-column table

The whole matrix is one table with five columns and rows you can read in one screen: decision or deliverable (a noun phrase a new hire understands), R (one name), A (one name), C (short list), I (short list). One page, twenty to forty rows: the recurring decisions where ownership fog costs real days — pricing changes, incident severity calls, vendor renewals, publishes, purchases, who approves access grants (that side lives in the role-permission matrix; RACI says who decides, the permission matrix says what the hands may touch).

The four failure modes

Every broken matrix fails in one of four ways, and each has a one-line tell:

1. Two Rs. The split-brain row: two names both “doing the work” means neither does it, and the deadline splits in half instead of the work. Tell: work stalls until one person is embarrassed into it. Fix: pick one R today, move the other to C or I.

2. No A. The orphan decision: a row with an R and no accountable owner means the decision has no arbiter when the Rs disagree or the C-list deadlocks. Tell: the decision lives in a chat thread until someone senior notices. Fix: A is the person whose budget or queue the decision spends — usually the row is theirs already.

3. C-spam. Everyone consulted, nothing ships: the C list is a courtesy list, and every courtesy costs a day of waiting. Tell: “waiting on feedback” appears in every status update. Fix: C list maxes at three, each with a reply-by date; beyond three, the extras are I.

4. The missing I. The surprise: someone is ambushed by a decision they were sure they’d be told about. Tell: “why did I find out from a customer?” Fix: walk the list of people downstream of the decision and name them, then trust the escalation policy to route the exceptions.

The 90-second test

Pick any row and ask one question: if this stalls today, whose name do I call? Not “which team”, not “who cares most” — whose name. If the answer is one name, the row is alive. If the answer is “depends”, the row is two rows. If the answer is “the founder”, the founder is the bottleneck and the row is a delegation waiting to happen — which is exactly what the founder asked for when they wrote the standing orders.

Keep it alive

A matrix reviewed never dies of neglect in one quarter. Three touchpoints keep it breathing: at every project kickoff, write the project’s rows into the same table (new project, new rows, same five columns); at every quarterly ops review, scan for dead names — anyone who left, changed role, or stopped replying comes off every list; after every incident or big win, add the decision everyone had to argue about. The reviewed row that keeps teams honest is the one that changed: “A” moved from founder to ops lead in March — that line in the decision log is what delegation actually looks like.

Three metrics

The matrix earns its keep on three numbers, checked monthly: percent of decisions with a named A (target: 100% — an unnamed A is an orphan); time-to-decision on matrix rows (the point of the page: it should fall, and stay down); escalations resolved without owner-hunting (if people still ask “who owns this?” in chat, the rows with fog haven’t been filled).

Worked example

A fifteen-person SaaS product team. Launch decisions had a pattern: eleven days from “should we ship” to actually deciding, because every launch was a fresh argument about who could say yes. One afternoon with the matrix: forty-one rows — nine had two Rs, six had no A, the C lists averaged 5.5 names (one row consulted the whole 15-person company channel). They cut every C list to three with a reply-by date, named one A per row, merged the duplicate Rs into one owner with a C. The next month: launch decisions landed in under 24 hours, the founder stopped appearing in four threads a week, and the two rows that still stalled were genuinely two decisions — split them, and they stopped stalling too.

Where this fits

The RACI matrix is the decisions layer. It sits next to three siblings: the role-permission matrix is the access layer (who may touch what); the incident severity matrix is the incident layer (who declares what, who leads); the change-freeze calendar is the timing layer (when decisions pause). Own all four and the question “who owns this?” has one answer everywhere in the company — for the rest of the estate, book the small-team ops audit & runbook service.