Knowledge sharing is a core team principle that is most efficiently captured through the practice of documentation. The beauty of documentation is that it closes the feedback loop of continuous gaining, sharing, and updating of knowledge. It's essentially condensing individual expertise into a digestible format and scaling that knowledge across multiple teams. This practice alone transforms tribal knowledge into team knowledge.

The single source of truth

In game development, the most common type of documentation we use is the design document. The design doc is created by the design team and becomes the early foundation on which the engineers reference as their building spec and on which QA begins creating their test plan from. This document gives an overview of the feature and it's goals, as well as, describing at detail how it accomplishes it's goals. It's the master plan of the feature that is both kept perpetually updated and referenced by everyone working on that feature.

Documents exists in all forms and sizes. Anyone can create a document for anything, as long as you identify a need. When deciding whether a document is necessary, you can find the answer by asking these questions:

1. 1. Would this information be useful for others?
   2. How often would someone be asking me about this information?
   3. Is this reusable, scalable information?

If the answer is yes to any of those questions, then often a document could do the trick.

In the QA domain, the glossary is one of the best examples of a type of documentation that becomes an invaluable resource across multiple teams. QA is uniquely positioned for this document since they interact with every facet of development on a daily basis. They often gain a highly nuanced understanding of the entire game.

What is a glossary?

This is a reference document that defines terms that describe various elements of the game or product. It can start as a simple list or spreadsheet of definitions. Which can later be expanded into tables with categories, examples, and visual aids.

Why is it useful?

It's purpose is to create unified language across disciplines through naming. This helps immensely when creating bug tickets, establishing a common, easily understood terminology that lasts throughout the entire project. These terms bring clarity and efficiency not only to bug writing, but also to bug fixing and tracking (See article: Writing Bug Summaries Effectively).

Where do these terms come from?

They come from the designers and engineers themselves. When first joining a project, there's often a lot of terms that you will be unfamiliar to you at first. Over time, you'll naturally begin to pick up these new terms and use them yourself without even noticing. The problem is, many of the terms only exist in the team's verbal vernacular until someone gathers them and enters them into a unified document.

Whats more, we often work in specialized siloes within a single project. Since we're not always familiar with the technical nuances of each others work, knowledge gaps form between team members. The solution to begin bridging those gaps is with shared documentation and in the case of a glossary, the knowledge gap is language.

Language is a foundation which we build communication and a glossary is the structure that strengthens it.

The glossary also scales beautifully to meet your evolving needs. It's adaptable to serve as a basis for onboarding or as a respository for deep technical nuance. You can create a glossary tailored for a single team's workflow or make a broader company-wide version that includes multiple categories or departments.

Let's take this very common scenario:

1. 1. You start the document with your individual knowledge and/or insights from your team
   2. It becomes a living resource that anyone can contribute to and update
   3. Now, whenever anyone has a question on what that "thing" is called, they can check the glossary
   4. If the glossary contains the term, problem solved
   5. If it doesn't, it becomes a finding mission and it becomes a new entry into the glossary
   6. The next time the question arises, Ctrl+V the document link

On top of that, with a team workspace tool like Confluence, every document exists in a structure and becomes easily searchable. It's the gift that keeps on giving but also can be updated, re-gifted, and re-gave (it's a dynamic gift).

It's a time saver

Imagine the first few weeks or months that a new team member experiences during their onboarding period. We've all been through that process and had to ask 100 questions in our first 100 days. With documentation, there is a wealth of knowledge references available to them from day one. Documentation is a big cost saving measure as it reduces the time spent asking many small questions in direct messages.

Documentation is not only about making the invisible, visible, but the known, shared.

There's many knock-on benefits

Beyond the primary benefits that I covered, the possibilities of what can be document are endless. It's essentially journaling in a professional setting. Likewise, the act of writing documentation in itself inherently deepens your own understanding of your work through structured reflection. Ultimately, a documentation mindset is a core component of closing the knowledge feedback loop, with many knock-on benefits to boot. It creates knowledge that is reusable, scalable, and drastically reduces time spent waiting on those replies in Slack.