RACI matrix for systems analyst interviews

Why interviewers ask about RACI

Systems analyst interviews at companies like Stripe, Atlassian, and DoorDash almost always include at least one process question, and RACI sits near the top of the list. It is a cheap signal: if you can sketch a clean responsibility matrix on a whiteboard in two minutes, the panel believes you have actually facilitated cross-functional kickoffs. If you fumble the difference between Responsible and Accountable, they assume you have only read about projects, not run one.

The other reason it shows up is that SAs are professional ambiguity-killers. Most product failures at the spec stage come from unclear ownership — two teams both thinking the other will handle the migration script, or nobody approving the API contract before engineering starts. RACI is the cheapest tool that forces that conversation. Interviewers want to hear that you reach for it when a project has more than five stakeholders and at least one cross-team handoff. Below that threshold, it is overkill and a senior SA will say so out loud.

What RACI actually is

RACI is a matrix where rows are activities (deliverables, decisions, recurring tasks) and columns are roles (not specific people). Each cell holds one of four letters, or stays blank:

The distinction interviewers probe hardest is R versus A. Responsible is the person doing the work; Accountable is the person who takes the blame if the work is wrong or late. They can be the same person on small tasks, but on anything cross-functional they should split. A senior engineer can be R on the implementation while the tech lead is A — that pairing scales much better than collapsing both into one role.

A second distinction worth memorizing: Consulted is two-way, Informed is one-way. If you ask for input and then ignore it, the stakeholder was not Consulted, they were Informed. Mislabeling here is how you end up with a head of design furious that "I was supposed to approve this, why am I seeing it in production."

How to build one

The mechanical steps are straightforward. The judgment is in how you scope it.

1. List activities first, not roles. Start with the deliverables and decisions for the project — usually 8 to 20 rows. Going role-first leads to padding and bloat.
2. List roles, not names. "Tech Lead" not "Priya." People rotate; the matrix should not break when someone changes teams.
3. Fill cells. For each activity, decide who is R, who is A, who needs to be Consulted, who needs to be Informed. Most cells stay blank — that is correct.
4. Validate. Three quick checks: every row has exactly one A; every row has at least one R; no single role is loaded with A on more than ~30% of rows (sign of a bottleneck).
5. Socialize. Walk through it with the team in a 30-minute meeting. Disagreements surface in this meeting, which is the entire point of the artifact.

Worked example: shipping a feature

Here is a typical cross-functional rollout — say, adding a new payment method to a checkout flow. Roles: Product Manager, Systems Analyst, Tech Lead, Backend Dev, QA, Designer.

How to read it. "API contract sign-off — SA is Accountable, Backend Dev is Responsible, PM and Tech Lead are Consulted, QA also Consulted, Designer Informed." That single sentence resolves the who-actually-owns-the-spec fight that derails most checkout projects.

Notice the Designer has both A and R on UI design. That is fine when one role both does the work and owns the outcome — common for senior individual contributors. The rule that "A and R should split" applies when the work is complex enough to need a separate owner, not as a blanket law.

Variants: RASCI, DACI, RAPID

You will get bonus points for naming the variants without being asked, but do not memorize obscure ones — three are enough.

RASCI adds S — Supportive. A Supportive role helps the Responsible person execute (think: a junior dev pairing with a senior, or a designer producing assets for a marketing campaign). Use RASCI when your team has many junior-senior pairs and the helping role would otherwise vanish into "C."

DACI is for decisions, not tasks. Driver runs the meeting, Approver has final say, Contributors bring expertise, Informed get the result. Atlassian popularized this format. Reach for it when you are documenting a one-time decision — "which vendor do we pick" — not a recurring delivery process.

RAPID is Bain's framework: Recommend, Agree, Perform, Input, Decide. It is heavier and used mostly in management consulting. Mention it if asked, do not lead with it.

If the interviewer is from a consulting background, RAPID will land well. If they are from product or engineering, RACI or DACI is the safe bet.

Common pitfalls

The pitfalls below are not theoretical — every one of them shows up in real interview "tell me about a time" stories, and every one of them is the kind of thing senior interviewers listen for.

Multiple Accountables per row. This is the cardinal sin and the fastest way to fail a RACI question. When two roles share A, neither one actually owns the outcome — both assume the other will catch the gap, and nobody does. The fix is brutal: pick one, even if the choice feels arbitrary at first. If you genuinely cannot pick, the activity is too coarse — split it into two rows where each has a clean owner.

Collapsing A and R onto a single manager for every row. When you see a column where one role is A+R on almost everything, you are looking at either a micro-manager or a team of two. Neither scales. In the interview, point this out as a sign you would normally redistribute work — say something like "I would push R down to the senior IC who actually owns the system, leaving the lead on A only." That phrasing reads as a manager who knows how to delegate.

Inflating Consulted and Informed. New SAs love to mark every stakeholder as at least Informed, on the theory that more communication is safer. In practice this creates meeting bloat and notification fatigue. The rule of thumb: if a role does not need to change behavior based on the information, they should not be on the row at all. The most senior SAs I have seen leave 60-70% of cells blank — and they are right to.

Building it once and never updating. A RACI matrix that lives in a Confluence page from kickoff and never gets touched again is worse than no matrix at all, because the team will reference it as authoritative even after roles shift. Tie updates to a trigger — every quarter, every team change, every major scope change. If your interview answer mentions a maintenance cadence, you will sound noticeably more senior than candidates who only describe the initial draft.

Assigning to people, not roles. When you write "Maria" instead of "Backend Lead," the matrix breaks the moment Maria takes parental leave or moves teams. Roles are stable; people are not. The only exception is RACI on a one-off project that will not outlive its current staff — and even then, a role label costs you nothing.

Forcing RACI where it does not fit. On a team of four people working in one room, RACI is theater. Reach for it when you have at least three teams involved, at least one cross-org dependency, or at least one stakeholder who has historically been surprised by your team's work. Below that threshold, a shared doc and a recurring sync do the same job for free.

Related reading

• AS-IS vs TO-BE for systems analysts
• Soft skills for systems analyst interviews
• Domain glossary for systems analysts
• Systems analyst resume guide
• Definition of Ready and Done for SAs

If you want to drill SA interview questions like this every day, NAILDD has 1,500+ problems including process, requirements, and architecture rounds.

FAQ

Does RACI still work in Agile teams?

Yes, but you use it less formally. Scrum and Kanban already encode some roles — the Product Owner is implicitly Accountable for backlog priorities, the Scrum Master for process. RACI becomes valuable when an Agile team has to coordinate with non-Agile stakeholders — legal, compliance, finance, partner teams — because those stakeholders do not know what a sprint goal is and need an explicit ownership chart. Most senior SAs will tell you they use a lightweight RACI for the cross-team activities only, not for routine sprint work.

What is the difference between Responsible and Accountable in practice?

Responsible is who does the work; Accountable is who takes the blame. Think of a deploy script: the on-call engineer is Responsible for running it, the tech lead is Accountable for whether the deploy strategy was sound. If something breaks, you wake up the on-call to fix it, but you ask the tech lead in the post-mortem why the rollback plan was wrong. The two roles answer different questions and should usually be different people on anything complex.

How big does a project need to be before RACI is worth doing?

A rough heuristic: three or more teams, or five or more named stakeholders, or any project that has historically had ownership confusion. Below that, you are adding process for its own sake. A common mistake junior SAs make is to RACI a two-engineer feature — interviewers will read that as cargo-cult process management and dock you for it.

Can one role appear in multiple cells on the same row?

Yes, the most common combination is A and R on the same row — meaning the person both does the work and owns the outcome. This is fine on small or self-contained activities, and it is the default for design and creative work. The combinations that should not happen are A+C or A+I on the same row — if you are Accountable, you are by definition not just consulted or informed, you own it.

How do you handle stakeholders who insist on being Accountable for everything?

This is half a process question and half a soft-skills question, and interviewers love it. The clean answer: bring the matrix into a working session, walk through the rows where they have claimed A, and ask them concretely what they will do if that activity slips. Usually the answer reveals that they actually want to be Consulted, not Accountable — they want visibility, not ownership. Move them to C and the conflict resolves itself. If they truly want A on everything, that is a separate organizational conversation and not something a RACI matrix alone can fix.

Is there a tool you should use to build RACI matrices?

No. A markdown table, a Confluence page, or a single tab in a Google Sheet are all fine. The artifact's value is the conversation it forces, not its formatting. Interviewers who push you toward a specific tool are usually testing whether you over-engineer process — the right answer is "whatever the team already uses, as long as it is one source of truth and gets reviewed quarterly."