Almost every data org over $100M in revenue has produced a data strategy in the last three years. Most have produced a roadmap to go with it. A meaningful fraction of those orgs are nonetheless stuck — strategy reviewed quarterly, roadmap updated monthly, and yet the business still cannot get its questions answered, and the CFO still cannot reconcile two reports that purport to measure the same thing.

The gap is not a strategy gap and not a roadmap gap. It is the absence of a third document that almost no one writes: the operating contract.

The strategy answers “where are we going and why.” It is a 5–15 page document. It names the business outcomes data is supposed to enable, the bets the org is making (centralized vs federated, build vs buy, breadth vs depth), and the principles that will be used to resolve trade-offs. A good data strategy is short, opinionated, and explicitly says what the org will not do. It is reviewed annually. It is signed by the executive who owns it. It is not a deck.

The roadmap answers “what are we building, in what order, by when.” It is a rolling 6–18 month plan, broken into quarters, with named owners and explicit dependencies. It is updated continuously and reviewed monthly. A good roadmap distinguishes commitments from aspirations and labels each item with the strategic bet it serves. The roadmap is not the strategy. A roadmap without a strategy is a list of projects ranked by whoever yelled loudest.

Most data orgs have both. Both are usually well-written. Both are usually wrong about how the work actually happens, because neither captures the interface between the data org and the rest of the business. That is the operating contract.

The operating contract answers “how do we work together, who owns what, and what do you get and not get.” It is the document that, if it existed and was signed, would prevent 80% of the cross-functional friction that makes data orgs miserable to work in and frustrating to work with. It covers, at minimum:

  • Intake. How requests enter the data org. What information is required. What the response SLA is for triage. What categories of work are accepted versus declined. The decline criteria are published.
  • Prioritization. Who decides what gets worked on. How conflicts between business units are resolved. The cadence at which priorities are revisited. The escalation path when a stakeholder disagrees with a deprioritization.
  • Capacity. How much of the data org’s time is allocated to roadmap work, ad-hoc requests, on-call, and platform investment. The split is explicit, defended, and reviewed. Without this, ad-hoc consumes everything and the roadmap is a fiction.
  • Quality bar. What it means for an analysis to be ready to share with executives. Peer review requirements. Reproducibility requirements. The standards are higher than the business naturally pushes for and the data org defends them.
  • Decommissioning. How dashboards, reports, and pipelines are retired. The default lifecycle. The criteria for extension. Without this, the org accumulates artifacts forever.
  • Boundaries with self-serve. Which questions the business answers itself, which require central involvement, and how the boundary is enforced. (Covered in detail in the previous post — the operating contract is where the boundary becomes binding.)

The operating contract is what turns a strategy and a roadmap into an organization that actually functions. Without it, the strategy is aspiration and the roadmap is a queue, and the work that consumes most of the data team’s hours — intake, ad-hoc requests, ambiguous prioritization, dashboard sprawl — happens in an undocumented operational dark matter that no one is responsible for improving.

The reason most orgs do not have an operating contract is that writing one forces unpopular decisions. It forces the data org to decline categories of work, which makes someone unhappy. It forces executives to commit to a prioritization process they cannot end-run, which makes them unhappy. It forces a published capacity allocation that makes everyone aware of how much “ad-hoc” they have been demanding. The strategy and roadmap can both be written without making anyone uncomfortable. The operating contract cannot.

That is exactly why it is the document that matters. The discomfort it produces in the writing is the same discomfort the absence of it produces in the operating, except concentrated into a few weeks instead of distributed across years of low-grade dysfunction.

Three documents. Strategy says where. Roadmap says how-and-when. Operating contract says how-we-work. The first two are common. The third is rare. The orgs that have all three are recognizable from across the room: their data team is calm, their executives are getting answers, and their roadmap actually ships.