Who Should Own Data Governance?

Stefania has worked in Data Science for over a decade, starting at a genetics company as a data engineer. Here she managed distributed computations and correlation analysis of physical trade with DNA mutations and discoveries.

Her PhD trajectory took her to QuizzApp, which reached one million users in the first five days, which was record-breaking growth for the App Store at the time. While there, she had the opportunity to build the data science division, team, infrastructure, and culture. “I had to learn a lot about data reliability and quality, including who should own what,” says Stefania.

Stefania needed to build tools and processes to facilitate better accessibility of self-serve analytics and even self-serve governance.

A few years later, she used this experience start Avo, a company that fixes data quality for product analytics. Avo has helped well-known companies like Fender, IKEA, and Condé Nast, and others to build better data cultures.

In my experience, organizations typically transition through four stages of data quality and data governance:

1. Wing it
2. Wild West
3. Centralized Governance
4. Self-serve Governance

We often start by winging it in the early stage, where there is no data because the product is just starting and there’s no real tracking element.

We then move into the ‘wild west’ stage, where it’s every team (or platform) for themselves. At this stage, we have a lot of data and variants, but the data isn’t typically owned by any one team, it’s generally bad data.

The next stage we go into is centralized governance. We typically have a person or team that owns data governance as the advocate for data quality. Usually, at this stage, the advocate will uncover the lack of data standards and take action. But soon the centralized team becomes a bottleneck because it’s a lot of work for them to make sure everything is high quality.

This leads us to the next step, which is self-serve governance. We begin to see global standards become owned by domain experts.

Data governance is a cross-functional problem. We have three core role groups contributing to data quality and relevance:

1. Product developers
2. Developers and product engineers
3. Data professionals

The product developers and engineers understand what goals to set for a product. They know the relevant metrics to measure success and the steps to take to achieve goals.

Data professionals have insights into what data is available, what tools to use for metrics analysis, and what structure the data should be. They also know how new data can fit with existing data.

You have all these different stakeholders bringing these different things to the table, and they all need to be included. It should be a cultural aspect that all teams are involved in, but they typically have different problems they want to solve at different stages.

For the best outcomes, it’s best to solve problems cross-functionally at the source of when events and data are created. This will increase data readability downstream, data quality, and data reliability.

It’s possible to build quality data from the start, providing you have some experience of knowing what is and isn’t good in advance.

If someone handling data has seen where it has gone wrong before, they can use that knowledge as an opportunity to try it in a new way at the start.

You need to commit to a naming convention and create global standards, including for the concepts within your product. Processes are also important. They serve as a single source of truth for how teams should document schemas.

If you’re starting with a new product, your tracking plan will be different now from what it will be in three years. There’s so much product evolution needed before you can firmly know how you will measure your product. Use the early stages to determine the standards, and add some best practices, but accept that it’s something you’ll need to iterate on along the way.

Collaborating cross-functionally has a flywheel effect—better breeds better.

If the product, engineering, and data teams care about data, everyone is invested in shipping quality data. Teams can then make better decisions and improve user experience. It works as a cycle that reinforces itself and becomes contagious.

I recommend starting with a small team. Find those data-curious developers and product managers to work with ahead of your next minor feature release and do a meeting on the purpose of that feature and what metrics you’re looking to drive.

That meeting will determine what your tracking needs are to assess the success of the product feature. For this meeting to have as much value as possible, it should occur before product development starts so developers don’t need to refactor code to bake in tracking.

Making tracking a first-class citizen in your product development process and involving everyone has the benefit of creating a more positive culture towards data. This alleviates the feeling of data governance being a chore, and rallying everyone around the goal of shipping better products.

To move towards a self-serve governance model, you need to combine two approaches: forcing teams to behave how you need them to and inspiring them to, as well.

If you remember the flywheel approach above, I suggest using teams almost as case studies for how easy it can be to manage analytics if you do it cross-functionally and proactively instead of reactively.

You also need to consider how to enforce standards computationally. Perhaps you introduce a JSON schema and then train people to implement suggestions to your company's single source of truth. Consider what global governance can happen on a computational level and the standards to propose so you can inspire culture.

Eventually, you will have enough case study examples of success, allowing you to make a case to senior leadership or data leads for why these examples should be implemented company-wide.