What I Learned about Data Governance and Why It Fails

As a solutions engineer lead, my work often involves translating problems described by humans into technical solutions.

Read my article on my day to day life as a solutions engineer lead if you are curious :)

On most days, this means having to sit down and talk to stakeholders, engineering teams and merchants. They would all describe the same problem in different perspectives, goals and priorities. My job is to align them all into a tangible solution, so everyone is happy (or at least satisfied).

Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m curious about. In this article, I want to share about data governance, how it is often framed as a technical/compliance project when in reality, the biggest obstacles are human-made.

Clarifying Data Governance

In a talk I gave last year, I gave a super layman definition for data governance:

The ability to trust & use raw data, make sense of it, document it across functional teams

As you can see in this definition, “trust” is a keyword people often overlooked. When talking to people at data conferences, they described data governance as creating a system for efficient data management. This involves getting the right data to the right people and setting up a catalog to organize the data clearly and without confusion.

Below is what most of us would think what data governance is all about: simply building robust systems and policies. Image credit

This is not wrong, in fact, I would have agreed with this definition in the past. Because I believed that a lot of companies implement data governance from a top-down approach by designing the right systems, implement the most sophisticated tools and have clear policies supporting it.

However, there was a project that humbled me and made me realized that many companies implement data governance from a top-down approach not because it works best, but because it feels safest.

An Example

There was a project that felt so smooth. Everything was aligned, the timeline was within everyone’s expectations and everything seems good to go. We had many solution design meetings with stakeholders prior to the project’s implementation. They were engaged, responsive and overall feedback was positive.

We even had training workshops where we showed teams how to use the dashboards and how decisions could now be made with more confidence, and where the data flows from end to end. Everyone was nodding. When asked if they had any questions, all of them said it was clear so they had none.

Then, we went live.

Pipelines were running as expected, no failures or alerts. However, I was shocked to see the dashboard showing zero to minimal activity. I was confused because the client said everything was working fine. So, what is the issue?

They couldn’t tell me. They were not very technical people so in their eyes, they had nothing to do with it. They said this “technical problem” wasn’t their fault and they asked us to check our data pipelines and our systems. Still, nothing came up.

I ended making an urgent trip to visit them on-site and what I found had little to do with our implementation. Teams were still updating their own spreadsheets, and many department heads were still asking admins to manually create reports in Excel. A lot of them were hesitant to enter data into the system.

When I asked why, there were a lot of:

“My manager told me it’s safer this way.

“We are unsure if our data will be safely stored and visible across teams.”

“We had some misunderstandings in the past.”

It was clear that there had been past cases where data was taken out of context and used to question teams publicly.There was a culture where no one wanted to publicly own the data because it could be used against them.

People did not distrust our system, they distrust how the data in the system might be used.

I spoke to managers who wanted transparency but feared being judged by management. I spoke to individual contributors who do not want to be held accountable. I spoke to upper management who wanted this to work and believed a “better system” would solve this problem.

And that day, I learned that technology was not the bottleneck. The problem was trust.

Why Data Governance Projects Fail

Good intentions don't always lead to good results. If we treat data governance as just a digital transformation project and ignore the necessary cultural and mindset changes, it's more likely to fail, as noted in an article by Prosci.

The most common life cycle I’ve seen in data governance projects is like this:
1. Governance launches as a compliance initiative
2. Teams experience it as added overhead
3. Data Steward roles exist in name but lack support and authority
4. Adoption drops, workarounds appear
5. Governance is declared a failure and rebooted the following year

Engineers resist governance when it feels imposed, when it slows them down, and when it ignores the reality of how work actually happens. Not because they are anti governance, but because governance often arrives without safety.

This project forced me to confront a hard truth as a solutions engineer lead.

Overcoming Data Governance Challenges

I could not fix this by adding more rules or tighter controls. If anything, that would have made things worse. The challenge was not technical compliance, but human alignment.

The first thing I had to do was slow down and listen. Before enforcing ownership, I needed to understand how teams experienced accountability. I had already written about this in my article What Engineering Leaders Get Wrong About “Ownership”, but this project made the lesson even more clear: Ownership only works when people feel safe enough to step forward. Without such culture, labels mean little.

So I got to work and opened Google Docs to start documenting everything I heard from the users themselves. Here are my findings of common responses I heard and how I addressed these:

Within months of constant monitoring and cultural reinforcement, the change in users' behavior becomes clear. Slowly, I see users themselves began to write their own documentation for their datasets. Engineers who were avoiding conversations were now asking thoughtful questions on metadata standards.

Conclusion

This experience taught me that the funny thing about governance is that the moment people said it feels like governance, it means it’s failing. Because effective data governance to me is a subtle and long term impact. A new hire would come in, and they shouldn’t be questioning the processes, the culture and the quality. It shouldn’t feel forced, controlling but instead, natural yet efficient and continuously evolving.

By acknowledging that data governance is a human problem disguised as a technical one, we focused on the missing piece of the puzzle: building trust.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG