How to build a shared glossary of project terms

New clients and new hires both hit the same wall, internal shorthand, tool names, process terms, that everyone already on the team uses fluently and nobody ever actually wrote down. Each person independently spends real time figuring it out through context, or worse, quietly nods along without fully understanding.

A shared glossary doesn't need to be exhaustive. It needs to capture the specific terms that come up constantly and were never actually explained.

New clients and new hires both spend real time decoding the same shorthand

The same handful of internal terms confuse nearly everyone new, client or hire, and without a shared reference, each person burns time figuring it out independently instead of just being told once, clearly, in a document.

Write each definition in plain language, not more internal jargon

A glossary that defines one piece of jargon using another piece of jargon doesn't actually help. Write each definition the way you'd explain it out loud to someone who's never heard the term before.

Include the terms that feel too obvious to define, since those cause the most confusion

The terms that feel too basic to bother explaining are often exactly the ones causing quiet confusion, since everyone assumes they're universally understood. Include those too, not just the genuinely technical or unusual terms.

Keep it close to where people actually work, not a separate onboarding document

A glossary buried in an onboarding packet gets read once and forgotten. Keep it somewhere people naturally return to during actual work, so it functions as a living reference, not a one-time onboarding artifact.

Update it as real terminology actually changes, not frozen at first draft

Internal terminology shifts over time, new tools, new process names, and a glossary frozen at its first draft quietly goes stale. Revisit it periodically against what's actually being said now, not what was true when it was written.

A simple checklist

If you do nothing else, do these five things:

• Write definitions in plain language, not more internal jargon.
• Include the terms that feel too obvious to bother defining.
• Keep it close to where people actually do their work.
• Update it as real terminology changes, not frozen at first draft.
• Build it from the actual questions new people ask, not a guessed list.

Do that, and new clients and new hires stop independently spending time decoding the same shorthand everyone else already understands.