One of the biggest pain points I’ve experienced in my career as a data leader is the lack of ownership of data-related work by non-data people.
One symptom for this is, for example, having to integrate some kind of discount logic in the data warehouse after a new discount structure has already shipped to production.
In this example, nobody told the data team about the new discount structure before the implementation. The data team only found out because Finance noticed a mismatch in a dashboard owned by Data & Analytics. Analysts then quickly rebuilt the backend logic in SQL to fix the issue, leaving a fragile workaround because the change was never planned.
Until recently, bad data meant a wrong dashboard and a little less confidence in the data team’s ability to deliver accurate figures. Nowadays, with AI-based features and AI agents consuming the same data faster, the risks are higher.
I don’t think we can accept this as normal, even though many data teams see it as the justification for their existence: being the cleanup layer and the provider of a single source of truth. But it is very expensive for the company and, at scale, it slows everyone down.
In my experience, companies suffering from this have an ownership problem or, more precisely, an ownership gap. And engineering leaders (CTOs, VPs, and Directors of Product Engineering) have the authority to fix it.
In this article, I explore why companies end up in this situation, which mandates and incentives engineering leaders can use to close the gap, and what good ownership looks like in practice.
How Data Became Someone Else’s Problem
Inside a Data & Analytics department, the Data Platform team builds the core pipelines and makes sure data arrives on time and with good quality. Data analysts define the metrics and answer business questions with data.
Outside the data team, engineering teams produce data as a byproduct of building features, but they usually don’t own “the data”.
But why? When there is a data org that handles “data”, engineering teams have no incentive to own their data, and every data issue becomes a cross-functional dependency that takes weeks to sort out, or months if the company is unlucky.
This model dates back to when data was pure BI: daily dashboards to understand what happened. BI teams implemented the business logic in the data warehouse and concentrated the expertise there. It was efficient.
Some organizations learned the limits of this model the hard way when they started data science projects to personalize experiences or optimize their supply chain, or when product analysts started using advanced analytics and A/B testing to improve products. At that point, data started to have more than one consumer. The same is happening today with generative AI, which is just another consumer of the data, only not a human one.
In that scenario, when a change breaks the data, the cost shows up right away and engineers end up getting pulled into fixing the data problem anyway. Suddenly they are asked “why is this number wrong?” when they had no idea there was a problem in the first place.
In the next section, I detail the strategies that have worked for me to close this ownership gap.
Ownership Follows Incentives
Telling engineering teams to own their data rarely works by itself, although it is a valid starting point. The biggest lever is to give engineering teams a real incentive to own their data. Of course, this is easier said than done, but I’ve seen it work in several organizations. The approaches fall into three groups: top-down mandates, direct incentives, and indirect incentives.
Top-down mandates
Imagine senior leadership in a company announcing that backend and frontend teams now own data too.
This rarely works, especially in non-regulated industries. Or it works for the first few months, then stops having an effect, and the same problems the data team had before surface again.
Direct incentives
A direct incentive means that engineers benefit directly from good data because their own feature consumes it for real-time decisions, personalization, or fraud checks. When the data is wrong, their feature breaks, so they care without being asked.
Today, a very powerful direct incentive is AI. As more product teams are tasked with building LLM-powered features or AI agents, they quickly realize these models are extremely sensitive to data quality. If the underlying data is a mess, their shiny new AI feature will hallucinate or fail in front of the user. When bad data directly breaks the feature they are building, engineers are incentivized to fix it by themselves. The ownership gap closes on its own.
Indirect incentives
An indirect incentive is when the engineer’s team benefits from data ownership, rather than the engineer directly.
When an engineer, a PM, and an analyst share a team OKR tied to checkout conversion, for example, the engineer is indirectly incentivized to ensure tagging is accurate. If the data is wrong, the team can’t prove their feature increased conversion, which hurts their shared goal.
Each option has its pros and cons, and probably none of the three works alone. The next section shows how engineering leaders can combine these strategies to make it work.
What Engineering Data Ownership Looks Like
Engineering leaders can use top-down mandates to set the direction, and incentives to make it stick where they exist in the org (it might not be straightforward or easy to create incentives in all teams). Here are four practices engineering leaders can adopt.
1. Formulate the top-down mandate as a principle
When a CTO formulates a top-down mandate in the shape of a principle, they give their teams a guideline for making decisions. For example, the ownership principle can be phrased as follows:
“The teams who build products are responsible for the quality, documentation, and reliability of the data those products generate.”
It can also be framed as an engineering quality standard, in the same family as test coverage or uptime requirements.
When I was working at Oda, we worked toward cross-functional product teams being responsible for sending backend data and frontend events into Snowflake. They were familiar with Fivetran and Snowplow tagging, the tools we used back then.
Luckily, I lived another version of the discount example from before there: engineers created new fields and objects in the backend and talked with a data analyst about how best to send them for analysis before pushing to production.
2. Split business and technical ownership
Once the principle is in writing and part of the operating model, engineering leaders can add a new way of working: splitting ownership of everything data-related in two.
On one hand, product managers and data analysts should have business ownership of their specific domain (growth, retention, checkout, etc.). They decide how the domain is measured and how a specific metric needs to be calculated.
It is not enough for data analysts to own this; it is crucial to involve a PM. A PM has a stake here because, in the end, these metrics are how their domain gets judged.
On the other hand, technical ownership sits with engineering and data engineering. They are responsible for translating the business definition of a metric into code. They make sure the data behind that metric is correct, complete, and on time.
3. Bake incentives into day-to-day work
The split ownership from the previous point will only stick when it becomes part of the teams’ reality. Engineering leaders need to tie data quality to the metrics and rituals engineers already care about.
A good example is the shared OKR from the checkout conversion from earlier. Because PMs, analysts, and engineers share the same goal, if a data pipeline breaks, the team cannot measure their success.
When that happens, the fix shouldn’t be a Slack message to the data team. The data team can be involved, but it should work hand in hand with the product team’s engineers. When bad data actively affects an engineering team’s delivery velocity and its system reliability metrics, teams will naturally invest in fixing the root causes.
Finally, CTOs can use AI projects as a forcing function. If leadership wants to roll out user-facing AI features, the CTO can tie that directly to data ownership and make it clear to engineering teams that they cannot ship AI agents until their underlying domain data meets strict quality and documentation SLAs. AI becomes the ultimate carrot for having good data.
4. Implement governance as code
For this ownership split to work for engineering, teams can follow certain practices. What matters is that they are enforced in code; documenting them in a Confluence page doesn’t work. The most important practices are:
Every table or event has an owning team, enforced in the data catalog, through a dbt tag, or similar.
Schemas are tested against contracts or schema validations in CI. It is the product teams who own the contracts, not Data & Analytics. They are obliged to communicate if a new release breaks the contract.
Data incidents tag the owning team’s on-call, not just Data Platform engineers.
Business rules are controlled and computed once, as far upstream as possible, so that they can be used for purposes other than analytics.
New features ship with their measurement agreed up front between business and technical owners, connecting back to the indirect incentives example.
You are probably thinking that engineering teams don’t have time for this. I just added a lot of new work to software engineers’ plates. The key is to make it as cheap as possible for people to take it on: starting small, piloting it in a few teams first, building as much as possible into existing developer experience programs, etc.
What Data Teams Owe in Return
These strategies push data work beyond the Data & Analytics organization and, yes, add work to engineering teams. Data is no longer something that the Data & Analytics department takes care of. So what do data teams owe in return?
The answer is a data platform team that makes data ownership easy. The team must provide:
Self-serve tooling. Tools that live where engineers already work, such as AI agent skills to document schemas and define metrics.
Automation. Quality SLAs that engineers define next to their code and that run in their existing workflows (CI checks, alerts in the team’s own channels), not in a separate data portal.
Guardrails. Gates that stop engineering-owned data from reaching consumers until it meets minimum standards: documentation in place, metric definitions consistent with the agreed ones, and contracts passing.
The data platform team builds the infrastructure that makes data ownership a natural byproduct of engineering work. In return, data engineers stop rebuilding backend logic in SQL and stop acting as the cleanup layer. The data team gives up the role that justified its existence and moves to higher-value work.
Where to Start
Every strategy I mentioned is a decision about engineering culture. When the CTO or an engineering leader treats data as someone else’s problem, engineering teams treat it as someone else’s problem too. If the CTO prioritizes features over data quality, engineering teams will too.
However, if the CTO treats data quality as a first-class engineering concern, for example, by tracking the number of data incidents in quarterly reviews or rewarding good practices in performance reviews, engineering teams will invest in it.
A good start is to pick one product team as the pilot, define the metrics they own, and make the team responsible for the documentation and quality of the datasets behind those metrics.
Data quality and pipeline success belong on the engineering dashboard, with schema documentation completeness, data freshness, and quality SLA compliance tracked and visible alongside system reliability metrics.
Data quality work goes in the backlog like any other engineering work. Tracking the before and after matters too: success in one team creates demand for the pattern in others.
The goal is to make the CTO ask about data quality with the same rigor as system reliability. And the CTO who treats data as a company-wide problem, and not just a data problem, is the CTO whose organization will use AI well.
Enjoyed this post? You might like my book, Data as a Product Driver 🚚.