Do you speak the same language as the rest of your team?

A shared, common language is essential for open teams of all sizes. It's time to codify your vocabulary.
Register or Login to like
Publisher's picks: Top 2016 open source books

A common, shared vocabulary is at the the heart of data quality and data management initiatives, not to mention effective team communication. On top of that, however, an explicit and common language also critical for maintaining a community-centered organizational culture. According to the Open Organization Definition, in the most successful open organizations, "people have a common language and work together to ensure that ideas do not get 'lost in translation,' and they are comfortable sharing their knowledge and stories to further the group's work."

Recently, our team needed to codify the vocabulary that forms the foundation of both our business practices and our operating culture. So we agreed to create a business glossary—one of the most challenging documents an organization can develop.

Here's how we did it the open way.

Know the lingo

A "business glossary"—sometimes referred to as a "data glossary"—is a document that clearly articulates and contextualizes common and important business terms and links readers to additional information assets (e.g., reports). Most commonly, a business glossary presents a list of terms, what those terms mean in a particular business context, and which systems and processes actually use or rely on the term. People often confuse a "data glossary" with a "data dictionary," which also defines data elements, their meanings, and their allowable values. Data dictionaries, however, are a bit more technical in nature. They formally document data (and metadata)—the structure and a description of tables and columns, relations, and constraints. Data dictionaries are  designed for developers, product owners, and reporting teams; a data glossary is designed for the entire business.

When tasked with creating a business glossary, our team intentionally chose to follow the Open Decision Framework.

The Open Decision Framework recommends that a project's problem statement is transparent. Multiple teams and stakeholders had requested a business glossary, so we knew the problem was obvious to many parties: We lacked clear and standard definitions of commonly used business terms.

So we chose to present the problem to our Data Governance Councils, the teams responsible for maintaining data integrity, security, and quality. Council members are from all areas of the business and all geographical regions. They represent a broad picture of all organizational data (customer, partner, product, and transaction) and its usage.

The principal idea was to foster meritocracy in determining the final definition for each term. When the group stalled and was unable to reach a final decision, the decision maker stepped in to help guide them to a workable solution.

Members volunteered to join a work group specifically to focus on a predetermined list of terms. Decisions makers leading the project moderated the groups, monitoring meetings, documenting terms and definitions, but allowing conversation to flow freely.

The principal idea was to foster meritocracy in determining the final definition for each term. When the group stalled and was unable to reach a final decision, the decision maker stepped in to help guide them to a workable solution.

After the work groups had completed their task and provided the terms and definitions to decision makers, a group of decision makers met to review the work. Together they developed clear, concise rules the definitions should follow (outlined in Figure 1). This provided guidance as they reviewed and edited the definitions.

Business Glossary Rules

Figure 1


One of the primary principles of the Open Decision Framework is to release often, so decision makers chose to pause when they reached 75 terms and definitions, which represented a first release. They then sent a list of those terms to the data owner for review and approval. As expected, the data owner requested changes and posed challenges. So the decision makers met multiple subsequent times to resolve conflicts, edit the terms again (and again), then (finally) present a list of terms for publishing.

Finally, decision makers shared the list of terms (now close to 100 in all) back to the work groups for approval, then to the larger council. Once all groups had signed off on the contents of the glossary, the team created a centralized location for the glossary, published it, and announced it to the organization at large. The plan is to release more terms each month until the glossary is complete.

But that's not all! The team has also provided an opportunity for open feedback from anyone who uses the glossary. They expect changes and challenges, but, having used the Open Decision Framework to develop the glossary, they're confident they can meet the challenges in a collaborative and transparent way.

Using the Open Decision Framework helped the stakeholders to see that:

  • Project decisions align with the team's overall strategy.
  • There was visibility into the research, review, and evaluation processes.
  • The decision making process was inclusive, involving multiple parties.
  • The decision makers agree with the strategy and culture of the organization.
  • All voices were heard and valued.

Creating a business glossary is challenging—but using this open process led to great success for our team.

Subscribe to our weekly newsletter to learn more about open organizations.

User profile image.
Tracy is a Senior Community Architect in the Open Source Program Office (OSPO) at Red Hat. She focuses on enablement and training and evangelizing the power of community. She is passionate about bringing business and technology together in creative ways to encourage full-circle feedback, transparency, and open communication.


In between the lines I sense a bit of obsessive policing, where one may be seen to "violate" the business glossary, which to some extent could lead to loss of creativity. When I look at some technical document or article, I have no objection to use of technical terms as long as their use is an efficient way of communicating. Trouble happens when a term is used which can have different meanings or contextual uses; it's especially bad when a technical term has been adopted from general usage for some skewed purpose. Technical terms with specific connotations should be defined or described when first used, then when used later should have reference to a footnote. Some terms are fairly specific and rigid, others less so and can shift meaning over time as new usages pop up.

Greg - Thank you for the comment on the article! I completely agree that technical terms should be defined in the document where they are first introduced and referenced. The terms that we are adding to the glossary are terms that traditionally have met different things to different parts of the business (for example, customer, account). Many of these terms are not technical terms, but rather business terms. In my experience, it seems that technical terms are often used more consistently.

In reply to by Greg P

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Leaders Manual

The nature of work is changing. So the way we lead must change with it.