Decision rights design

The decision bottleneck

Organizations do not move at the speed of their processes. They move at the speed of their decisions. A process can be optimized to operate in hours, but if the decisions within that process take weeks, the process takes weeks. The speed of organizational decisions is determined not by the complexity of the decisions themselves but by the clarity of the decision rights — who has the authority to decide.

Gary Hamel observed that in most organizations, the hierarchy exists primarily to make decisions — and the hierarchy's decision-making function has become a bottleneck. Decisions that could be made in minutes by the person closest to the situation instead take days or weeks as they travel up the hierarchy, wait for attention, receive approval, and travel back down. The hierarchy is not adding value at most of these decision points — it is adding delay (Hamel, 2007).

The decision bottleneck is not caused by incompetent leaders who hoard authority. It is caused by ambiguous design. When decision rights are not explicitly defined, the default behavior is escalation — because making a decision without clear authority is risky (what if my boss disagrees?), while escalating a decision is safe (I am being appropriately deferential). The rational individual response to ambiguous authority is to not decide — which produces organizational paralysis that looks like indecisiveness but is actually rational risk avoidance.

The RACI framework and its limitations

The most common tool for defining decision rights is the RACI matrix — Responsible, Accountable, Consulted, Informed. For each decision type, the matrix specifies who performs the work (Responsible), who owns the outcome (Accountable), who must be consulted before the decision (Consulted), and who must be informed after the decision (Informed).

RACI is useful as a starting point but has three limitations. First, it does not distinguish between different types of decisions — a hiring decision and a technical architecture decision have different characteristics but may be assigned the same RACI. Second, it is static — RACI matrices are created once and rarely updated, becoming increasingly disconnected from actual practice. Third, it conflates authority with involvement — being "consulted" can mean "must approve" or "provides input that can be ignored," and the matrix does not distinguish between these very different levels of involvement.

More effective decision rights frameworks specify three elements that RACI alone does not capture.

Decision type classification

Not all decisions are alike. A useful classification distinguishes three types:

Reversible decisions (Type 2 in Jeff Bezos's framework) can be undone at low cost — feature experiments, team process changes, vendor selections for small contracts. These decisions should be made quickly by the person closest to the situation, with minimal approval overhead. The cost of a wrong decision is small; the cost of a slow decision (missed opportunity, organizational drag) is large.

Irreversible decisions (Type 1) cannot be undone or are very costly to reverse — major acquisitions, platform migrations, organizational restructurings, key executive hires. These decisions deserve careful deliberation, broad input, and senior authority. The cost of a wrong decision is large; the cost of a slow decision (additional due diligence) is justified.

Cascading decisions affect other decisions downstream — setting a strategic direction, choosing a technology platform, establishing a pricing model. These decisions require broad input because they constrain the decisions of many other people and teams. The decision-maker must understand the downstream implications, which requires consultation with the people who will be affected.

Decision scope

Decision rights should specify the scope within which the authority operates. A team lead may have authority to make technical decisions within their team's codebase but not across codebases. A director may have authority to approve hiring within their department but not across departments. A product manager may have authority to prioritize features within their product but not to make commitments that affect other products.

Scope boundaries prevent both undergoverning (no one decides because no one knows if they have authority) and overgoverning (multiple people decide the same thing because their scopes overlap).

Escalation criteria

Decision rights should specify when a decision should be escalated — not as a default but as an exception. Escalation criteria define the conditions under which a decision exceeds the scope of the assigned decision-maker: the dollar amount exceeds a threshold, the decision affects another team's commitments, the decision involves a risk that exceeds the team's tolerance, or the decision sets a precedent that should be set at a higher level.

Clear escalation criteria eliminate the ambiguity that produces default escalation. The decision-maker knows exactly when to decide autonomously and when to escalate — and escalation is the exception rather than the rule.

The principle of subsidiarity

The principle of subsidiarity, borrowed from political theory, states that decisions should be made at the lowest level of the organization that has the information and capability to make them well. Only when a decision exceeds the capacity of a lower level — because it requires information, resources, or authority that the lower level does not have — should it be escalated to a higher level.

Subsidiarity produces three benefits. Speed — decisions made at lower levels travel shorter organizational distances. Quality — decisions made by people closer to the situation are informed by more current, more detailed, and more contextual information. Development — making decisions develops the judgment and capability of the people who make them, producing organizational capacity that top-down decision-making cannot develop.

The most common objection to subsidiarity is risk: "What if they make a bad decision?" The counter-argument is calibration: define the decision scope, provide the information, set the escalation criteria, and accept that some decisions will be suboptimal — because the speed, quality, and development benefits of distributed decision-making outweigh the occasional cost of a reversible mistake.

The Third Brain

Your AI system can help you design decision rights frameworks. Describe the decision types your organization makes and the current decision authority structure, and ask: "Design a decision rights framework that classifies these decisions by type (reversible/irreversible/cascading), assigns decision authority based on the principle of subsidiarity, specifies scope boundaries for each authority level, and defines escalation criteria for when decisions should move to a higher level. For each decision type, what information does the decision-maker need, and how should it be provided?"

From authority to workflow

Decision rights determine who decides. Process design determines the workflow through which decisions are made and implemented. The next lesson, Process redesign, examines process redesign — how changing the flow of work changes organizational outcomes.

---

Sources:

1. Hamel, G. (2007). The Future of Management. Harvard Business School Press.