Two teams sitting in different Slack channels build two pipelines that compute the same metric.
Conway’s Law: systems mirror the communication structure of the org that builds them. It was written about software in 1968. It applies to data pipelines exactly the same way.
I see this every quarter at scaleups. Marketing has its own data analyst who built a customer_attribution table in Looker. Product has its own analyst who built a user_attribution model in dbt. Finance has a spreadsheet that calls the same thing customer_acquisition. Three “single sources of truth,” three different numbers, three teams who don’t talk daily.
The pipelines are the symptom.
The org chart created three teams with separate goals, separate reporting lines, and separate Slack channels. Each team built the thing it needed to ship its own work. That’s rational behavior. The duplication is just the architectural shadow of the communication boundary.
Fix the pipelines without fixing the boundary and the duplication comes back in 6 months under different names.
What works:
- A shared metrics review every 2 weeks where all three teams present and reconcile definitions
- One named owner per shared metric (not per pipeline)
- A weekly 30-minute working session where the three analysts pair on each other’s work
- Architecture Decision Records visible to all three teams when a new metric ships
These thin the communication boundary just enough that the pipelines stop drifting.
The data architecture follows from the conversations the org actually has. Change the conversations, the architecture changes with them.
How many times is “active user” defined in your warehouse right now?