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 our required speed, we treat Decision Rights like software permissions. Every major operational action in this company has a defined “Owner” (Write Access) and a “Validator” (Read/Check Access).
The Golden Rule of Authority
Section titled “The Golden Rule of Authority”Authority follows Responsibility
Section titled “Authority follows Responsibility”When you are the person formally responsible for the quantitative outcome (the P&L, the quality yield metric, the shipping deadline), you hold the 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.
The Decision Matrix
Section titled “The Decision Matrix”We distribute operational authority by Risk Class. These rights are essential for speed and accountability and should not be bypassed without a formal, written exception from Executive Leadership.
| Category | Decision Trigger | Decision Owner (The DRI) | Veto Authority |
|---|---|---|---|
| Financial | Department Expense < $1k | Team Lead | None |
| Financial | Expense > $10k / CapEx | Department Head + CFO | CEO |
| Hiring | Extending a Job Offer | Hiring Manager | Bar Raiser (Peer/HR) |
| Quality | Stop Shipment / Line Stop | Quality Engineer | None (Safety/Quality cannot be overridden) |
| Commercial | Non-Standard Contract Terms | Sales Director | Legal / COO |
| Engineering | System Architecture / Stack | CTO / Chief Engineer | None |
| Supply Chain | New Vendor Approval | Procurement Head | Quality (if the factory audit fails) |
Critical Control: The Quality Veto
Section titled “Critical Control: The Quality Veto”In hardware 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 final test.
- 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 Model (Simplified for Speed)
Section titled “The RACI Model (Simplified for Speed)”We use the RACI framework to define roles for specific execution projects. However, most RACI charts fail because they become too complex. We use a streamlined definition:
- 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): People who are notified of the decision after it has been made.
Common RACI Failures:
- Too many “A”s: When two people are Accountable, no one is Accountable.
- 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.
Escalation Logic: Breaking Deadlocks
Section titled “Escalation Logic: Breaking Deadlocks”Professional disagreement is healthy; operational gridlock is expensive. When two functional leaders cannot agree, they navigate this escalation path.
Level 1. The Data Review
Section titled “Level 1. The Data Review”- 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.
Level 2. “Disagree and Commit”
Section titled “Level 2. “Disagree and Commit””- 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.
Level 3. The Executive Tie-Breaker
Section titled “Level 3. The Executive Tie-Breaker”- The Action: Submit a formal Decision Memo (see below) 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.
The Standard Artifact: The Decision Memo
Section titled “The Standard Artifact: The Decision Memo”You are expected to distribute a written pre-read document before 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:
- We officially propose executing Option A because [Data Point 1] and [Data Point 2].
4. The Documented Dissent:
- Department X disagrees with this approach because [Specific Reason]. We have mitigated this risk by [Specific Action].
5. The Required Action:
- [Approve / Reject / Discuss]
Final Alignment Checklist
Section titled “Final Alignment Checklist”| The Check | The Requirement |
|---|---|
| The “One A” Rule | Every project and metric has exactly one designated Accountable person. |
| Quality Autonomy | The Quality Department can stop mass production without seeking external permission. |
| The Meeting Rule | Complex decision-making meetings require a written Decision Memo pre-read. |
| Deadlock Breaker | When data is inconclusive, the designated “A” decides, and the team commits. |
| Documentation | Major architectural decisions are formally logged, not lost in chat histories. |