Who owns the model?

Writing SQL is fine until you are maintaining forty-seven versions of the same query, chasing which one broke a dashboard, or explaining to someone senior why revenue means three different things depending on who they ask.

The first two are annoying. The third is the actual problem, and no tool fixes it. It is an ownership question, and it has become a more consequential one than it was when I first wrote about it.

The question got promoted

For most of my career, a model definition was something you could argue about later. Two teams computing revenue differently was a meeting, an awkward reconciliation, and eventually a decision. Slow and irritating, but recoverable, because the disagreement was visible: two numbers, two people, one argument.

That recoverability came from the definitions being contested out loud.

A system that answers questions does not contest anything. It picks a model and speaks. Whichever definition happens to be wired in becomes the company’s answer by default, everywhere, at once, without a meeting.

So the ownership question got promoted. It used to be about velocity: who can ship a change without waiting on engineering. It is now about authorship. Whoever owns the model is not maintaining SQL. They are deciding what the company will say when someone asks.

That is the frame for everything below. The tooling made the move possible. The reason to make it is that the people who understand what a number means should be the people who decide what it says.

The tooling, briefly

dbt does a small number of things well, and the tooling is not the interesting part, so this stays short. The piece doing the important work is ref(), the way one model points at another. It builds the dependency graph, which determines execution order and, more usefully, tells you exactly what breaks when you change something. Tests live beside the model as configuration rather than in a suite someone forgets to run. Documentation generates from the project, which is the only documentation that survives a deadline. Incremental models process only new rows, which shows up on the warehouse bill.

All good. None of it is why the move mattered.

The move

I have moved data model ownership out of engineering and into the analysts’ hands. On paper that is a tooling change: analysts already wrote SQL, and dbt let them write SQL that ships. In practice it was nothing of the sort.

Engineers owned the models because engineers were trusted with production. Analysts were not, and nobody had ever written that rule down or examined it. The moment you propose handing over ownership, every unexamined version of it surfaces at once. What if they break something. What if the numbers change and nobody notices. What if we spend a quarter cleaning up.

Some of that is legitimate, and more of it than I wanted to admit at the time. Engineers own production for real reasons: they are the ones paged at 2 a.m., they understand the warehouse bill, they know what a bad model does to the tables downstream of it. Those concerns deserved answers, not dismissal.

Some of it was a control question dressed as a competence question, because competence is the easier thing to say out loud. Telling those two apart was most of the work.

What made it work was not winning that argument. It was making the guardrails real enough that the argument stopped needing to happen.

Tests are not optional. A model shipping without tests brings the trust question straight back, and you will lose it. The tests stand in for trust that has not been earned yet, and eventually they become the reason it gets earned.

Review stays. Analysts own the models, and engineers review the pull requests. Not as a gate on competence, but as the normal way software gets written. That framing matters, because the alternative reads as supervision, and people can tell the difference immediately.

Downstream owners approve what affects them. An alert tells you something already broke. An approval stops it breaking.

Someone owns each definition. The forty-seven versions do not vanish because you moved them into a repo. They vanish when one person is accountable for what revenue means and everyone else references that model instead of writing their own.

The full set, with CI and a review model that moves with capability, and what each piece cost, is the case study Giving the models away. The point here is the one the case study takes for granted: once the guardrails exist, the argument about trust becomes an argument about meaning, which is the argument worth having.

Where this meets governance

I used to treat ownership and governance as separate programs. One is an organizational question about who writes what; the other is a policy layer about catalogs, lineage and access. Running both at once made it obvious they are the same thing viewed from different ends.

A catalog tells you a model exists. Lineage tells you what depends on it. Neither tells you who decides what it means, and that is the question that determines whether the number is trustworthy. Governance without named owners is documentation. Ownership without lineage is people making confident changes they cannot see the consequences of.

The dependency graph turned out to be the connective tissue. Once models are code with ref() wiring them together, lineage stops being something you maintain in a separate tool and becomes a property of the project. Schema changes notify the right people because the graph knows who is downstream. Approvals route to real people because ownership is recorded next to the model rather than in someone’s memory. The governance essay sets out which changes need an agreement rather than a notice.

Do not run a governance program and an ownership migration as two initiatives. The ownership move is how governance stops being a slide deck.

What it cost

This was not free, and a version of this piece that pretended otherwise would be worthless.

Models multiply. Give twelve people write access and you get near-duplicates with slightly different filters, each one someone’s preferred version of the truth. That is the forty-seven-versions problem coming back in a new costume, and the only fix is the boring one: a named owner per definition, and a review culture that asks “does this already exist” before it asks “is this correct.”

Warehouse spend becomes the analysts’ concern, and they do not arrive thinking about it. Materialization choices and incremental models have to be taught, not assumed, and the first full rebuild of a large table is usually how the lesson arrives.

And authorship is heavier than maintenance. An analyst who owns the revenue model now owns the company’s answer about revenue, including the day an assistant repeats it to someone who never asked which definition was in use. That is a responsibility, and it needs engineering support proportionate to the risk. Neither job disappears when ownership moves. Engineers stop writing models and start reading them, which is faster but not free, and nobody budgets for it up front. Their job changes from writing the model to making sure it cannot quietly say something wrong.

None of that argues against the move. It argues against announcing it as done the week the tooling ships.

What changed

The engineers got time back. That was the stated goal and the least interesting result.

More useful: the people who understood what the numbers meant became the people who defined them. That gap, between whoever knows the business logic and whoever holds write access, is where most bad metrics come from. Closing it did more for data quality than any test in the suite.

The part I did not expect is that ownership changed how closely people looked. Analysts stopped asking for data and started asking sharper questions about it, because nobody reads a pipeline carefully until it is theirs.

That is the answer I would give now to “who owns the model.” Whoever can say what the number means, and is prepared to be the one who said it.