This article is part of the series “Data Leadership That Delivers: Pragmatic Lessons from the Front Line,” where I share lessons learned from leading data and analytics at high-growth companies like eBay, Marktplaats, and Adevinta.

TL;DR: Effective data governance isn’t about control; it’s about enabling faster, more trusted decision-making. Discover practical strategies to implement governance frameworks that empower teams rather than restrict them.

Most badly designed data governance efforts fail because they’re built like security checkpoints designed to catch problems rather than prevent them. After leading data teams through multiple governance transformations, I’ve learned that the best governance is built with an offensive mindset, fanatically focused on delivering value instead of defensively trying to reduce ambiguity or focus solely on compliance.

The shift is from governance as gatekeeping to governance as an enabling platform. Why I love working on governance topics is because if you design these well you do it together with end users and can be pivotal in solving for their problems. The goal is to democratize data and data access while maintaining quality and trust. When central teams dictate governance that only benefits them while decentralized teams do the work, it inevitably fails.

People working on governance must understand the business thoroughly. Goals shouldn’t focus on technical numbers like pipeline failures, but on value-added metrics tied to strategic priorities. If customer retention is a strategic priority, then data products on churn prevention need to grow in usage while retention numbers improve.

When Governance Goes Wrong

Early in my career at eBay, we learned the value of simple, well-designed governance the hard way. One case to illustrate was when Marketing teams were using tracking parameters for attribution, but without consistency. Each team used their own naming conventions, making cross-team data aggregation impossible.

The solution wasn’t implementing complex policies, it was a simple documentation page explaining where you could and couldn’t use these parameters, and which naming conventions to follow. Data quality improved, results became interoperable between teams, and teams policed themselves because deviating from the agreed structure would impact other teams.

This worked well when we weren’t that big and use cases were limited. However, when data use cases increase, the sophistication of your data management needs to increase accordingly. And that’s exactly when we hit problems.

As we started scaling our data governance efforts, we fell into several classic traps. These failure patterns emerged in our own organization as first-world problems of growth:

The Approval Bottleneck: We initially tried aligning with individual teams to get approval for every new tracking change or dataset, but it became a massive undertaking. The people who actually needed to use the data weren’t actively involved in the process, and development slowed down while teams waited for governance owners to process their request and approve .

The Documentation Trap: I remember working with a major consulting firm on our financial data transformation. The amount of documentation they created was staggering, such cognitive load that we needed meeting after meeting just to understand what was needed. Nobody read the massive policy documents, yet we kept producing more.

The Blame Game: We experienced this firsthand when central and decentralized teams started pointing fingers at each other when numbers didn’t align. Governance teams would point to policy violations while business teams pointed to governance obstacles. This was a clear case of not being aligned on ownership.

The Shadow System Response: This happened to us when the speed of delivery and granularity of what we as central teams provided wasn’t what individual teams needed. Teams built workarounds, creating the exact fragmentation and risk that governance was meant to prevent.

These patterns are predictable because they’re the natural result of scaling governance without evolving the approach. The good news? We overcame each of these challenges by fundamentally shifting our mindset.

Applying Product Thinking to Data Management

The shift came when we applied more product thinking to designing our data catalog, policies, and federated groups. Instead of asking “How do we control data usage?” we asked “How do we make it easier to use data correctly than incorrectly?”

This changes everything:

• From policies to platforms: Instead of writing rules about data quality, we invested in building quality checks into data pipelines.
• From committees to automation: Rather than manual approval processes, we invested in more automation with clear escalation paths.
• From documentation to discovery: Instead of static policy documents, we invested in dynamic data catalogs showing quality, lineage, and usage patterns in real-time.

Much of what I describe aligns with the data mesh framework, which I consider the most influential data management approach in my career. Data mesh emphasizes decentralized data architecture and operating models that treat data as a product. However, as mentioned in my previous article, data mesh isn’t for every team and company. The key is finding the right balance for your organization’s scale and needs.

The Three Pillars of Enabling Governance

Pillar 1: Transparent Data Quality and Context

Your teams need to see the quality and context of their data in the flow of work. Transparency isn’t just about documentation; it’s about making data quality visible where people actually use the data. This helps surface where the biggest issues are and help foster a good conversation on priotization.

At eBay, we added quality indicators in our dashboards so people would know the state of their data. We also annotated when things broke or tracking changes happened. A dashboard showing conversion rates would also display data freshness, coverage, and any known quality issues.

This transparency significantly reduced “Is this data right?” questions because users could see the quality context themselves.

Pillar 2: Self-Service with Smart Defaults

The fastest way to governance compliance is to make it the path of least resistance. When teams can work autonomously to solve their own data problems quickly and correctly, they stop building workarounds that bypass governance entirely.

The key is giving teams both foundation and freedom. At Marktplaats, we established golden records as reliable starting points for company-wide business planning data. But crucially, teams could then build their own more granular datasets aligned with their specific operational needs. We had policies in place, but we deliberately leaned back to let teams move at speed and gave them access. Trusted them to do the right things, but evaluated this frequently to ensure they did.

When teams can act autonomously within smart guardrails that match their real needs, they naturally align with governance principles because it serves their interests. The alternative, waiting for central teams or working with poor-quality data, becomes obviously inferior.

One part I’m not touching on in this article, but for sure will be a follow up is the levels of scrutiny that is needed for every datapoint. If you run a quick experiment the needs are different than if you do continuous fraud prevention. Designing for that is a very quick win.

Pillar 3: Embedded Ownership and Accountability

Governance can’t be something that happens to your data, it has to be something all teams using data actively participate in. While governance teams should remain central to provide platform and policies, the actual ownership of data quality needs to be distributed to domain experts who understand their data best.

Looking at data as a product requires teams to be accountable for the quality and usage of what they create. If no teams are using your data product despite clear potential value, that’s a signal something isn’t working.

At Adevinta, we established Data Product Governance Council that had contributions from each business unit. These were groups of data product owners who met regularly to share challenges, align on standards, and coordinate changes affecting multiple teams. These councils should be led by someone who can bring groups together effectively and make participation engaging and fun rather than bureaucratic. When governance feels like just another meeting, it fails.

Making Governance Stick: The Implementation Playbook

Be Clear on Quality Levels: Begin by identifying where trust is broken. Which datasets do people question? Focus governance efforts on these trust gaps first. Start with three critical data products and make them exemplars rather than mandating comprehensive policies from the top down.

Build Governance into the Platform: Governance that exists separately from daily tools will be ignored. Embed governance decisions into your data platform architecture, quality checks that run automatically, access controls based on data classification, lineage tracking built into pipeline tools. A unified data catalog has always been the foundation of our data growth.

Create Feedback Loops: Good governance requires continuous improvement. Use surveys about trust and ease of use, usage analytics showing which governance features are actually used, and quality trend tracking.

Invest in Data Literacy: Governance without data literacy is just bureaucracy. Teams need to understand not just what the rules are, but why they matter. Many governance frameworks are very technical, but it’s more important to take people along on the journey. Simplifying is key.

Read more …