An editorial preview prepared for this diary, awaiting the author’s review. Examples are hypothetical.
Start where the work happens
Data governance often arrives as a document. There is a framework to review, a policy to approve, and a diagram explaining who reports to whom. These can all be useful. Yet they become meaningful only when people recognise a problem that the structure helps them solve. A useful starting point is therefore a conversation about work: a decision that keeps getting delayed, a report that attracts disagreement, or a request that nobody feels able to answer. The purpose is to find a shared concern before proposing a shared process.
Consider a hypothetical team preparing a monthly service report. Operations counts a case when it is opened, finance counts it when a payment is recorded, and the leadership dashboard counts it when it is closed. Everyone may be calculating accurately, while answering a different question. Calling this a data problem is reasonable, but incomplete. The conversation first needs to establish which decision the report supports, which definition belongs in that context, and how the other legitimate definitions will be described. Governance begins by making that difference visible.
Listen for the decision
A productive governance discussion stays close to a decision. Ask what someone needs to do differently when the information changes. Ask what happens when it arrives late, or when two trusted sources disagree. These questions reveal the significance of the issue without asking colleagues to learn specialist vocabulary. They also help distinguish something inconvenient from something important. A recurring disagreement about a measure used to allocate resources deserves different attention from a cosmetic inconsistency in an internal spreadsheet that does not affect anyone's work.
The next question is who can resolve that uncertainty. This is rarely identical to asking who owns the system. A technical team may manage a platform while another team understands the business meaning of a field. A manager may approve a definition while a steward maintains its description and gathers questions from users. Naming these different responsibilities makes collaboration more practical. It also prevents ownership from becoming a vague label that gives somebody accountability without the time, authority, or support needed to carry it.
Start with a decision. Build the agreement around it.
- The decision
What are we trying to decide?
- The people
Who needs to be part of it?
- The agreement
Who owns the next step?
Make a small agreement
The first agreement does not need to cover the whole organisation. Choose one important measure, one dataset, or one recurring decision. Write down its purpose, the meaning of the key terms, the person who can approve a change, and the route for raising an unresolved question. Add a review date. Keep the language short enough that a colleague can use it during an ordinary working day. If the agreement requires a lengthy explanation before it can be applied, there is probably still an ambiguity worth discussing.
For the hypothetical service report, the agreement might say that the leadership measure represents cases closed during the reporting month. It would explain which timestamp determines closure, how reopened cases are handled, and who reviews exceptions. It would also name the opening and payment measures rather than treating them as errors. This creates a useful distinction between a shared definition and a universal definition. The goal is consistent interpretation for a stated purpose, with enough context to avoid forcing every legitimate use into the same shape.
Give stewardship a working rhythm
A named steward helps only when the responsibility fits into real work. Decide how questions will reach that person, how much time they can spend on them, and where decisions will be recorded. Some issues can be handled through a short conversation. Others need a review with the relevant subject experts. A small, predictable rhythm is often easier to maintain than a large meeting that accumulates every possible topic. The important point is that users can see where to go and what they can expect next.
Keep a decision log that records the question, the options considered, the agreed answer, and the reason behind it. This makes future conversations easier because people can understand the context instead of reopening the same issue from the beginning. A log should not become a transcript of every meeting. Its value lies in preserving the reasoning needed to use an agreement responsibly. When circumstances change, that reasoning helps the team recognise whether the agreement still applies or deserves another look.
Notice whether work gets easier
Measure progress through the original concern. Are reports taking less time to reconcile? Can a new colleague find the right definition? Are questions reaching the right person sooner? The number of policies published may describe activity, but it does not explain whether governance is helping. Choose a small number of signals that the participating teams can understand and influence. Discuss them openly, including cases where a new process adds effort without producing enough benefit. That feedback is part of governance rather than an objection to it.
Be careful with claims of success. If a reporting process improves, several changes may have contributed. Describe the observable difference and the conditions around it. A team might say that the same definition was used in three consecutive reporting cycles, or that an unresolved question now has a documented route for review. These are modest statements, but they are specific and useful. They give colleagues a reason to continue without promising that a framework will remove every disagreement or make every dataset trustworthy.
Let the framework follow
Once an agreement works in practice, look for patterns. The same responsibilities, escalation routes, and review questions may apply elsewhere. That is the moment to make a reusable template and connect local practice to a broader framework. The framework then describes a way of working that people have already tested. It can still set expectations and establish boundaries, but its language has roots in recognisable situations. Expansion becomes a matter of adapting useful habits, with attention to the differences between teams and decisions.
A practical next step is to invite three people who see the same data from different angles. Bring one disputed measure and ask each person what it means, what they use it for, and what would make them more confident in it. Capture the points of agreement and leave the genuine differences visible. Agree one owner for the next action and a date to revisit it. This will not finish data governance. It will give it something more valuable than an abstract starting point: a shared problem and a small commitment.
Start with one real decision, make one useful agreement, and give people a clear way to keep that agreement alive.
Put the thought into practice.
A practical starting template. Download it and adapt it to your own context.
Download resource (MD)What could this look like in your organization?
Add your context and build a brief for your AI assistant, or download a video storyboard for this entry.
Open the application guide