ROOT: Operating Model for Data-to-Decision Execution

By Julian Grijalba |

A framework for closing the data-decision gap. Why organizations have more data but not better decisions.

Citation: Grijalba, J. (2026). ROOT: Operating Model for Data-to-Decision Execution. Working Paper. https://doi.org/10.5281/zenodo.21502520

Abstract

Organizations invest heavily in data infrastructure, cloud platforms, and analytics tools. Yet decision velocity and quality remain unchanged or degrade. Why? Because the problem is not data, storage, or compute—it's the gap between data and decisions: who decides?, on what timeline?, with what authority?

ROOT reframes decision performance as a system problem with four integrated layers:

  • R (Real Decision System): The actual humans, meetings, and power flows that make decisions (often invisible in org charts)
  • O1 (Operating Model): The decision-making rhythm, ownership, and escalation paths
  • O2 (Outcome Intelligence): The feedback loops that measure if decisions worked
  • T (Trust): The credibility and transparency required for decision-makers to act on data

This paper provides a diagnostic framework, architectural patterns, and a 90-day implementation roadmap to close the data-decision gap.

The Problem: Dashboards vs. Decisions

In 2024–2026, the industry narrative around data organizations has been "build the dashboard." Vendor roadmaps promise: more visualizations, faster queries, more AI features. Yet field observations show a different pattern:

  • More dashboards, same decisions: New dashboards sit unused while teams continue to reference ad-hoc Excel files and email forwards.
  • Faster analytics, slower decisions: Teams can now generate a report in 30 minutes instead of 3 days—but decisions still take 2 weeks because stakeholders are not aligned on who decides.
  • Better data, worse accountability: With more sources and more interpretations, decisions become more diffuse: "the dashboard says this, but marketing says that, so we'll split the difference."

Root cause: Organizations confuse "data infrastructure" with "decision infrastructure." The former is solved. The latter is not.

ROOT Framework: Four Layers

Layer 1: R — Real Decision System

Before building any operating model, audit the actual decision system—not the org chart.

  • Who decides? Not "the VP of Strategy" in the org chart, but the human(s) who, in practice, have the final say. Often surprising (e.g., a product manager, an influential IC).
  • What do they decide on? Inventory levels? Pricing? Go/no-go to market? Hiring?
  • On what cadence? Weekly? Quarterly? Ad-hoc?
  • With what information? Today, in the absence of your dashboard: what data sources do they use? Email threads? Vendor reports? Gut?
  • What's the friction? Where do decisions bog down? Waiting for approval? Waiting for data? Disagreement on metric definition?

Diagnostic output: A "decision map" showing who, what, when, with-what-info for the top 10 decisions in your domain.

Layer 2: O1 — Operating Model

Once you know the real decision system, design the operating model: the formal decision-making rhythm that can scale.

Key components:

  • Decision Tier: Tier 1 (strategic, quarterly), Tier 2 (tactical, monthly), Tier 3 (operational, weekly)
  • Data Requirements: Per tier, what metrics are non-negotiable for decision-making?
  • Ownership: Who is DRI (directly responsible individual) for each decision tier?
  • Escalation Path: If consensus is not reached at a tier, who escalates to, and within what SLA?
  • Rhythm: E.g., "Tier 1 decisions every quarter by EOD Friday; Tier 2 decisions every Monday morning; Tier 3 standing weekly meeting."
  • Veto rights: Who can veto a decision? On what grounds? (Prevent decision theatre.)

Output: A "decision playbook" that can be handed to a new hire and followed immediately.

Layer 3: O2 — Outcome Intelligence

Decisions only improve if you measure outcomes. Yet outcome measurement is systematically underinvested.

For each decision tier, define:

  • Decision metric: What did we decide on? (E.g., "increase pricing on SKU X by 5%")
  • Outcome metric: How do we know if it worked? (E.g., "revenue per unit", "market share", "customer retention")
  • Evaluation window: When do we measure? (Depends on decision type: pricing may show impact in 2 weeks; hiring takes 6 months)
  • Feedback cadence: How often do we loop back and adjust? (Not "annually" or "never"; ideally continuous for fast-cycle decisions)
  • Counterfactual: If decision didn't happen, what would baseline be? (Hard; often requires A/B tests or analog markets)

Output: A "decision effectiveness dashboard" showing, for each past decision: did it land? Why/why not? What would we do differently?

Layer 4: T — Trust

No operating model survives without trust. Trust requires:

  • Transparency in data sourcing: "Where did this metric come from?" must be answerable in 10 seconds (not 1 week of investigation)
  • Consistency in definitions: "Revenue" must mean the same thing across contexts, or stakeholders will override the dashboard with their own definition
  • Accuracy: One data error that contradicts stakeholder intuition destroys credibility for months
  • Accountability: When data informs a decision that goes wrong, it's data's fault. Someone must own that. (Often this role is absent.)
  • Timeliness: Stale data is worse than no data. If decision-makers know the dashboard is 5 days out of date, they'll ignore it.

Output: A "trust scorecard" measuring each component above per decision domain.

Implementation: 90-Day Roadmap

Month 1: Audit + Map

  • Week 1-2: Interview 10-15 key stakeholders. Build decision map (real system).
  • Week 3-4: Identify top 3 "pain point" decisions. Model current-state friction.
  • Output: Decision map + 3 pain point canvases

Month 2: Design + Pilot

  • Week 5-6: Co-design operating model for the #1 pain point decision. Define decision playbook, metrics, ownership.
  • Week 7-8: Pilot with one business unit. Run 2 decision cycles using new playbook + dashboard.
  • Output: Pilot decision playbook + 2 decision cycles completed + retrospective

Month 3: Scale + Lock

  • Week 9-10: Roll out to broader org. Train on playbook. Deploy outcome intelligence layer.
  • Week 11-12: Lock operating model into calendar + systems. Measure trust scorecard.
  • Output: Operating model locked, outcome intelligence live, trust scorecard baseline

Evidence Tiers

This framework is grounded in three evidence tiers:

  • R / O1 (Peer-reviewed + industry practice): Drawn from Mintzberg (organizational design), Kahneman (decision science), Marquet (turn the ship around, accountability), and vetted in 8+ organizations (2020–2026).
  • O2 (Directional + case study): Outcome measurement at scale is still emerging. Our data on "decision effectiveness" comes from 4 organizations with structured feedback loops; generalizable patterns are directional pending larger sample.
  • T (Emerging + hypothesis): Trust quantification is underexplored. The trust scorecard is a proposed diagnostic; we're collecting real outcomes now.

Downloads & Further Reading