One of the biggest challenges we have seen organizations face is the chaos that emerges due to confusion around what certain terms in the business mean. The strength of a data team (or any other team, for that matter!) is derived from the diversity of the people in it. As a leader, you experience first-hand how these diverse mindsets approach problems in their own unique ways.
This diversity is an asset, but to truly get the most value from it, everyone in the organization needs to speak the same language — and a good glossary does exactly this! It helps you tame that chaos. How awesome it would be if everyone understands exactly what you mean, the first time around?!
To solve this challenge, some of our amazing DataOps champions started experimenting with glossary structures that empower teams to collaborate efficiently.
Glossary 101
A glossary is a list of terms, organized in a way to help users understand their data assets. It helps people identify, manage, and discover data assets in a consistent manner. For example, terms like cost, P&L, and revenue can be used to group and search all financial data assets.
Using familiar terminology helps people quickly understand the data and its background. This is a crucial element of data governance as it helps business users better understand an organization's data initiatives.
Glossaries are unique to every organization, but broadly there are four types of glossaries that power your data needs.
Business glossary
This helps define the business terminology and gets everyone on the same page as to what these business terms mean. When you build this glossary, definitely include terms that have always been pain points for team collaboration — for example, annual statements, appraisals, etc.
Metrics glossary
This gives everyone in the organization a quick view into the KPIs and business metrics that are being tracked. For example, think of ARR, MAU, etc. A metrics glossary is also a great way to bridge the gap between technical and business counterparts, since it gives everyone complete transparency on what a metric means.
Technical glossary
You can think of a technical glossary as a data dictionary, only cooler! It is great for defining technical terms from data tables or data models — for example, policy_expiration_date, policy_id, etc. Your data team will use these as they decide how to create views, dashboards, and insights.
Projects glossary
A projects glossary relates to your internal projects or reporting. For example, think of a project that started as an experiment, but now you are expanding it to add more capabilities. Or a project that is being handed over to someone. Or a project that started within your data team, but now marketing wants to collaborate on it. Well, definitions for all such projects can live in your projects glossary.
Framework for defining your glossary structure
Now that you know of the broad four categories of glossary structure, you must be thinking, "Which type of structure is right for us?" Well, the answer is, it depends!
If one of the most challenging areas for your organization is a lack of understanding around how you are calculating metrics today, then you can start out with a metrics glossary across different departments. Below, we have shared an example of what a metrics glossary structure might look like.
On the other hand, if your biggest pain point is around business terms, then a business glossary might be a good place to start. For example, maybe everyone in the organization has a different definition for "customer", "active contract", "service", etc. In such a scenario, creating a business glossary serves as a single source of definition for everyone.
You can use the framework below to define what each type of glossary might look like for you.
It is possible that everything looks equally important and you are not sure which one to pick. In that case, ask yourselves the following questions to help you prioritize:
- In which areas do we see most "data brawls" (challenging conversations) happening?
- Typically, the terms that caused the most confusion over the years are good candidates for a glossary. Look for a team that has to constantly explain or do additional work due to the lack of common language, and they can be your starting point.
- Do we have a motivated champion to align the rest of the team?
- We highly recommend starting out with teams that have motivated individuals who can take ownership. You should build an end-to-end MVP glossary for them, take learnings, and then create a structure for the entire organization.
- Which teams already have a makeshift solution in place — for example, defining terms in spreadsheets or Google documents?
- Before you decide on an organization-wide glossary structure, speak to your end users — understand what kind of problems they face due to a lack of common language, and what solutions (if any) they use today. The insights from these sessions will be critical in helping you decide your organization's glossary structure.