Building Shared Data Vocabulary

In the last unit you learned to put a number on governance and frame it in a leader's terms. But almost every value case you make eventually traces back to the same root: two teams using one word to mean two different things. Before you can settle that, you have to see what kind of data you're actually arguing about, because "active customer" and "currency code" are not the same animal and they don't drift for the same reasons. This unit gives you the vocabulary to sort the data, the moves to align people on a definition, and a way to write it down so it sticks.

Start by learning to recognize the four Core Data Types, because naming the type tells you where a problem lives and what kind of fix it needs.

Master data is the important "nouns" your business reuses everywhere: customers, products, employees, suppliers. Reference data is the standardized lists people pick from, like country codes, currency codes, or status values that everyone is supposed to share.

Metadata is data about data: the definition, the source, the owner, the last-updated date. Think of it as the label on the jar rather than what's inside. Transactional data is the record of events that happened: an order placed, a payment made, a ticket logged, a login.

Here's why this matters in your day-to-day. When a number is disputed, the type points you to the cause. A fight over "who counts as a customer" is a master-data problem (one real person showing up as several records). A complaint that "this code isn't allowed" is reference data. A question like "what does this field even mean?" is metadata. And "the order total looks off" is transactional. Diagnosing the type first keeps you from treating a definition disagreement as if it were a broken record.

Most of the value lives in master data and the metadata that defines it, so your core skill is getting people to agree on what a term means. Your job here is facilitator, not judge. You surface why two teams differ, then drive them toward four things: a single business definition, a named owner, the valid values that count, and usage notes that stop future drift.

• Marcus (Finance): We only count someone as active if they've paid this quarter.
• Jessica: And we count anyone who logged in within ninety days. That's why our dashboards never match.
• Chris: So the gap is the time window and whether payment is required. Let's land one business meaning you both can live with, then name who owns it.
• Jessica: I can accept "paid within the last quarter" as the official one, as long as my engagement view keeps its own clear label.
• Marcus (Finance): Works for me, as long as Finance signs off on any change to it.

Notice the moves Chris made. He didn't crown a winner; he restated the trade-off neutrally, secured a single owner, and let each team keep its local view under a different, honest label. That last part matters: people resist alignment when it feels like erasure, so give the side view a name instead of killing it.