The DecisionOps Guide
The Growth Engine
Price Signals
AcademyDecisionOps Guide1. The Reality
Chapter 1
The Reality of Decision-Making
How business questions actually emerge, stakeholder drift, and why artifacts become surrogates for real decisions.
⏱ ~10 min readFree Chapter
1.1 How Business Questions Actually Emerge
In the idealized world of data engineering, a “Requirement” is a crisp, static document. In reality, questions are messy, organic, and evolving.
The Hallway Conversation
💬 Most questions start as vague anxiety
“I feel like we're losing momentum in the mid-market.”“Why are our Azure bills so high this month?”
This anxiety triggers a “Drive-by Request”: “Can you pull the last 6 months of sales data?”
⚠️ The Trap
The requester thinks they need “sales data”, but what they really need is to validate their anxiety about “momentum”. If the analyst simply pulls the data (Task Execution), the data will likely be irrelevant to the actual underlying question.The Iterative Loop
The question is not a static input. It is an evolving object. As soon as the analyst provides the first chart, the stakeholder says: “Oh, I meant recurring revenue, not one-time sales.”
This back-and-forth is not “scope creep”. It is learning. The question is being refined. The analyst's job is to make that refinement explicit rather than absorb it silently into successive SQL revisions.
1.2 Stakeholders, Incentives, and Interpretive Drift
Data is objective. Humans are not. Every stakeholder brings incentives and context that shape how they phrase a question and interpret an answer.
Interpretive Drift
Interpretive Drift is the distance between the Stakeholder's Intent and the Analyst's Query.
📊 Example: “Are customers happy?”
But the stakeholder might have meant “Are they renewing?”, not “Do they fill out surveys?”. The drift has rendered the data technically accurate but decision-incompatible.
Incentive Bias
A Sales VP wants the data to show growth. A Risk Officer wants to show exposure. When these two stakeholders look at the same dashboard, they draw opposite conclusions. Neither is wrong about the data. They are applying different unstated frames to it.
When interpretations are never written down, there is no way to tell whether two people disagreeing about an answer are working from the same question.
1.3 The Analyst as Translator, Not Executor
The dominant anti-pattern in analytics is the Service Desk Model. A stakeholder files a ticket (“Need Q3 sales by region”). An analyst picks it up, writes SQL, ships a CSV, and closes the ticket.
This reduces the Analyst to a Query Executor. It wastes their highest-value skill: translation between business intent and data logic.
Executor vs. Translator
💬 The same request, two approaches
This dialogue is the work. The code comes later. When it does not happen, the analyst spends days building the right answer to the wrong question.
1.4 SMEs, DE, and the Cost of Late Involvement
The Subject Matter Expert (SME) knows the business. The Data Engineer (DE) knows the pipeline. Typically, they are only involved at the very end (Validation) or the very middle (ETL).
😱 The 'It Looks Wrong' Moment
An analysis takes 3 weeks. You present it to the SME. They look at the first slide and say: “That number is impossible. We didn't operate in Japan in 2022.”The analysis is dead. Three weeks wasted. The SME's constraint was injected too late.
Shift Left: Constraint Injection
SMEs should be involved when definitions, constraints, and domain assumptions are being formed, before data is queried. Data Engineers should be involved when evidence strategy requires scalable, performant, or reusable data assets, before requirements are socially fixed.
Late involvement creates predictable failure modes. SMEs are asked to “confirm” logic that is already embedded. DEs inherit ambiguous requirements and build assets that do not precisely match the intended question. Both create rework loops that could have been avoided at the framing stage.
1.5 Why Artifacts Become Surrogates for Decisions
In most organizations, the “Deliverable” is a dashboard or a slide deck. We confuse the Artifact (the PDF) with the Decision (the choice to act).
The Surrogate Problem
When the Artifact is the goal, we optimize for production value, not truth. We polish the charts, align the pixels, cache the data. But an Artifact is static. It represents the world at the moment of generation. As soon as it is emailed, it begins to rot.
The artifact circulates, but the reasoning disappears. Later, the artifact becomes “truth” without context. Teams debate the chart, not the assumptions that produced it.
Artifacts lack the assumptions that shaped the output, the interpretations that were rejected, the validation that was or was not performed, and the confidence level of the evidence. So meetings devolve into re-litigating metric definitions and timeframes, because the artifact is the only visible object everyone can point to.
1.6 The Spreadsheet as a Symptom, Not a Solution
IT departments hate Excel. “Shadow IT,” they call it. “Ungoverned.” But business users love it. Why?
The Ultimate Flexibility
📊 Why users export to Excel
Users dump data into Excel because the official dashboard did not quite answer their specific question. The dashboard gave them “Revenue by Region”. They needed “Revenue by Region excluding last Tuesday for Project Alpha”.The Spreadsheet is a Symptom of a rigid data stack. It is the user saying: “I need to apply my own context.”
Don't Kill the Spreadsheet, Fix the Workflow
The goal is not to ban Excel. It is to stop Excel from becoming the system of record for decision logic. When context, assumptions, and filters live only in a spreadsheet, they are invisible to anyone who was not there when the file was built.
These patterns compound. Each unanswered or incompletely answered question adds to Question Debt: a growing backlog of decisions whose reasoning was never captured. When those questions return, the same investigation runs again from scratch, often with different definitions and a different conclusion.
