Conway’s Law for Data Teams

Two Dashboards, One Truth

On Monday, Maya—head of a seven‑person data team—watched two dashboards disagree.

The executive dashboard showed $11.2M in MRR. Sales’ dashboard said $10.6M. Both pulled from “the warehouse.” Both refreshed nightly. Neither was “wrong”; they just measured different things.

Maya didn’t control how Sales Ops or Marketing were organized, who they reported to, or which tools they bought. She controlled only her data team—its models, interfaces, and operations. Yet the warehouse had clearly taken on the shape of the company’s communication patterns.

Conway’s Law, without asking permission, had moved in.

What Conway’s Law Really Says

Melvin Conway’s 1967 observation: organizations design systems that mirror their communication structure. If teams coordinate loosely, systems integrate loosely. If interfaces between people are ambiguous, system interfaces will be ambiguous too.

In data, this law bites harder than in most domains because metrics are social agreements wrapped in code. Even when you can’t change the wider organization, you still have to deliver trustworthy, cost‑aware data products inside it.

How Conway Shows Up in the Data Stack

Four “Customers,” All Slightly Different

Sales, Marketing, Finance, and Product each define “customer” with different keys, freshness, and attributes. Joining any two is work; joining all four is work and money.

Pipeline Per Team

Marketing builds its own ingestion from the event bus. Sales mirrors the same events “to move faster.” Finance runs separate CDC from billing with different SLAs. The same bytes traverse your cloud three times—and you pay three times.

Definition Drift

“Active user” is 21 days for Marketing, 28 for Sales, 30 for Product. All defensible, all incompatible. Disagreements become ingestion pipelines; code enshrines misalignment.

Hidden Costs

Storage multiplies as teams keep local bronze copies “for safety.” Egress spikes as extracts feed tool‑specific marts. You’re not paying for data once; you’re paying for every communication boundary around it.

You don’t need an org‑wide reorg to make this better. You need to design your data practice for the organization as it is.

Operating Within Your Span of Control

You can’t redraw the org chart. You can redraw your interfaces, defaults, and incentives.

1) Establish a Contracted Core You Own

Create a narrow, opinionated core layer—call it core or gold_contracts—where a handful of entities (Customer, Account, Subscription, Product) are:

• Versioned: schemas with explicit versions – breaking changes get deprecation windows).
• Documented: keys, nullability, SCD/CDC semantics, SLAs.
• Continuously tested: freshness, key uniqueness, row‑level expectations.
• Owned: clear on‑call, backlog, and incident process—within your team.

Upstream of the core: ingest and explore however you need. Downstream: teams can model their own marts. At the core: your rules.

Practical move: Publish an Executive Metric Pack (MRR, ARR, churn, active user) built strictly on the core. Make leadership reporting consume only that pack. Adoption follows reliability.

2) Add Anti‑Corruption Layers at the Edges

You can’t force upstreams to align; you can adapt them.

• Source‑specific adapters (CRM, billing, product events) translate external shapes into your canonical ones.
• Consumer‑driven contracts: store assertions about upstream payloads (types, allowed values, event counts/hour).
• Breaks fail fast in your pipelines and trigger graceful degradation (quarantine rows, fill from last good state, alert your team—not theirs).
• Treat identity stitching as a product (deterministic rules + probabilistic matching + explainability tables).

These layers absorb organizational asymmetry so the core stays clean.

3) Make the Recommended Workflow the Easiest Option

You can’t mandate behavior, but you can make the default irresistibly convenient:

• Templates for sources, models, and tests that target the core.
• Auto‑generated docs and lineage for core datasets.
• Simple publishing from the core to BI tools and feature stores.
• Starter kits (“Marketing Attribution,” “Booking Pipeline,” “Subscription Health”) that read from the core and show how to extend it.

Low friction beats policy.

4) Own a Metric Registry and Semantic Layer

You can’t stop local metrics, but you can provide a single definition of record:

• Metrics‑as‑code bound to core entities.
• Compilation to multiple runtimes (warehouse SQL, BI definitions, Python for batch), so one definition fans out everywhere.
• Versioning with deprecations and change logs.

Start with the high‑leverage few (MRR, active user, churn). Don’t outlaw local variants; name them and relate them to the standard.

5) Implement Cost Controls You Can Enforce

You may not own other teams’ budgets, but you do control platform knobs:

• Resource limits on heavy transforms -> schedule noisy jobs off‑peak.
• Materialization and result reuse in the core so downstreams don’t re‑compute shared logic.
• Duplicate detection when two DAGs run the same SQL on the same inputs.
• Make extracts opt‑in with visibility (who, what, when, how much data).

Tag costs by data product (e.g., “Customer Core”) rather than by tool. Trim the worst offenders first.

6) Create Social Interfaces Without Reorgs

You can’t change reporting lines, but you can standardize collaboration:

• Office hours and SLAs: “If you map to the core, we review in 48h and backfill within 72h.”
• Two‑page design doc template for proposing core changes; your team answers asynchronously with a plan.
• Release notes: monthly “What changed in Core?” beats a thousand DMs.
• Rotating liaisons: one data engineer shadows a partner team for two weeks per quarter—information flow without moving boxes on the org chart.

7) Contain Incident Scope

When (not if) an upstream changes:

• Contract checks fail early; bad rows don’t leak into the core.
• Feature flags in transforms let you roll forward/back quickly.
• Scripted backfills replace bespoke heroics.
• Runbooks live with code so any team member can triage.

8) Scale Your Data Team Deliberately

Resist Conway’s pull by clarifying internal ownership:

• Split your backlog into a small platform slice (ingestion, core models, CI, cost controls) and data products (domain‑facing models built on the core). Same leader; distinct responsibilities.
• Assign clear owners for each core entity (Customer, Subscription).
• Enforce quality gates in CI: no merges that violate contracts, no matter how urgent the request.

What Changes (Without Changing the Org)

Back to Maya. She didn’t restructure Sales or centralize Marketing. She did three moves inside her remit:

• Shipped a Core Customer: versioned schema, identity stitching, daily SLA.
• Moved the executive dashboard to the metric registry tied to the core.
• Offered a default toolkit (templates, reviews in 48h, docs, lineage) for teams that wanted first‑class marts.

Within a quarter:

• Executive MRR and Sales’ MRR converged.
• Sales kept its local cut for pipeline management; leadership used the registry’s MRR.
• Duplicative ingestion jobs were retired because the core delivered the same data, faster, with support.
• Costs stabilized; heavy logic was computed once in the core instead of many times downstream.

The org chart didn’t move an inch. The interfaces did.

Signs You’re Losing to Conway (and What to Do)

Sign: The same raw table lands in three schemas.

Move: Publish a certified core version; deprecate private copies with a 30‑day migration path.

Sign: Metric debates last longer than a sprint with no code changes.

Move: Add or revise a registry entry; require PRs to the registry for any “official” report.

Sign: A small upstream tweak breaks three DAGs.

Move: Formalize contract checks; quarantine deltas until adapters catch up.

Sign: No named owner for “Customer.”

Move: Assign one inside your team. Ownership collapses ambiguity.

Smell: Cost reports are by tool, not by data product.

Move: Tag compute/storage by core entities and reports; prune where it hurts most.

“We Can’t…”—You Still Can

• “We can’t force Sales to use our tables.” Don’t. Make the core the easiest reliable option; point executive reporting at it.
• “Marketing won’t change their definition.” Fine. Publish the standard and map theirs to it in the registry (“Marketing Active User”). Differences become explicit, not accidental.
• “Upstreams change without notice.” Assume they will. Contracts, adapters, quarantine, and scripted backfills are your insurance.

Epilogue: The Dashboard We Didn’t Police

A PM in Growth shipped a dashboard pulling core.customer and the registry’s “Activation Rate v3.” Nobody asked for approval. Finance commented on the PR to note an upcoming change to proration; the metric bumped to “v4,” and dashboards updated automatically.

Conway’s Law still describes the organization outside your reach. Inside your reach, contracts, adapters, and defaults describe your platform. You don’t need authority over the org chart to build an efficient, cost‑effective data architecture or to scale a data team that doesn’t fracture. You need to design for the org you actually have—and make the right way the easiest way.