Responsibility matrix for a small team: tasks and accounts

What is a responsibility matrix?

A responsibility matrix, also called a responsibility assignment matrix, lists your work down the side and your people across the top. Each cell says what that person has to do with that job: do it, answer for it, give input or just be told. It replaces "I thought you had that" with a sentence anyone can read.

The best-known version is the RACI chart. If you want the letter codes explained with a filled-in example, read the RACI matrix template. This guide is about the part that template cannot cover alone: making the matrix work for a team of two to six people, and extending it to the accounts and money that keep the project alive.

Why small teams need one even when everyone talks daily

Big organisations use a responsibility matrix because nobody knows everyone. Small teams think they don't need one because they do. The trouble is different. In a two- or three-person team, every job gets done by whoever happened to be there first. That works until one of three things happens:

• Someone is away. A renewal email arrives and nobody knows whose job it is.
• Someone leaves. The accounts they opened on their own card and their own email leave with them.
• Someone disagrees. Two people each assumed they would make the call, and now each thinks the other overstepped.

None of these needs a dispute. They only need a gap. A responsibility matrix finds the gaps while everyone is still on good terms.

The two tables you need

Keep two separate tables. Mixing them makes both unreadable.

The first table is about behaviour. The second is about control. Control is what you lose when a person disappears, so it deserves its own table.

How to build the task matrix in 30 minutes

1. List 8 to 15 recurring jobs. Think in verbs: ship a release, answer support email, pay the bills, renew the domain, post the weekly update, approve a refund, back up the data. Skip one-off tasks.
2. Write the names across the top. One column per person. Add a column for "nobody yet" if you are honest about it.
3. Pick one person who answers for each row. This is the single most important step. Two people answering for the same job means nobody does. Mark that person with an A.
4. Mark who does the work. Use R. It can be the same person as the A.
5. Add C and I sparingly. C means "asked before the decision". I means "told after". If everyone is C on everything, decisions slow down and the matrix stops meaning anything.
6. Read each row aloud. If you cannot say it in one sentence ("Dana does it, Sam answers for it, Lee gets told"), the row is unclear.
7. Look for empty rows. A job with no A is an unowned job. Fix those first.

A worked task matrix (illustrative)

Three people building a small web product. The names and tasks are invented for the demonstration.

Every row has one A. Ana answers for the money and the domain. Piotr answers for releases and backups. Mia answers for customers. Nobody had to argue to get here: they just had to read the table together.

The second table: accounts and assets

Now list what the project depends on. Be literal. Open each service and note whose login it really is.

• Owner: the person whose account holds it. If the account is in one person's name, that is the owner, however you feel about it.
• Payer: whose card or bank pays. Often different from the owner.
• Backup admin: a second person who can act if the owner is unavailable.
• Recovery: where password resets and security codes go. A personal inbox or phone number is a single point of failure.

A worked account matrix (illustrative)

Read the "backup admin" column first. Three of five assets have none. Read the "recovery" column second. Four of five assets depend on one person's inbox or phone. That is what this table is for. Nobody did anything wrong; the project simply grew the way projects grow. But now the team knows exactly which row to fix on Monday.

How to read the result

When both tables are filled in, look for these patterns. They are the whole payoff.

1. One person is A for everything. That is a team of one with helpers. It is fine if you chose it, and a risk if you did not.
2. Someone is A for nothing. They may be a founder in title and a spectator in practice. Talk about it kindly and early.
3. Owner and payer are different people. Common and not wrong, but write down who reimburses whom, and how often. The cost split calculator helps when the split is not even.
4. No backup admin. If the owner is unavailable on renewal day, the project stalls. Add a second admin where the service allows it.
5. Recovery points to a personal account. Move recovery to a team-controlled address where the service allows it, and keep the change recorded.

Where responsibility and ownership differ

A responsibility matrix tells you who does the job. It does not tell you who owns the thing. "Ana renews the domain" is a responsibility. "The domain belongs to the company, not to Ana" is a different statement and needs its own record. Keep the two apart in your head:

If the team has not written down who is entitled to the domain, the code and the customer list, a matrix will not do it for you. The founders agreement template is the place to start, and who owns the domain when cofounders split up explains why this matters.

Keep it alive

A matrix that is filled in once and forgotten becomes wrong in a month. Three habits keep it true:

• Review it on a calendar date. Once a quarter is enough for most small teams. Open both tables and ask what changed.
• Update it when you add a tool. A new subscription is a new row in the account table. Add it the day you sign up, not the day something breaks.
• Update it when a role changes. Someone cuts hours, someone new joins, someone leaves. Each is a prompt to re-read the A column.

The user access review checklist gives you a repeatable way to check who can still log in to what. Pair it with the matrix and you can see both who is supposed to have access and who actually does.

Common mistakes

• Two A's on one row. Pick one. If you cannot, the decision itself needs splitting into two decisions.
• Matrix of titles, not names. "Engineering" cannot answer for anything. A person can.
• Too many rows. Past about 15 jobs, the table stops being read. Group related jobs or drop the rare ones.
• Skipping the account table. This is the commonest and most expensive mistake. Tasks are visible every day. Accounts are invisible until the day they are needed.
• Treating it as a performance tool. The matrix is for clarity, not blame. If it is used to point fingers, people stop being honest in it.

Copy the starter

Paste these two tables into a spreadsheet or a shared document. Delete the rows you do not need.

What this guide does not cover

It does not tell you how to split equity, draft a legal agreement, or decide who is entitled to an asset in a dispute. It does not cover large-organisation project governance. It is a working method for teams of two to six people who want fewer surprises. If a real dispute is under way, get advice from a qualified professional in your country.

Frequently asked questions

Related

• RACI matrix template
• Team charter template
• Decision log template
• Team charter vs project charter
• Bus factor: who can recover your project?
• Access audit
• Handover checklist
• All co-founder guides and free tools