I learned the difference between being responsible and being accountable long before I ever worked with data. I hadn’t yet turned 23 when I arrived at my first duty assignment as a newly-minted lieutenant. I was the battalion chemical officer, responsible for contingency plans if weapons of mass destruction were ever used. Part of my responsibility was inventorying and maintaining the detection and decontamination equipment for a unit of 400 men. This included some very advanced electronics with low-radioactive isotopes. In today’s dollars all of it could be worth well over a million dollars. If something happened to that equipment, my career was on the line.
I saw the same lesson play out again when I was a manufacturing engineer. In manufacturing, the plant manager owns the line. If scrap rates climb or a shipment misses its window, the conversation starts and ends with that person. The process engineers, the quality technicians, and the operators on the floor are the ones who actually change the set points, quarantine the bad parts, and rewrite the work instructions. They are responsible for the work. The manager is accountable for the result.
Data isn’t any different, though looking at most corporate data org charts, you’d think we were all stuck in a mid-80s Tuesday night primetime loop—constantly asking, “Who’s the boss?” line-item by line-item while Tony Micelli and Angela Bower debate who actually holds the title.
Most organizations say they have “data governance”; in reality, all they have is a slide that lists roles and a meeting that no one wants to attend. What’s usually lacking is a clean line between the person accountable for the quality and usefulness of a data set, and the people actually doing the work to keep it that way.
Years ago, I wrote an outline for a data governance course that never shipped. In the introduction, I put it this way: the owner is responsible for quality, but the stewards are responsible for implementing.
That single sentence is still what most teams get wrong.
The data owner is the person answers for the data when something is wrong. They’re usually a business leader or a senior domain expert who understands the value the data is supposed to create, and also the damage it can cause if it’s wrong, late, or misused. They don’t need to know how to write a dbt model or tune a clustering key. They do need to be able to say, “This definition of an active member is the one we will use for reporting and for the next campaign,” and then stand behind that decision when the numbers move. In a data mesh, this is the domain owner. Sales owns sales data. Claims owns claims data. The remote central team does not reverse-engineer the meaning; the people closest to the source do.
The stewards are the ones who turn accountability into something that can actually run. There are usually two kinds.
The first is the business steward. Typically an analyst or operations specialist, the business steward lives in the use cases. They know the business rules, the edge cases, the workflows, and the value that’s supposed to come out the other side.
In one hybrid domain I worked near, the “Rewards” data was not pure marketing and not pure finance. It sat in the middle: eligibility rules that looked like product, calculation logic that looked like finance, and reporting that looked like marketing. The business steward was the person who could say which rule applied when a customer was both a rewards member and a claims filer, and who could defend that rule when finance and marketing disagreed. They own the business logic and the certified definitions that eventually live in the gold layer.
The technical steward is the data architect or senior engineer who owns the data model and the quality implementation. They decide how the grain is expressed, where the conformance checks live, how duplicates are collapsed, and how the contracts between bronze, silver, and gold levels are enforced.
They aren’t, however, free to invent meaning.
Technical stewards implement the meaning the owner and business steward have already accepted. When schema drift or a grain mismatch appears, the technical steward is the one who makes the pipeline or the model stop lying about it.
Operators are the people who keep the lights on: the pipeline runners, the platform engineers, the people who monitor jobs and respond when something fails. They are essential, but they aren’t stewards and they aren’t owners. Their job is execution and escalation, not definition.
In some ways this mirrored my experience in the army. The staff officers were the business stewards, dictating the plan of battle. The warrant officers were the technical stewards, technical specialists who dealt with the nuts and bolts of the vehicles. And the sergeants were the operators, the ones responsible for making sure the job got done.
The commander still owned the outcome.
Somewhere above all of this sits a data governance board or council. Its job is not to become another ticket queue. It is to set the global rules that no single domain should invent on its own—naming standards, PII handling, retention baselines, interoperability expectations—and to resolve the conflicts that appear when two domains both claim ownership of the same concept. In the artillery analogy I used earlier, this is closer to fire-support coordination than to the gun line itself. The board does not pull the lanyard; it keeps the guns from shooting the same grid twice.
When data governance lets down the business, it almost always happens the same way. Organizations name owners who never attend the working sessions, then expect the technical team to invent the business rules. Or they name stewards who have no authority to change a source system or a definition, then wonder why quality never improves. The owner must be close enough to the outcome to feel the pain when the data is wrong, and distant enough from the daily implementation that they do not become a bottleneck. The stewards must have both the domain knowledge and the technical or analytical skill to implement, plus enough access that their work can actually land in production.
None of this requires a new platform. It requires the same discipline that already shows up in a well-run medallion architecture: bronze preserves what arrived, silver makes it accurate and conformant, gold makes it useful under an agreed definition. The owner is accountable for whether that gold definition is the right one. The stewards are responsible for making the definition real and for keeping the silver checks from silently laundering defects into the gold layer.
In the navy, it’s said the captain goes down with his ship. The same thing applies to data owners. You don’t solve a governance problem by throwing the stewards under the bus.
If you are starting from a blank page, begin with one critical data set. Name the owner who will answer for it. Name the business steward who knows the rules and the technical steward who will implement them. Write down the three or four quality problems that currently cost the most time or produce the most wrong numbers. That is enough to start. The board and the operators can come later. The accountability line has to be clear first, or everything else is just another meeting.