Decision Rights and Organizational Coordination

When nobody decides, everybody pays

The most expensive meetings in business are the ones that end without a decision. Attendees leave with action items that overlap, contradict, or wait for "another round of feedback." Six weeks pass. The pricing change, the API launch, the vendor contract, or the hiring plan is still in limbo. Meanwhile, competitors ship, customers churn, and talented employees conclude that the organization cannot execute.

Decision rights specify who recommends a course of action, who must agree, who performs the work, who provides input, and who decides. Without that clarity, two failure modes dominate. Conflict happens when multiple people believe they decide and issue contradictory instructions. Stalemate happens when everyone believes someone else decides, so nothing moves. Both modes feel like politics. Often they are architecture problems: the organization never designed who owns which decision type.

This lesson builds on Lesson 1. You learned that goals, incentives, and accountability must align. Decision rights are the structural complement: they define who can commit resources when accountability owners need help. You will learn RAPID (Bain's Recommend, Agree, Perform, Input, Decide framework) and RACI (Responsible, Accountable, Consulted, Informed, a lighter role matrix). You will learn how span of control and organizational layers trade speed against oversight. You will learn coordination mechanisms from hierarchy to mutual adjustment, and why matrix organizations gridlock without forums. By the end, you should be able to map a stalled decision, redesign roles with exactly one decider, and write escalation triggers that turn ambiguity into a designed path upward.

Decision rights: one decider per decision type

A decision type is a recurring category of choice, not a one-off meeting topic. "Enterprise discount above 20%" is a decision type. "Change to public API breaking compatibility" is a decision type. "Hire above band for critical role" is a decision type. Mature organizations document decision types so teams do not reinvent RAPID for every email thread.

The non-negotiable rule: exactly one D (Decider) per decision type. Multiple deciders create veto grids or parallel commands. Zero deciders create stalemate. The Decider may delegate execution, but the D role must be unambiguous on the org chart or decision charter.

Other roles support the Decider:

Agree is not "everyone who cares." Too many A roles recreate committee paralysis. Limit A to functions with legitimate veto authority: signing contracts (legal), spending beyond budget (finance), accepting security risk (CISO). If an A role blocks frequently, either the Recommend role is submitting incomplete proposals or the decision type should be split.

Input is often over-invited. Large input lists slow Recommend cycles because every stakeholder wants their paragraph in the deck. Good charters say: "Input roles have 48 hours to comment; silence implies consent to proceed to Decide."

War story: a fintech platform team owned core payment APIs. Product teams needed new endpoints for launch. The platform lead believed platform Decided all API shapes. Product leads believed they Decided product-facing APIs within standards. Average wait time for approval: six weeks. Launches slipped. Product bypassed platform with shadow services, creating security debt.

The fix was tiered decision types documented in an architecture RFC (request for comments) template:

One decider per row. Conflicts dropped because the decision type, not the loudest voice, determined who decided.

RACI: a lighter matrix for recurring workflows

RACI maps the same intent with different labels. It is popular in project management and process design because it fits workflow steps.

Accountable in RACI corresponds to Decide or final ownership in RAPID. Responsible often maps to Perform. The critical rule repeats: one Accountable per task.

Consider a concrete RACI for monthly pricing updates at a subscription software company:

Reading the table: Product Marketing Recommends analysis and comms drafts. Finance Recommends margin models and Agrees on floor. Sales Ops Performs system updates. Legal Consults on comms compliance. The GM is Accountable/Decider for publish.

A common RACI failure is marking everyone Consulted on every step. That produces the six-week email loop. Another failure is dual Accountable on one step ("Product and Finance both A"). Split the step or elevate D to a parent role.

RACI works well for SOPs (standard operating procedures, documented repeat processes). RAPID works well for strategic or contentious decisions. Many organizations use both: RACI on monthly pricing, RAPID on entering a new country.

Span of control and layers: speed vs oversight

Span of control is the number of direct reports a manager supervises. Layers are levels between frontline and CEO.

Wide span (10 to 15 direct reports) creates a flat organization. Information travels in fewer hops. Frontline employees often have more autonomy because managers cannot micromanage fifteen people. The cost is less coaching bandwidth per person and fewer promotion levels for high performers.

Narrow span (4 to 6) creates taller hierarchies. Managers can coach deeply and review work closely. The cost is slower communication, higher overhead, and risk that each layer filters or distorts signal.

Startups are flat by necessity: everyone is visible to the founder. Scale adds layers for specialization (platform security, regional sales, compliance). Reorganizations should follow decision bottlenecks, not consulting fashion. If the CEO is the accidental D on fifty decision types, adding a layer with delegated D rights may speed execution more than another cross-functional task force.

Layers add coordination cost. Each hop can delay escalation, soften bad news, or reinterpret strategy. When you hear "the frontline does not know the strategy," layers are often part of the distortion chain. Lesson 5 addresses translation to frontline behaviors; here the lever is reducing unnecessary approvers and documenting who decides.

Coordination mechanisms beyond the org chart

Henry Mintzberg described how organizations coordinate work. Managers choose mechanisms based on task uncertainty and interdependence.

Hierarchy works when authority is clear and speed matters. Military operations, regulatory responses, and factory safety stops fit hierarchy.

Standards and rules encode repeat decisions so they do not require meetings. Expense policy, coding standards, and brand guidelines are coordination by rule. Lesson 3 covers SOPs in execution cadence.

Mutual adjustment is real-time coordination among peers. Cross-functional product teams adjust daily in standups. Matrix organizations depend on mutual adjustment, which fails without a forum that can resolve conflicts when peers disagree.

Slack and buffers absorb uncertainty: inventory, schedule float, extra budget. Buffers cost money; they buy time for coordination without escalation.

Technology platforms coordinate through shared data and workflows: customer record, ticket system, product analytics. Platform teams succeed when decision rights on the platform are as clear as rights in the business org.

Matrix gridlock war story: a global retailer ran category managers (merchandising) and country GMs (P&L) in matrix. Category Decided assortment globally. Country GMs Decided local pricing and promotions. Neither charter defined promotional depth on global SKUs. Promotions conflicted. Margin eroded. Fix: a weekly assortment and promo forum with one D (chief merchant) for conflicts, RACI on promo calendar steps, and escalation if local promo exceeded 15% depth without finance Agree.

Escalation: designed paths, not failure

Escalation is the process of moving a decision to a higher D when thresholds trigger. Escalation is not shame. It is insurance against local optimization and unresolved conflict.

Good escalation charters specify:

Without triggers, teams escalate too early (CEO inbox overload) or too late (customer already gone). Lesson 1 linked accountability to weekly review; escalation is the exception path when weekly owners cannot decide within their authority.

Example escalation RACI for security incidents:

Severity classification Decides at CISO level until trigger for CEO Agree (national press, >100K records). Clear D prevents parallel press releases and ad hoc IT fixes.

ApexCloud sells data warehouse software. A product team wants to launch a public beta API. Platform, security, and legal have blocked or delayed past launches. CEO wants a 30-day beta start.

Part A: Current chaos (fact pattern)

Last launch: 14 weeks from RFC to beta. No written decision types.

Part B: RAPID redesign

SLA: D responds in 3 business days or escalates to CEO per trigger.

Part C: RACI for beta launch checklist (excerpt)

Go/no-go Accountable: Product VP (D). One row, one A.

Check: Each decision type has exactly one D ✓. Beta path has max two A roles (security, legal only when triggered) ✓.

Part D: Managerial read

CEO calendar should not be the default D. The redesign moves 80% of beta launches to Product VP D, reserving CEO for escalation when security and product disagree on data class. Board question: "How many launches per year require CEO decision?" If the answer is more than a handful, decision rights are still broken.

Union Ridge Bank has 200 branches. Branch managers want faster vendor hires for local marketing. Corporate procurement wants control. Average approval time: 22 days. Local campaigns miss seasonal windows.

Part A: Threshold table (before)

Branch managers often split invoices to stay under $5K (gaming). Regional directors lack marketing Input from central brand team.

Part B: Redesigned rights + RACI

Anti-gaming: aggregated vendor spend per quarter triggers retroactive review if split invoices detected.

RACI for local campaign execution:

Part C: Results after one quarter

Check: Thresholds cover all spend ✓. Each band has one D ✓.

Part D: Managerial read

Procurement Agrees on risk, not on every poster order. Brand Agrees on template, preserving coordination without central D on trivial spend. The operator lesson: widen D at the edge where information is local; keep A on finance and brand where risk is systemic.

Helio Robotics manufactures warehouse robots. Software releases require firmware, cloud, and safety certification. Current state:

• Firmware lead and cloud lead both claim Decide on release date.
• Safety reviews average 18 days; no SLA.
• Last release slipped 5 weeks; customer penalties $400K.

Tasks:

1. Write RAPID for decision type "Production release to installed base."
2. Write RACI for the release checklist: code freeze, safety sign-off, customer comms, rollout.
3. Propose two escalation triggers with time boxes.
4. Explain why exactly one D matters here in one paragraph.

Solution

1. RAPID

2. RACI (excerpt)

Note: Safety A on sign-off means no release without certification. VP Eng D on waiver only if safety documents residual risk.

3. Escalation triggers

• Safety review open > 10 business days → escalate to COO (chief operating officer) with packaged risk and customer penalty schedule.
• Cross-team disagreement on severity of bug → escalate to VP Eng within 24 hours; if unresolved in 48 hours, CEO D on ship/hold.

4. Why one D

Dual D on release date lets firmware and cloud optimize local schedules while customers experience one product. Penalties attach to the integrated release, not to subcomponents. A single D forces tradeoffs visible in one decision: ship with known cloud bug vs hold for firmware delay. Without that, teams negotiate indefinitely and penalties accrue.

Check: One D on production release ✓. Safety retains legitimate A on certification ✓.

A 900-person company moves to matrix: product lines (P&L owners) × geography (country managers). Country managers Decide local pricing. Product GMs Decide global list price. Conflict on discount depth.

Tasks:

1. Draw the failure mode in prose (who wins locally, who loses globally).
2. Design one forum + one D for discount conflicts.
3. Write a RACI row for "Approve enterprise discount > 25% off list."

Solution

1. Failure mode

Country managers Decide deep discounts to hit local quota. Product GMs see global margin erode and brand price integrity collapse. Enterprise customers arbitrage across countries. Finance sees unpredictable ASP (average selling price). Sales learns that loudest country wins, not best economics. Global product Decides list price but not realized price, so list price becomes fiction.

2. Forum and D

Weekly Deal Desk forum: R = deal strategist, I = country mgr + product GM, A = finance on margin floor, D = Chief Revenue Officer for discounts > 25%. SLA: 48-hour turn. Escalation to CEO if contract > $2M ARR.

3. RACI row

Check: One D on discount approval ✓. Finance A enforces floor ✓.

Key takeaways

• Exactly one decider per decision type; document RAPID or RACI before debating options.
• RACI fits recurring workflows; RAPID fits contentious or strategic decisions; both require one accountable owner.
• Span, layers, and matrix design trade speed against oversight; matrix needs forums with a named D.
• Escalation triggers and time boxes turn ambiguity into a designed path, not a political contest.

1. Pick a decision that stalled recently. Map actual roles (even if chaotic) to RAPID. Redesign with one D.
2. Find a recurring process and write a five-row RACI. Flag any step with dual Accountable.
3. Continue to Lesson 3: Execution Systems and Operating Cadence.