Data Governance Without a Governance Team: What Can Data Engineers Do?

Data Governance Without a Governance Team: What Can Data Engineers Do?

Five Questions with Charlotte Ledoux, Data and AI Governance Consultant

Pipeline to Insights and Charlotte Ledoux

Nov 3

Data governance plays an important role in helping organisations get value from their data and AI initiatives. With the rise of AI, the need for clean, trustworthy and well-structured data has become even more noticeable. From improving data quality and building trust in business reporting to enabling reliable AI solutions, managing risks and meeting regulatory and compliance requirements, good governance can address challenges across an organisation.

Yet, putting governance into practice is not always straightforward. Organisations can struggle to demonstrate their return on investment, maintain momentum after an initial initiative ends, or keep it on the agenda as other business priorities take over. Sometimes, even initiatives that deliver value gradually lose visibility and become difficult to sustain.

Data governance can occasionally remain in the background until something goes wrong. A data quality issue affects a business decision, a compliance requirement is missed, a reporting discrepancy creates confusion or an AI initiative exposes problems with the underlying data. Suddenly, governance becomes a priority. Many issues that appear to be technical, operational or business problems can have their roots in data governance. The challenge is making sure organisations don’t wait for these situations before taking it seriously.

This presents an important question: does every organisation need a dedicated Data Governance team to make progress?

I believe there is an opportunity for data engineers and other people working closely with data to play a meaningful role. They understand how data enters an organisation, how it moves through systems, how it is transformed, and how different business teams use it. This puts them in a good position to identify governance challenges and help translate governance principles into functional processes, controls and solutions.

Good governance also needs to evolve alongside the organisation. As new systems, data products and AI capabilities are introduced, governance should become part of everyday data operations rather than remain a separate initiative or documentation exercise. This can help organisations build trust in their data while creating the right foundations for innovation.

I recently came across Charlotte Ledoux’s LinkedIn and Substack post on Data Governance as Code, which explored this connection between data engineering and governance. It encouraged me to explore the topic further, particularly how data engineers can contribute to governance initiatives and make them part of the way data platforms are designed and operated.

I’m pleased to welcome Charlotte Ledoux , Data and AI Governance consultant and author of The Data Governance Playbook, to discuss where data engineers should start, the challenges they might encounter, and how organisations can turn governance principles into applicable, sustainable outcomes.

About Charlotte

She is a freelance Data and AI Governance consultant, a LinkedIn Top Voice with 50,000+ followers, and the author of The Data Governance Playbook, a newsletter with 8,500+ subscribers covering data governance through practical frameworks and field experience. She’s been independent since 2023 and has around 10 years of consulting experience, including time at BearingPoint and Quantmetry. She also runs maketools.ai, a company providing fun and engaging AI literacy content.

Subscribe to Data Governance Playbook

Here are five questions covering the practical side of data governance, from getting started to measuring whether our efforts are making a real difference

I hope you enjoy this interview as well 😊.

Where Should Data Engineers Start with Governance

1. Your writing makes the point that governance needs to be built into the code to be effective, and that data engineers often take on this responsibility when there’s no dedicated data governance engineer. For a data engineer who’s new to this idea, where would you recommend they start?

I’d start before the code. If you write governance checks without knowing why they exist, you end up with a pipeline full of tests that nobody owns. So the first step is to understand what data governance is for in your company.

Data governance exists so that people can trust and use data without asking around every time.

Who decides what “active customer” means? Who says yes when someone wants to use a dataset for a new purpose? Who gets called when a number looks wrong? When nobody can answer those questions, you get 3 dashboards with 3 different revenue figures, and a lot of meetings to work out which one is right.

The best way to understand this is to talk to people. Find out if your company has a data governance strategy, a CDO, data owners or data stewards, even if nobody uses those titles. Ask them what problem they’re trying to solve. Sometimes it’s regulation (GDPR, the AI Act, sector rules). Sometimes it’s an AI project that failed because the data couldn’t be trusted. Sometimes it’s just that the business has stopped believing the reports. The answer tells you which rules matter and which ones are paperwork.

Then look at it from the business side. Take a dataset you build and go see the people who use it. Ask what they do with it, what decisions it feeds, and what happens when it’s late or wrong. Most data engineers never have this conversation, and it changes how you see your own pipelines.

Overall, you need to understand that most of data governance is change management: getting people to agree on definitions, take ownership, and change how they work. The code is the part that makes those agreements stick.

2. For a data engineer with zero governance background who’s just been told some of this is now their job, where should they start?

First, learn the vocabulary, because it’ll save you a lot of confused meetings. The data owner is the business person who’s accountable for a dataset and decides what’s correct. The data steward handles the definitions and quality day to day. The data custodian runs the technical side. As a data engineer, you’re usually the custodian. That matters, because it means you’re not supposed to decide what “active customer” means. Your job is to make sure that whatever the owner decides is applied every time.

After that, go and see the people who use your data. Pick one dataset, find who relies on it, and ask what they do with it and what happens when it’s wrong. You’ll learn more about governance in that conversation than from a framework document.

When the Code Enforces the Wrong Rule

3. You’ve said code makes governance rules real, but doesn’t make them right. Can you give an example of a rule that was perfectly enforced in code but was still the wrong rule?

You add a quality rule to your payment pipeline: every transaction amount must be greater than zero. That sounds reasonable. A negative payment looks like a bug. The check goes into CI, and any row that fails is quarantined so it doesn’t reach the reporting tables. It works perfectly. The check runs every night, the dashboard stays green!

But refunds are recorded as negative amounts. So every refund is quietly filtered out. Revenue in the finance dashboard is a bit too high every month, and the refund rate looks better than it really is. Nobody notices for a quarter, because the governance tooling shows a pipeline with 100% of checks passing.

The code did what it was told. The rule was wrong, because the engineer who wrote it guessed what a “valid amount” was instead of asking the person who owns the payments data.

The Smallest Real Step You Can Ship

4. If a data engineer at a company with no formal governance function wanted to operationalise just one governance rule in code this quarter, what’s the smallest real version of that they could ship?

Every table in production has a named owner, and the build fails when one doesn’t. It isn’t a quality rule, and that’s on purpose. Without a governance team, the thing you’re most likely missing is someone to call when the data is wrong. Quality checks with no owner just produce alerts that nobody reads.

The smallest version you can ship: add an owner to your models. In dbt that’s two lines in the YAML.

The owner should be someone on the business side who decides what the data means. Not the engineer who built the pipeline.

How Do You Know Governance Is Working?

5. How do we know governance-as-code is really working, versus just producing compliance theatre?

You need KPIs, and they have to measure coverage of what other people actually use, not the whole warehouse.

The 3 I’d track:

• % of exposed models with an owner. By exposed, I mean anything outside your team reads: data products, tables behind dashboards, anything shared across domains. Staging tables don’t count.

• % of contracted interfaces with a data contract. When one team consumes another team’s output, is the schema, the owner, and the quality rules written down and checked at every merge? Or does it still run on “we’ll ping them if it breaks”?

• % of data products with SLOs. Freshness, completeness, availability — is there a promise someone can check, and is it measured?

They’re easy to compute from your repo and your manifest, so you can publish them every month without asking anyone for anything. And they show where you stand on the things that matter.

Coverage alone can still be theatre, though. An owner field filled in with a team alias counts towards your 100%. A contract nobody reads is still a contract. So add a check on behaviour next to each KPI. Do owners reply when a check fails on their table? Do SLO breaches get fixed, or does someone quietly change the threshold? Are the rules updated now and then, or untouched since the day they were written?

And the 5-minute test still works.

Pick 3 owners from your YAML at random and ask them what they own. If they don’t know, your coverage number is just a number.

Conclusion

For data engineers, contributing to governance starts with observation. From day one, pay attention to how data is collected, managed and used across the organisation. Identify gaps, inconsistencies and opportunities for improvement. More importantly, learn to communicate these challenges in business terms, understand their impact on stakeholders and work with the right people to address them. When you see something that needs attention, take the initiative, offer support and help move things forward rather than waiting for someone else to take ownership.

Eventually, data governance is not limited to a dedicated team or a formal job title. Data engineers are well-positioned to contribute because they understand the technical foundations of data and how it flows through the organisation. By combining technical knowledge with business understanding, communication and a willingness to take ownership, they can help make governance part of everyday work and build a stronger foundation for trusted data and AI.

We value your feedback

If you have any feedback, suggestions, or additional topics you’d like us to cover, please share them. We’d love to hear from you!

Pipeline To Insights is where I share lessons, tutorials, and experiences in data engineering and AI to help you learn and grow.🙂

Your support helps me continue creating content like this, thank you 💐🙏

© 2026 Erfan Hesami
548 Market Street PMB 72296, San Francisco, CA 94104