Build fluency in the vocabulary of naming clear ownership on a cross-team project.
0 / 5 completed
1 / 5
At standup, a dev mentions a chart that names exactly who is Responsible for doing a task, who is Accountable for its outcome, who should be Consulted, and who should just be Informed, for a cross-team project. What is this chart called?
A RACI matrix names exactly who is Responsible for doing a task, who is Accountable for its outcome, who should be Consulted before a decision, and who should just be Informed afterward, for a cross-team project with several stakeholders. An informal assumption with no documented roles risks two different people each assuming the other one owns a task, or a key stakeholder never getting consulted before an important decision. This explicit chart is what keeps a multi-team project's ownership genuinely clear rather than implicitly guessed at.
2 / 5
During a design review, the team wants exactly one person or role designated as Accountable for a given task's outcome, even if several people are jointly Responsible for the actual work. Which capability supports this?
A single, unambiguous Accountable owner per task ensures there's exactly one person ultimately answerable for that task's outcome, even when several people are jointly Responsible for actually doing the work. Designating multiple people as jointly Accountable recreates the classic problem where everyone assumes someone else will make the final call, and no one clearly does. This single-owner rule is one of the most important disciplines a RACI matrix is meant to enforce.
3 / 5
In a code review, a dev notices a project's RACI matrix is reviewed and updated whenever the project's scope or team composition changes, rather than being written once at kickoff and never revisited. What does this represent?
Treating a RACI matrix as a living document updated as a project's scope or team composition changes keeps it an accurate reflection of who's actually responsible and accountable at any given point, rather than a stale snapshot from the original kickoff. Writing it once and never revisiting it risks the documented roles no longer matching reality as the project evolves. This ongoing maintenance is what keeps a RACI matrix a genuinely useful, trustworthy reference rather than an outdated artifact.
4 / 5
An incident report shows a cross-team decision stalled for weeks because two different people each believed they were Accountable for making it, and the project's RACI matrix had never actually been created. What practice would prevent this?
Creating and maintaining an explicit RACI matrix at the start of a cross-team project, naming exactly one Accountable owner per key decision, would have prevented the ambiguity that stalled this decision for weeks. Relying on an informal, undocumented assumption is exactly what let two different people each believe they held that accountability. This documented, explicit ownership is a low-cost, high-value practice specifically for a project spanning multiple teams with genuinely overlapping interests.
5 / 5
During a PR review, a teammate asks why the team documents an explicit RACI matrix for this cross-team project instead of relying on an informal, shared understanding of who's handling what. What is the reasoning?
An informal, shared understanding of who's handling what can quietly break down on a project spanning multiple teams, where each team might reasonably assume a different person owns a given decision. An explicit RACI matrix removes that ambiguity by naming exactly one clear Accountable owner per task. The tradeoff is the upfront effort of actually creating and then maintaining that matrix as the project's scope and team composition evolve.