Decision rights matrix: a practical playbook for leaders

A decision rights matrix is a structured map that assigns single-point authority for each important decision and specifies the supporting roles required to reach it. Without one, authority often defaults to whoever shouts loudest or whoever has the most senior title in the room, which is rarely the person closest to the data.

To start this week, do three things:

1. Run a decision inventory covering a recent period of time: pull a sample of consequential decisions your organisation actually made.
2. Identify a selection of high-impact decisions from that list, prioritised by revenue, risk, or recurring bottleneck severity.
3. Name one Decider per decision, no exceptions.

Bain's RAPID® framework has codified this logic for decades: one Decide role, used sparingly for Agree, and clear separation between those who recommend and those who act. McKinsey's analysis of large organisations reaches the same conclusion: without explicit decision-rights architecture, RACI charts produce relitigation and delay rather than clarity. Oakandnine's live org-mapping platform is built to operationalise exactly this kind of structure, connecting decision authority to real workflow data rather than static documents.

Key takeaways

A decision rights matrix works only when a single Decider is named for every mapped decision type, authority is delinked from the org chart, and the matrix is reviewed on a fixed cadence with measurable KPIs.

Table of Contents

• What a decision rights matrix actually is
• Why RACI often produces slower, worse decisions
• Proven alternatives: RAPID, D‑R‑C‑I and when to use each
• How to build your matrix from scratch
• Which decisions to map first
• Pilot, roll-out, governance and measurement
• Implementation mistakes that derail adoption
• A practical example matrix
• How live org-mapping keeps the matrix current
• The gap between designing authority and distributing it
• How Oakandnine supports your decision rights pilot
• Sources

What a decision rights matrix actually is

An org chart shows who reports to whom. A RACI task map shows who does what on a project. A decision rights matrix does something different: it maps decision types to authority roles, making explicit who has the final call, who must be consulted, and who simply needs to know the outcome.

The canonical roles are:

• Decide (D): Single point of authority. One person per decision, always. This role cannot be shared.
• Recommend (R): Proposes the decision with supporting analysis. May be held by multiple people.
• Consult (C): Provides input before the decision is made. Two-way dialogue, not a veto.
• Inform (I): Notified after the decision is made. No input required.
• Perform (P): Executes the decision once made. Common in operational matrices.
• Agree (A): Holds formal approval authority, typically for legal or regulatory sign-off. Use sparingly.

A single matrix row might illustrate a typical allocation of roles to eliminate common meeting loops.

The matrix differs from an org chart in a critical way: authority belongs to proximity to data and the work, not to title alone. A senior vice-president may sit in the Inform column for a decision their direct report owns.

Why RACI often produces slower, worse decisions

RACI is not wrong in principle. It fails in practice because the Accountable role is routinely assigned to more than one person, which means no one is truly accountable. McKinsey's analysis of large organisations documents this pattern directly: RACI charts scale poorly because they conflate responsibility (doing the work) with authority (making the call), and they give no guidance on what happens when the two conflict.

Common failure modes:

• Multiple Accountable entries: Two or more people listed as Accountable creates a diffusion of ownership. When a decision goes wrong, everyone points elsewhere.
• Overuse of Consult: Listing ten stakeholders as Consulted turns every decision into a committee exercise. Speed collapses.
• Confusion between Responsible and Accountable: Teams treat them as synonyms. They are not. Responsible means you do the work; Accountable means you own the outcome.
• No escalation path: RACI charts rarely specify what happens when the Accountable person is unavailable or when two Accountable owners disagree.
• Built from the org chart, not from real decisions: Most RACI exercises start with boxes and lines rather than with the decisions that actually caused bottlenecks last quarter.

A 2019 MIT CISR survey of 1,311 companies found many were rated "not effective at all" to only "moderately effective" at changing decision rights to support digital transformation. The root cause included overcentralisation: too many decisions requiring senior sign-off, with no clear mechanism to redistribute authority.

The corrective is not a better RACI. It is a framework that enforces single-point accountability by design.

Proven alternatives: RAPID, D‑R‑C‑I and when to use each

Two frameworks consistently outperform RACI in mid-market and enterprise settings.

RAPID (Bain & Company)

Bain's Decision Rights Tools define five roles:

• R — Recommend: Proposes the decision with analysis and a preferred option.
• A — Agree: Holds formal veto or approval power. Bain is explicit: use this role sparingly, typically only where legal or regulatory approval is genuinely required. Overuse of Agree is the fastest way to recreate RACI's bottlenecks inside a supposedly better framework.
• P — Perform: Executes the decision. Useful in operational contexts where implementation accountability needs to be named separately from decision authority.
• I — Input: Provides information or expertise before the decision is made, without formal consultation rights.
• D — Decide: Single-point authority. One person, one decision type. Non-negotiable.

D‑R‑C‑I (Decide, Recommend, Consult, Inform)

A leaner variant that drops Agree and Perform. Better suited to strategic and cross-functional decisions where execution is handled through separate process tools. Most mid-market organisations find D‑R‑C‑I easier to adopt initially, then layer in Perform and Agree selectively as the matrix matures.

When to use Agree: Reserve it for decisions with genuine legal, regulatory, or fiduciary sign-off requirements — board-level spend thresholds, data-protection approvals, or regulated product launches. Applying Agree to ordinary operational decisions adds a veto point without adding value.

McKinsey, Bain, and Deloitte each approach the problem from a different angle: McKinsey focuses on architecture and relitigation costs, Bain on role clarity and speed, and Deloitte on building the decision inventory that feeds the matrix in the first place. All three converge on the same principle: one Decider, clear role separation, and a governance cadence to keep the matrix current.

How to build your matrix from scratch

The most common mistake is opening a spreadsheet and starting with roles. Start with decisions instead.

1. Assemble recent decisions. Pull the last 30–50 consequential decisions your organisation made. Include ones that stalled, were relitigated, or required unexpected escalation. These are your signal.
2. Group into decision types. Collapse similar decisions into 10–20 recurring types. "Approve new supplier above £100,000" is a decision type. "Approve this specific invoice from Supplier X" is an instance. Map types, not instances.
3. Prioritise by impact. Not every decision type deserves a matrix row. Focus on those that affect revenue, introduce legal or financial risk, or represent recurring operational bottlenecks, as Deloitte's guidance recommends.
4. Assign a single Decider and complementary roles. For each decision type, name one person in the Decide role. Then assign Recommend, Consult, and Inform. If you find yourself wanting to put two people in Decide, you have found a governance conflict that needs resolving before the matrix can work.
5. Set thresholds and delegation rules. Specify the conditions under which authority shifts. "CFO decides on contracts above £500,000; Finance Director decides below that threshold" is a threshold rule. "In the CFO's absence, authority passes to the Finance Director" is a representation rule. Both belong in the matrix.

Pro Tip: Write each decision row as a complete, bounded statement: include the decision type, the financial or operational threshold, and the time horizon. "Approve capital expenditure above £250,000 for the current financial year" is durable. "Approve big spending" is not. Ambiguous rows generate the same disputes the matrix was built to prevent.

Version-control the matrix from day one. A document with no version history becomes a political artefact within six months: people cite the version that suits them. Use a shared platform with edit history, or at minimum a dated naming convention and a single owner responsible for updates.

Which decisions to map first

Trying to map everything at once is a reliable way to produce a matrix that no one uses. Prioritise ruthlessly.

Score each candidate decision type on three dimensions, using a 1–5 scale:

• Impact: How significantly does a poor or slow decision here affect revenue, margin, or customer outcomes?
• Frequency: How often does this decision type recur? Weekly decisions with unclear authority cause more cumulative damage than annual ones.
• Risk: What is the downside of a wrong call? Legal exposure, safety implications, or significant financial loss all push the score up.

A decision type scoring 4–5 across all three dimensions goes into the first version of your matrix. Anything scoring below 3 on two or more dimensions can wait.

Beyond that threshold, the matrix starts to replicate the committee culture it was designed to replace. Most decisions should have a clear Decider who can act without a vote.

Finding the bottleneck in a process before you begin scoring will sharpen your prioritisation considerably. The decisions that consistently create queues or require senior intervention are almost always the ones to map first.

Pilot, roll-out, governance and measurement

A decision rights matrix that lives in a document but never changes behaviour is a governance theatre prop. Implementation is where most organisations lose the gains they designed on paper.

1. Run an 8–12 week pilot. Select one function or business unit where decision bottlenecks are visible and the leadership team is willing to test new authority structures. Avoid piloting in a function undergoing simultaneous restructuring.
2. Train before you publish. Every person named in the matrix needs to understand their role, what it does and does not authorise them to do, and how to escalate when a decision falls outside their threshold. Training is not optional; it is the mechanism by which the matrix becomes behaviour rather than policy.
3. Publish the matrix formally. Make it accessible to everyone it affects. A decision rights framework that only the leadership team can see will be ignored by the people it is meant to guide.
4. Define escalation paths explicitly. What happens when the named Decider is unavailable? What happens when a decision exceeds the threshold? Who is the escalation point, and what is the expected response time? These rules belong in the matrix, not in someone's head.
5. Integrate with existing process and project tools. A matrix that sits outside your project management or workflow system will be bypassed the moment a deadline creates pressure. Map decision checkpoints into your existing process flows wherever possible.

Measurement matters: Track three KPIs from the pilot's first week. First, time-to-decision: how long from the point a decision is triggered to the point it is made. Second, implementation lag: the gap between a decision being made and action being taken. Third, percentage of decisions with a single named Decider. Harvard Business School's guidance is clear that accountability without metrics and reporting is accountability in name only. Review these KPIs quarterly in fast-growth environments, biannually in more stable ones.

Operational efficiency improvements compound quickly once decision bottlenecks are cleared. The pilot data will tell you where to expand next.

Implementation mistakes that derail adoption

Most matrices fail not because the framework is wrong but because the implementation ignores organisational reality.

• Overcentralisation: Assigning Decide to the CEO or MD for decisions that could safely sit one or two levels lower. Remedy: Apply a delegation test — if the Decider needs to be briefed before they can decide, the decision probably belongs lower in the organisation.
• Overuse of Agree: Adding Agree roles to decisions that have no genuine legal or regulatory requirement. Remedy: Challenge every Agree entry. If the justification is "they need to be comfortable with it," that is a Consult, not an Agree.
• Building from the org chart: Designing the matrix around how authority should work rather than how it does work. Remedy: Start with the decision inventory. If a row shows two Deciders, you have found a real conflict that needs resolving before the matrix can function.
• Mapping too many low-value decisions: A 200-row matrix is unmanageable. Remedy: Apply the impact/frequency/risk scoring above and cut anything that scores below threshold.
• Weak or absent escalation rules: When the named Decider is unavailable and no representation rule exists, the decision defaults to whoever is most senior in the room. Remedy: Every row needs a named escalation path and a representation rule.

A practical example matrix

The table below uses D‑R‑C‑I notation with a single Decider enforced per row. Thresholds and escalation rules are embedded in the decision description.

How to read this table: Each row represents a decision type, not a single instance. The Decide column holds exactly one role. Consult entries are two-way conversations that must happen before the decision is made. Inform entries receive notification after the fact.

The GDPR row shows a near-Agree function with decisional authority where regulatory accountability exists, illustrating delinked authority.

Escalation rule example: For capital expenditures above a specified threshold, if the CFO is unavailable beyond a certain time, authority escalates to the CEO for urgent decisions; deferrable decisions wait for the CFO's return. This rule can be noted with the decision type.

How live org-mapping keeps the matrix current

A static spreadsheet degrades from the moment it is published. People leave, structures shift, thresholds become outdated, and within a year the matrix reflects the organisation as it was rather than as it is. This is not a failure of intent; it is a failure of tooling.

A live organisational model solves this by connecting decision authority to real workflow data. When a role changes hands, the matrix updates. When a process bottleneck is detected, the relevant decision row surfaces automatically for review. Representation rules can be encoded as logic rather than footnotes, so they actually execute when the named Decider is unavailable.

Oakandnine's platform is built for exactly this: it maps decisions into a live organisational model, integrates with existing process and project tools, and provides real-time alerts when implementation lag or bottleneck patterns suggest a decision-rights gap. For mid-market companies running their first pilot, this removes the version-control problem entirely and gives leadership a single source of truth rather than a folder of competing spreadsheets.

Pro Tip: When integrating your decision rights matrix with project management tools such as Jira, Monday.com, or Microsoft Planner, map decision checkpoints as workflow gates rather than as comments or documentation. A gate that requires the named Decider's input before a stage advances enforces the matrix in the flow of work, not as a separate governance exercise.

Change management software guidance for mid-market teams can help you choose the right tooling layer to support adoption during roll-out.

The gap between designing authority and distributing it

The conventional wisdom on decision rights is that the hard part is the framework design. In practice, the hard part is the distribution conversation.

Most leadership teams can agree on a framework in a workshop. What they struggle with is the moment when the matrix requires a senior leader to move from Decide to Recommend on a decision they have historically owned. That conversation is not a governance exercise; it is a power transfer. Treating it as anything less is why so many matrices are approved in principle and ignored in practice.

The most durable matrices are built by leaders who understand that retaining strategic authority while delegating execution is not a loss of control. It is the mechanism by which an organisation scales without the CEO becoming the bottleneck for every material decision. The Harvard Business School analysis frames this precisely: authority must be paired with information and incentives, not held as a status signal.

You have documented a bottleneck.

How Oakandnine supports your decision rights pilot

Mapping decision authority on paper is a start. Keeping it live, connected, and measurable is where most organisations need support.

Oakandnine works with mid-market leadership teams to build decision rights into a live organisational model, not a static document. The platform integrates your people, processes, and systems into a single connected framework, so when a decision-rights gap creates a bottleneck, you see it in real time rather than in a quarterly retrospective.

A typical pilot runs several weeks: Oakandnine maps your current decision inventory, identifies a selection of highest-impact decision types, assigns roles using RAPID or D‑R‑C‑I notation, and integrates the matrix into your existing workflow tools. Deliverables include a versioned decision rights matrix, escalation rules, and a governance cadence tied to measurable KPIs.

To scope a pilot for your organisation, request a demo at Oakandnine and a consultant will outline the process within two working days.

Sources

These are the primary references behind this playbook. Each one is worth reading in full when you are making the case for governance change with peers or a board.

• Getting decision rights right (Deloitte)
• Decision rights and digital transformation (MIT CISR)
• Management tools — Decision rights tools (Bain & Company)
• The limits of RACI—and a better way to make decisions (McKinsey)
• Decision Rights: Who gives the green light? (Harvard Business School Working Knowledge)

Recommended

• Change Management Software: A Mid-Market Buyer's Guide
• Digital transformation best practices for UK mid-market leaders
• Improve margin strategy for mid-market leaders
• Oakandnine — Map and optimise your organisation