Who owns the model?

Writing SQL is fine until you’re 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 one is the actual problem, and no tool fixes it. It’s an ownership question.

The tooling, briefly

dbt does a small number of things well, and I’ll keep this short because the tooling is not the interesting part.

Models are SELECT statements with a config flag deciding whether they land as a table or a view. No hand-written DDL, no managing drops and recreates.

{{ config(materialized='table') }}
SELECT * FROM {{ ref('raw_orders') }}

That ref() is quietly doing the important work. It builds the dependency graph, which is what determines execution order and, more usefully, what tells you exactly what breaks when you change something.

Tests live beside the model as configuration rather than in a separate suite someone forgets to run. Docs generate from what’s already in the project, which is the only documentation approach that survives a deadline. Jinja collapses twelve near-identical queries into one. Snapshots handle slowly changing dimensions without anyone hand-rolling temporal logic. 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’ve moved data model ownership out of engineering and into the analysts’ hands.

On paper that’s a tooling change. Analysts already wrote SQL; 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 weren’t, 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’re the ones paged at 2am, 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 also 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 wasn’t 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 hasn’t been earned yet, and eventually they become the reason it gets earned.

Review stays. Analysts own the models, engineers review the pull requests. Not as a gate on competence, 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. The same control I wrote about in the governance piece, for the same reason. An alert tells you something already broke. An approval stops it breaking.

Someone owns each definition. The forty-seven versions don’t 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 org-design version of this argument, with the tradeoff stated as a tradeoff, is written up separately in Giving the models away.

Where this meets governance

I used to treat ownership and governance as separate programs. One is an org question about who writes what, the other is a policy layer about catalogs, lineage, and access. Running both at once made it obvious they’re 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’s the question that actually determines whether the number is trustworthy. Governance without named owners is documentation. Ownership without lineage is people making confident changes they can’t 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 fire notifications because the graph knows who’s downstream. Approvals route to real people because ownership is recorded next to the model rather than in someone’s memory.

That’s the part I’d tell anyone doing this. Don’t 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 wasn’t free, and a version of this piece that pretends 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’s 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 a team concern rather than an engineering one, and analysts don’t arrive thinking about it. Incremental models and materialization choices have to be taught, not assumed.

And review load shifts. Engineers stopped writing models and started reading them, which is faster but not free, and nobody budgets for it up front.

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

What changed, and what I didn’t expect

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 didn’t 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’s theirs.

One more reason this matters now

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 humans, one argument.

That recoverability came from the definitions being contested out loud.

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

So the ownership question got quietly promoted. It used to be about velocity: who can ship a change without waiting on engineering. It’s now about authorship. Whoever owns the model isn’t just maintaining SQL, they’re deciding what the company will say when someone asks.

That’s a bigger job than it was in 2025, and it’s a good argument for putting it with the people who understand what the number is supposed to mean.