Data ownership fails in a specific and predictable way. Somebody builds a matrix. The matrix lists domains down one axis and names across the other. Cells are filled with R, A, C and I. The matrix is circulated, approved and published. Six months later, a field changes meaning, nobody is told, three downstream reports quietly disagree, and the matrix has had no effect on any part of that sequence.
The matrix was not the problem. The assumption underneath it was. That assumption is that ownership is a labelling exercise, and that once the correct label is applied, the correct behaviour follows.
Ownership is a workload, not a title
When we ask a newly named data owner what changed for them, the honest answer is usually nothing. Their calendar is identical. Their objectives are identical. Their manager has not been told. What they received was a designation with no accompanying budget of time, and time is the only currency stewardship actually runs on.
Real stewardship has a workload attached, and it is not trivial. Someone has to review proposed schema changes. Someone has to arbitrate when two teams want the same field to mean two different things. Someone has to decide whether a definition change is a correction or a break. Someone has to be reachable when a pipeline fails at seven in the morning and the question is whether to hold the report or ship it with a caveat.
Estimate that honestly and it lands somewhere between half a day and two days a month for a meaningful domain. Nobody absorbs two days a month invisibly. If it is not carved out, it does not happen, and the designation degrades into a name in a cell.
The three tests we apply
Before we accept that a domain has an owner, we check three things. They are deliberately blunt.
Can they say no
If an engineering team proposes a change to a field the owner is responsible for, can the owner block it? Not escalate it, not comment on it. Block it, and have that block hold.
Ownership without a veto is advisory, and advisory roles lose to delivery pressure every single time. This is the test most organisations fail, and it fails upward: the owner is junior to the person shipping the change, so the block is theoretical.
Do they find out automatically
An owner who depends on being remembered is not an owner. If the notification path is a person choosing to mention something in a stand-up, the system will fail whenever that person is on holiday, busy, new, or reasonably assumes someone else has mentioned it.
The fix is mechanical. Changes to owned assets generate a review request. The pull request cannot merge without it. This is unglamorous plumbing and it does more for governance than any policy revision we have ever seen.
Does anyone notice if they stop
If an owner did nothing for a quarter, would anything visibly change? If not, the role has no load-bearing function and you have created ceremony. This test is uncomfortable to run and worth running anyway, because it tells you which parts of your governance model are real.
Federate the decision, centralise the standard
There is a long-running argument about whether governance should be central or distributed. In our experience the argument is malformed, because the two things being argued about are different.
Decisions about meaning belong to the domain. What counts as an active customer is a commercial question, and a central data team answering it is guessing. Push that decision to the people who live with the consequences.
Decisions about form belong to the centre. How a definition is recorded, where it lives, what a breaking change requires, how deprecation is communicated, what the minimum test coverage is. These are consistency problems, and consistency is exactly what a central function is for.
Get this the wrong way round and you produce the two classic failure states. A central team defining business semantics produces definitions nobody uses. Fully devolved standards produce eleven mutually incompatible ways to describe the same customer.
Make the good path the easy path
The most effective stewardship intervention we have run had nothing to do with policy. A client had a recurring problem with undocumented metric changes. The stated process required updating a definitions register held in a separate system, with a separate login, that engineers did not otherwise open.
We moved the definition into the transformation code, as a required property on the model. Missing or unchanged definitions failed the build. Compliance went from roughly a third to effectively complete in one sprint, and nobody attended a training session.
The lesson generalises. When the compliant path costs more than the non-compliant path, people take the cheaper one, and no amount of communication changes that arithmetic. Change the arithmetic instead.
What we would do first
- Pick the three domains where a wrong number costs the most. Ignore the rest for now. Full-estate coverage is how these programmes die.
- Name one person per domain, with a deputy, and put the time in their objectives in writing.
- Wire the notification path so changes reach them without anyone remembering to tell them.
- Give them a real veto and back it publicly the first time it is exercised. That first moment sets whether the role is genuine.
- Move the definition to wherever the work already happens.
Then expand, slowly, and only into domains where the same conditions can be met. A stewardship model covering three domains properly is worth more than one covering forty on paper.
A note on the word steward
Some organisations distinguish owners from stewards, the owner being accountable and the steward doing the work. Where the distinction is real and both roles are resourced, it works well. Where it is introduced to give a senior person accountability without a workload and a junior person a workload without authority, it produces the worst of both. The senior name provides cover, the junior person cannot say no, and the arrangement looks complete on the org chart while doing nothing.
If you are going to split the role, check that the steward passes the veto test in their own right. If they have to escalate every disagreement to the owner, you have added a step rather than distributed responsibility.
