Responsibility Matrix (RACI)

This document explains the RACI responsibility matrix used for Appcircle Internal Docs and related governance workflows. The matrix itself lives in an Excel file and is treated as the source of truth.

Info

Source of truth (Excel)
- Download / Open the Responsibility Matrix (Excel)
- This Markdown page explains how to interpret and maintain the Excel matrix.

Purpose

• Make ownership explicit: who executes, who decides, who must be consulted, and who must be informed.
• Prevent “hidden ownership” and reduce decision ambiguity.
• Provide a clear escalation path when work spans multiple teams.

RACI definitions

RACI legend

• R (Responsible): The doer(s). Executes the task and produces the output.
• A (Accountable): The owner. Ultimately responsible for the outcome and the final decision.
• C (Consulted): Provides input or review before finalization (two-way communication).
• I (Informed): Kept up to date after decisions/changes (one-way communication).

Practical rules of thumb

Tip

If you only remember one thing: Every row must have exactly one A.

Excel matrix schema

The Excel file contains the matrix as a simple table with only these columns:

Column	What it means	How to fill it
Task	The activity/process being owned	Use verb-first and be specific (e.g., “Publish release notes”, “Update mkdocs.yml navigation”)
R (Responsible)	Who executes the work	One or more roles/teams that do the task (comma-separated)
A (Accountable)	Who owns the outcome and makes the final call	Exactly one role/team (avoid multiple A)
C (Consulted)	Who must be consulted/review before finalization	Add only mandatory reviewers (comma-separated)
I (Informed)	Who should be notified after completion	Stakeholders to notify (comma-separated)
Escalation	Who resolves blockers / conflict, and the escalation target	Prefer a stable role (e.g., “EM”, “Head of DevOps”, “CTO”)
Description	What “done” means	1–3 sentences with acceptance criteria / scope notes

Best practices

Use these rules to keep the matrix consistent, actionable, and easy to operate.

Core RACI rules

1. Exactly one A per task

   • No shared accountability.
   • If multiple parties must agree, set one A and list others as C.

2. R can be multiple

   • Multiple people/teams can execute.
   • If execution spans teams, prefer listing teams/roles, not individuals.

3. Keep C minimal and meaningful

   • Only add Consulted when input is required before finalization.
   • If someone only needs visibility after the fact, they belong in I, not C.

4. I is notification, not approval

   • I should not block the work.
   • A task should not require acknowledgement from I to be considered done.

5. Write people/teams consistently

   • Prefer teams/roles over individuals (more stable).
   • If you use mentions, keep a consistent format (e.g., @team/devops, @team/security).
   • For multiple entries in a cell, use comma-separated values.

6. Avoid common anti-patterns

   • Multiple A values (“shared accountability”) → decision deadlocks.
   • Everyone in C → review becomes a bottleneck.
   • Putting key reviewers into I → quality/compliance gaps.
   • Putting CTO as A on every row → removes operational ownership and slows decisions.

Core RACI rules

1. Exactly one A per task

   • No shared accountability.
   • If multiple parties must agree, set one A and list others as C.

2. R can be multiple

   • Multiple people/teams can execute.
   • If execution spans teams, prefer listing teams/roles, not individuals.

3. Keep C minimal and meaningful

   • Only add Consulted when input is required before finalization.
   • If someone only needs visibility after the fact, they belong in I, not C.

4. I is notification, not approval

   • I should not block the work.
   • A task should not require acknowledgement from I to be considered done.

5. Prefer roles over people

   • Roles survive org changes.
   • Use individuals only when responsibility is truly person-specific.

6. Avoid “CTO as A everywhere”

   • CTO may be the ultimate executive owner, but operational accountability must sit with the closest decision-maker.
   • Use CTO as A only for strategy-level decisions or risk acceptance that cannot be delegated.

Task writing rules

• Task should be clear and measurable:

  • Good: “Perform production release”, “Publish security policy”, “Update docs navigation”
  • Weak: “Release”, “Documentation”, “Security review”

Decision roles (how decisions happen)

• Decision Owner = A

  • A is the final decision-maker (go/no-go, risk acceptance, rollback direction, publication approval).

• Executor(s) = R

  • R implements the decision and delivers the output.

• Reviewers = C

  • C provides required input/review before A finalizes.

• Stakeholders = I

  • I gets notified after changes/decisions.

Escalation best practices

Use the Escalation column to ensure tasks don’t stall.

1. Blocked execution

   • If R is blocked, R escalates to A first.

2. Cross-team conflict

   • If there is disagreement across teams, A decides.
   • If the conflict is about priorities/resources, escalate to the role listed in Escalation (commonly EM / Head of function).

3. Security / Compliance impact

   • If the task can affect security posture, data handling, compliance, or external publishing:

     • Ensure @team/security is C (or A if it is a security-owned decision).
     • If still blocked, escalate to Security Lead (or your defined escalation role).

Tip

Keep escalation targets stable (e.g., “EM”, “Head of DevOps”) so the matrix doesn’t require frequent updates when people change.

How to fill the matrix

1. Define the activity

   • Write a specific, measurable task name.
   • Add a short description of what “done” means.

2. Assign Responsible (R)

   • Add the team(s) or role(s) that execute the work.
   • Multiple R entries are OK.

3. Assign Accountable (A)

   • Choose one owner who:

     • decides go/no-go,
     • accepts risk,
     • owns success/failure,
     • ensures the work is completed.

4. Add Consulted (C)

   • Only include groups that must review or provide input.
   • Prefer “C” for compliance/security-sensitive items.

5. Add Informed (I)

   • Include stakeholders who need visibility after completion.

6. Set escalation

   • Specify the role who resolves blockers if R cannot proceed or there is conflict.

Examples

Example: Release

• The team executes the release → R can be the release squad/on-call engineers.
• The Team Lead / Release Manager owns success and final decisions → A.

Example row:

Task	R	A	C	I	Escalation	Description
Release	@teams/development	Enver	QA	OsmanÇ,Çağkan	OsmanK

Warning

Avoid “hidden ownership”. If a process exists, it must have an explicit A.