#10 Using glossary to speak the same language in the organization


Before we dive into this week's digest, I want to give a big thanks to all of you who voted on the poll last week. It has been incredibly helpful for us to look at the results so far and start designing a community plan for you. Just a note that we will be closing the poll on Monday (22nd November) at 5 PM GMT, so if you haven't already, please do have your voice count and vote here - link

On to other fun stuff!

Last few weeks, we did a four-part series to talk at length about use cases, something that we discussed a lot during office hours. This week, I want to share another office hours favorite topic — glossaries! We will be doing a two-part series on decoding what goes into successfully implementing a glossary in your organization. Let's start with Part 1!

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. As a leader, you experience first-hand how 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.

A glossary is a list of terms, organized in a way to help users understand their data assets. You can have multiple glossaries for your organization, but they must be mutually exclusive. Though glossaries are unique to every organization, there are four types of glossaries that power your data needs.

1. Business Glossary

This helps define the business terminology and gets everyone on the same page as to what these business terms mean — for example, terms like annual statements and appraisals are great candidates to be included in the business glossary.

2️. Metrics Glossary

This gives everyone in the organization a quick view of the KPIs and business metrics that are being tracked. For example, think of ARR, MAU, etc. One of the best practices we recommend is to link saved queries to metrics definitions. This ensures that if your end user reads a term definition, they can also easily see what query is being run to get those numbers. This not only brings trust and transparency to the team, but is also handy while onboarding new members.


3. Technical Glossary

You can think of a technical glossary as a data dictionary, but only cooler! It is great for defining technical terms from data tables or data models — for example, policy_expiration_date, policy_id, etc. Data teams often lose time going back-and-forth over Slack/Teams to understand the context. Linking technical glossary terms to tables and dashboards reduces dependency and enables them to make faster decisions.

4. 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.

Below we have summarised the framework for how different glossary types differ.


If you want to read more, a detailed article is up on the Community: Link

Next week, we will deep dive into best practices for setting up a glossary. In the meantime, if you have any questions or would like to discuss this further, do let me know! Would love to chat during office hours.

Speak soon,


P.S. The purpose of these emails is to share learnings and best practices to empower our community of DataOps Leaders. All the previous editions of these weekly digests can be found on our community website. Though we have put a lot of thought into curating the most relevant content, if you do not wish to have access to this, you can choose to opt-out by emailing me here: opt-out