Skip to content

2.2 Decision Rights and RACI: The Permission Matrix

Ambiguity in authority creates organizational paralysis. When multiple people believe they “own” a decision, the result is endless debate. When no one believes they own it, the result is inaction. Both of these outcomes hinder velocity.

To operate at the required speed, Decision Rights are treated like software permissions. Every major operational action possesses a defined “Owner” (Write Access) and a “Validator” (Read/Check Access).

The individual formally responsible for the quantitative outcome (P&L, quality yield metric, shipping deadline) holds the definitive decision right on how to achieve it.

  • The Principle: When the process breaks and requires critical intervention at 2:00 AM, the person responsible for the outcome is the person who makes the decision.

Operational authority is distributed by Risk Class. These rights are essential for speed and accountability and must not be bypassed without a formal, written exception from Executive Leadership.

CategoryDecision TriggerDecision Owner (The DRI)Veto Authority
FinancialDepartment Expense < $1kTeam LeadNone
FinancialExpense > $10k / CapExDepartment Head + CFOCEO
HiringExtending a Job OfferHiring ManagerBar Raiser (Peer/HR)
QualityStop Shipment / Line StopQuality EngineerNone (Safety/Quality cannot be overridden)
CommercialNon-Standard Contract TermsSales DirectorLegal / COO
EngineeringSystem Architecture / StackCTO / Chief EngineerNone
Supply ChainNew Vendor ApprovalProcurement HeadQuality (if the factory audit fails)

In electronics manufacturing, the Quality Department holds the final release authority.

  • The Rule: Operations owns the Schedule, but Quality owns the Release.
  • The Scenario: The Sales team urgently needs to ship a batch of units today. The Quality Engineer notices a 0.5% spike in the failure rate during Functional Testing (FCT).
  • The Outcome: The unit does not ship. The Quality Department has Veto power over Revenue the moment technical standards fall out of specification.

The RACI framework is used to define roles for specific execution projects. Because complex RACI charts frequently fail, a streamlined definition is utilized:

  • R = Responsible (The Doer): The individual(s) executing the daily work (writing code, configuring machines, negotiating contracts). Multiple “R”s are allowed.
  • A = Accountable (The Owner): The single individual who owns the final outcome. They hold the “Yes/No” authority. The Rule: There can only be ONE “A”.
  • C = Consulted (The Expert): People required to provide technical input before the decision is finalized. They provide expertise but do not hold a veto.
  • I = Informed (The Broadcast): Personnel notified of the decision after it has been made.

Common RACI Failures:

  1. Too many “A”s: When two people are Accountable, no one is Accountable.
  2. Using “C” as a Veto: Consulted individuals exist to provide data. When the Accountable Owner disagrees with the Consultant, the Owner makes the decision and documents the accepted risk.

Professional disagreement is healthy; operational gridlock is expensive. When two functional leaders cannot agree, the following escalation path must be navigated.

  • The Action: Both parties present a summary of the data supporting their view.
  • The Rule: Data supersedes Opinion. When one side has hard metrics and the other relies on intuition, the data guides the decision.
  • The Action: When the data is truly inconclusive, the formally assigned “A” (Accountable Owner) makes the final call.
  • The Rule: The dissenting party is then obligated to fully support the execution of that decision. Passive resistance undermines the team and is unacceptable.
  • The Action: A formal Decision Memo (see below) must be submitted to the CEO or appropriate Executive.
  • The Rule: Using the CEO as a daily referee is a failure of management alignment. This should be a rare exception.

A written pre-read document must be distributed prior to scheduling a meeting to present a complex decision. This template ensures clarity.

Format Constraint: 1 Page Maximum.

Header: [Decision Title] | [Date] | [Accountable Owner]

1. The Context:

  • What exactly is the business problem? (Maximum 2 sentences).

2. The Options:

  • Option A: (Description + Financial Cost + Operational Risk).
  • Option B: (Description + Financial Cost + Operational Risk).
  • Option C: (Do Nothing - Always include this as the baseline).

3. The Recommendation:

  • Option A is officially proposed for execution because [Data Point 1] and [Data Point 2].

4. The Documented Dissent:

  • Department X disagrees with this approach because [Specific Reason]. This risk has been mitigated by [Specific Action].

5. The Required Action:

  • [Approve / Reject / Discuss]

Final Checkout: Decision rights and RACI: the permission matrix

Section titled “Final Checkout: Decision rights and RACI: the permission matrix”
The CheckThe Requirement
The “One A” RuleEvery project and metric has exactly one designated Accountable person.
Quality AutonomyThe Quality Department can stop mass production without seeking external permission.
The Meeting RuleComplex decision-making meetings require a written Decision Memo pre-read.
Deadlock BreakerWhen data is inconclusive, the designated “A” decides, and the team commits.
DocumentationMajor architectural decisions are formally logged, not lost in chat histories.