Most data governance initiatives optimize for the wrong thing. They create documents nobody reads, committees that rubber-stamp decisions already made, and policies that exist solely to pass audits. Meanwhile, the actual problems—broken pipelines, mystery metrics, and decisions based on bad data—continue unchanged.
After watching governance efforts across multiple organizations, the pattern is clear: data problems are communication problems in disguise. Fix the communication, and governance follows. Build governance theater, and you get compliance checkboxes while your data remains a mess.
The theater we've all watched
You've seen this show. A consultancy arrives, interviews everyone, and produces a 200-page governance framework. Committees form. Someone gets named "Chief Data Officer" or "Data Governance Lead." There are RACI matrices. Stewardship roles assigned to people who've never written SQL. Quarterly reviews of data dictionaries that are outdated before the meeting ends.
Six months later, the same problems persist. Nobody knows what that critical metric actually measures. The finance team and product team calculate revenue differently. That pipeline still breaks every Tuesday. But hey, the audit passed.
This happens because traditional governance approaches the problem backwards. They start with frameworks and org charts instead of asking why data problems exist in the first place.
What's actually broken
Data doesn't spontaneously combust. It breaks for predictable reasons:
Nobody talks during design. The engineering team builds a feature, instruments it their way, and throws events into the pipeline. Analytics discovers it months later, tries to reverse-engineer intent from column names. By then, the original engineer has left.
Ownership means nothing. Sure, Sarah is the "steward" of the customer table. But Sarah's in marketing, doesn't know SQL, and has no ability to fix issues. When the pipeline breaks at 2am, nobody pages Sarah. The on-call engineer who's never seen this data before scrambles to fix it.
Feedback loops don't exist. That report you deprecated? Three teams downstream still depend on it. That field you renamed? Broke five dashboards. That "temporary" table from 2019? It's now load-bearing infrastructure.
Context evaporates. Why does this table exist? What assumptions does this metric make? Why do we calculate churn three different ways? The answers lived in someone's head, Slack threads, or that one Confluence page nobody can find.
What actually works
Successful data governance doesn't look like governance at all. It looks like good engineering practices and clear communication patterns.
Data contracts in code, not committees
Define schemas where engineers work—in pull requests, not PowerPoints. When someone changes a critical table structure, automated checks catch breaking changes. The PR becomes the forum for discussion. "This will break the marketing dashboard" becomes a blocking comment, not a discovered problem three weeks later.
# data_contracts/user_events.py
@contract
class UserEvent:
user_id: str # UUID from auth service
event_time: datetime # UTC only
event_type: Literal['click', 'view', 'purchase']
@validation
def reasonable_time(self):
# Events can't be from the future
return self.event_time <= datetime.now()This lives in your repo. Changes require review. Tests run automatically. No committee needed.
Ownership that matters
Real ownership means accountability for outcomes, not titles. The team that produces data owns its quality. The team that consumes data owns understanding it.
If the user attribution logic breaks, the growth team that built it fixes it—not some arbitrary "data team" that inherits everyone's problems. If finance needs revenue calculated a specific way, they own that transformation logic.
This seems obvious but watch how many organizations centralize all data problems into one overwhelmed team while the producers and consumers point fingers at each other.
Documentation where developers live
Wikis die. They're created with enthusiasm, updated twice, then become archaeological sites. But code comments stay close to the truth because they're right there when you're making changes.
-- models/revenue/mrr.sql
-- Monthly Recurring Revenue calculation
--
-- WARNING: This excludes paused subscriptions as of 2023-01-01
-- See RFC-123 for why we made this change
-- Finance uses this for board reporting - changes require their approval
--
-- Owner: revenue-team@company.com (pager: #revenue-oncall)
WITH active_subscriptions AS (
SELECT *
FROM subscriptions
WHERE status = 'active' -- Paused excluded per RFC-123
...
)Context stays with the code. Git blame shows you who made changes and why.
But you're not making analysts read SQL comments to understand metrics. Generate documentation from these comments—automated, always current, accessible to everyone. Tools like dbt do this well: developers write docs as code comments, the system generates a searchable catalog. One source of truth, multiple ways to access it.
Cost visibility as a proxy for caring
You're right that warehouse costs rarely break the bank. But resource waste indicates deeper problems.
That query taking 20 minutes? It's scanning the entire customer table because nobody added an index. Those 47 development datasets? Half belong to people who left last year. That scheduled job running every hour? It's been failing for six months but nobody noticed.
Cost attribution—tagging every query to a team and purpose—creates accountability. Not because the CFO cares about your $3,000 Snowflake bill, but because it forces teams to notice what they're doing.
-- Bad: Anonymous query hammering the warehouse
SELECT * FROM events WHERE date > '2020-01-01'
-- Good: Tagged, optimized, owned
-- @team: growth
-- @purpose: daily-dashboard
-- @priority: p2
SELECT /*+ USE_INDEX(events date_idx) */
user_id,
COUNT(*) as event_count
FROM events
WHERE date >= CURRENT_DATE - 30
GROUP BY user_idRegular "what broke and why" sessions
Most organizations treat data failures like shameful secrets. Instead, run monthly reviews of what went wrong. Not blame sessions—learning sessions.
"The executive dashboard showed zero revenue on Monday. Why?" leads to discovering that a timezone assumption in the pipeline wasn't documented. Everyone assumed UTC. The new engineer used local time. Simple fix, valuable lesson.
These sessions build shared mental models about how your data actually works, not how the governance document claims it works.
The lightweight framework
If you must have a framework (and honestly, sometimes you need one for compliance), keep it simple:
Design phase: Data producers and consumers talk before building. A Slack thread or brief doc outlining what data will exist and why. Not a multi-week approval process—a conversation.
Build phase: Schemas defined as code. Tests for data quality. Documentation in comments. Standard stuff that should happen anyway.
Run phase: Clear ownership (who gets paged). Monitoring that alerts before users complain. Cost tracking so you notice problems.
Evolution phase: Breaking changes require migration plans. Deprecation notices actually reach consumers. Regular review of what's not working.
This isn't revolutionary. It's applying basic engineering practices to data. Yet most organizations would rather build elaborate governance theater than have engineers talk to each other.
Why this matters now
AI makes this urgent. Every company is rushing to build ML models, RAG systems, and analytics products on their data. But models trained on ungoverned data encode all your organizational dysfunction. That customer churn model using three different churn definitions? It's learning nonsense. The RAG system pulling from outdated documentation? It's giving users wrong answers.
Bad governance used to mean wrong reports. Now it means models making bad decisions at scale, automatically, thousands of times per second.
The real test of governance
Here's how to evaluate whether your governance actually works:
- Can a new engineer understand your critical metrics within a week?
- When data breaks, do you know within hours, not days?
- Can teams ship new data without three committees blessing it?
- Do consumers know when upstream changes affect them?
If you're answering no, you don't have a governance problem. You have a communication problem. Fix that first, and governance follows.
Start simple, build momentum
You don't need a Chief Data Officer if nobody knows what your data means. You don't need stewardship roles if pipelines break daily. You don't need a framework if teams don't talk to each other.
Start with basics that create immediate value:
- Make people talk during design
- Put documentation where developers work
- Make ownership mean accountability
- Track costs to encourage attention to detail
Good data governance doesn't look like governance at all. It looks like engineering practices that make teams more effective. The less ceremony and the more automation, the better it works.
Your data problems aren't unique. They're the predictable result of teams not communicating, context not being preserved, and ownership meaning nothing. Fix those fundamentals, and you build a foundation for data that actually works—whether you call it governance or not.