It's Monday's leadership meeting. Marketing says you added 412 new customers last month. Finance says 371. The product dashboard says 455. Twenty minutes later, nobody has talked about what to do — everyone is still arguing about which number is right.
If that sounds familiar, you don't have a data problem. You have a data governance problem. And before you picture a committee, a 40-page policy document, and an expensive software contract — relax. For a team of 5 to 50 people, governance is mostly a handful of habits you can set up in an afternoon.
In this article you'll learn what data governance actually means for a small company, the six habits that cover 90% of it, and the mistakes that quietly make your numbers untrustworthy.
What "data governance" means (in plain English)
Strip away the jargon and data governance answers four questions:
- What do our numbers mean? (definitions)
- Who is responsible for each one? (ownership)
- Who can see what? (access)
- Can we trust it? (quality)
Think of it like the rules of a shared kitchen. Nobody needs a manual to cook, but it helps if everyone agrees where the knives go, who restocks the milk, and that you don't eat the food labeled with someone else's name. Without those few rules, the kitchen still works — it's just chaotic, and eventually someone gets food poisoning.
Big companies formalize this with dedicated teams and catalog software. Small teams can get most of the benefit with a shared doc, a few naming rules, and a little discipline.
Why small teams need it more, not less
It's tempting to think governance is something you "grow into." But small teams are actually more exposed:
- Everyone touches the data. In a 15-person startup, the founder, the ops lead, and a part-time contractor might all be building reports.
- Knowledge lives in heads. When the one person who knows that "active user" excludes internal test accounts goes on vacation, the numbers drift.
- Mistakes compound fast. A wrong churn number in a fundraising deck or a pricing decision costs more when you have less runway.
- AI tools multiply questions. As teams start asking AI assistants questions about their data, an undefined metric gets interpreted a different way every time it's asked.
Habit 1: Write a one-page metric dictionary
This is the single highest-value thing you can do. Pick your 10–15 most important numbers and, for each, write down a plain-language definition, how it's calculated, and what's excluded.
| Metric | Definition | Excludes | Owner |
|---|---|---|---|
| New customer | An account whose first successful payment happened in the period | Free trials, internal/test accounts, refunded-within-7-days | Finance lead |
| Active user | A user who performed at least one core action (created or edited a project) in the last 28 days | Logins only, employees | Product lead |
| MRR | Sum of normalized monthly subscription revenue for paying accounts | One-time fees, taxes, discounts expired | Finance lead |
Notice the "Excludes" column. That's where almost every disagreement hides. The 412 vs. 371 vs. 455 argument from the intro? It's almost always a difference in what got excluded — trials, refunds, test accounts, or time zones.
Keep it somewhere everyone already looks: a pinned doc, your wiki, or the description field of the dashboard itself.
Habit 2: Give every important number an owner
"Owner" doesn't mean the only person allowed to look at it. It means the person who:
- Decides the definition when there's ambiguity
- Gets pinged when the number looks wrong
- Approves changes to how it's calculated
Without an owner, a broken metric becomes everyone's problem — which means nobody's. One name per metric is enough. In a tiny company, the same person may own five metrics. That's fine.
Habit 3: Have one "official" source for each metric
Most "which number is right?" fights happen because the same metric exists in three places: a spreadsheet someone exported in March, a dashboard in the BI tool, and a chart inside your billing system.
Pick one place as the source of truth for each key metric and label it clearly — for example, a dashboard folder called "Official — reviewed monthly". Everything else is exploration. People can still build their own quick charts; they just don't present them in leadership meetings as the number.
A useful rule: if it goes in a board deck, investor update, or company-wide meeting, it comes from the official source.
Habit 4: Access by role, not by convenience
Access is the "who can see what" piece, and small teams usually get it wrong in one direction: everyone gets admin credentials to the production database because it was easiest on day one.
A lightweight approach:
| Role | Typical access |
|---|---|
| Most of the team | View shared dashboards; no raw database access |
| Analysts / power users | Read-only access to the data, ideally a replica or warehouse copy |
| Engineers on call | Write access, logged and limited |
Pay special attention to sensitive data — customer emails, payment details, salaries, health or personal information. A simple rule like "personal data columns are hidden from dashboards unless there's a specific need" prevents a lot of accidents. And when someone leaves the company, remove their access the same day; shared logins make that impossible, so avoid them.
This matters even more if you're letting AI assistants query your data. Give them the same read-only, least-privilege treatment you'd give a new contractor. Many tools now connect through managed, read-only connections for exactly this reason (Draxlr's MCP server is one example), but the principle — read-only, scoped, auditable — applies whatever you use.
Habit 5: Build in lightweight quality checks
You don't need a data quality platform. You need a few tripwires that tell you when something looks off:
- Sanity ranges: "Daily signups are usually 40–120. Alert if it's 0 or 900."
- Freshness checks: a "last updated" timestamp on every official dashboard, so nobody makes decisions on data that stopped syncing last Tuesday.
- Reconciliation once a month: does revenue in the dashboard roughly match revenue in your billing system? If not, find out why before someone else does.
- A known-issues note: "Signups from Sept 3–5 are undercounted due to a tracking bug." Two sentences save hours of confused investigation later.
Habit 6: Change definitions deliberately
Definitions should evolve. Maybe you decide that "active" should mean two core actions instead of one. The problem is when they change silently, and suddenly your growth chart has a cliff nobody can explain.
When a definition changes:
- The owner approves it.
- Update the metric dictionary with the date and reason.
- Annotate the chart where the change took effect.
- Tell people — a one-line message in your team channel is enough.
Common mistakes to avoid
- Starting too big. Trying to document every column in every table means nothing gets finished. Start with the 10 numbers leadership actually uses.
- Treating governance as a one-time project. A metric dictionary from 18 months ago is worse than none, because people trust it. Review it quarterly.
- Locking everything down. Governance that makes it impossible to get answers pushes people back to rogue spreadsheets. The goal is trusted self-service, not no self-service.
- Ignoring time zones and dates. "Last month" in UTC and "last month" in Pacific time can differ by hundreds of orders. Pick one and write it in the dictionary.
- Letting test data leak in. Internal accounts, QA users, and demo workspaces inflate early-stage metrics dramatically. Flag them once, exclude them everywhere.
- No owner for AI-generated answers. If an AI assistant answers "how many customers churned?", it should be using your documented definition — and someone should spot-check it against the official dashboard.
Key takeaways
- Data governance for a small team is about definitions, ownership, access, and quality — not committees.
- A one-page metric dictionary with an "Excludes" column resolves most number disagreements.
- Every key metric needs one owner and one official source.
- Grant access by role, keep most people read-only, and treat AI tools the same way.
- Add a few cheap quality checks and announce definition changes.
- Start with your top 10 metrics this week; you can expand later.
The payoff isn't bureaucracy — it's meetings where you spend the time deciding what to do, instead of debating which spreadsheet is right.
What does your team use as its "source of truth" for metrics — a doc, a BI tool, a wiki page, or tribal knowledge? Share your setup (or your best "three different numbers" horror story) in the comments.
Top comments (0)