The Words We Wreck: Why UK Teams Need a Shared Dictionary Before Another App

Buying another collaboration app will not fix your team's vocabulary. If anything, it will add more places for the same fuzzy words to hide. UK teams are famously polite, which is lovely until someone says 'could we have a quick review?' and three people interpret it three ways. The result is not a software problem. It is a language problem with a software bill attached.

The expensive words

Every team has them. The words that sound clear until you ask what they mean.

• Done. Merged? Deployed? Client-approved? Or 'I have finished my bit and assumed someone else will do the rest'?
• Review. Read for typos? Check the logic? Give strategic feedback? Sign it off legally?
• Quick call. Five minutes? Fifteen? A 40-minute therapy session disguised as a catch-up?
• ASAP. Today? This week? Before the end of the hour? And who decides?
• Blocked. Waiting on a named decision, or just finding it a bit difficult?
• Sign-off. From the client, the legal team, the finance director, or the person who happened to be in the room?
• EOD. End of whose day, in which timezone, and does that include the 5:45pm message that arrives just as you close the laptop?
• FYI. Read this for information, or read this and do something about it?

These words are not jargon. They are work. And when they are fuzzy, the cost shows up as missed deadlines, repeated pings, meeting creep, and the particular British passive-aggression of a thread that says 'just checking in on this' for the third time.

Why a glossary beats another integration

Apps encode workflows. They do not encode meaning. You can connect your task board to your chat tool and your document store, and still have a team that disagrees about what 'done' looks like. A shared glossary is cheaper than a new subscription and more effective than another meeting about ways of working.

It is not a corporate dictionary. It is a one-page contract. Short, living, and specific to the way your team actually talks.

Here is what a few entries might look like:

• Done: The task meets the agreed acceptance criteria and the output is in the shared folder. Unless explicitly stated, it is not client-approved.
• Quick call: 15 minutes maximum, with an agenda in the invite. No agenda means an async message first.
• Review: A first pass for sense within two working days. It is not a line edit unless the request says so.
• ASAP: Within one working day. If it is genuinely immediate, ring the person and explain why.
• Blocked: Cannot progress without a named person or decision. Add it to the handover note.
• FYI: No action required. If action is required, say what and by when.

That is the whole idea. Clear enough to use, short enough to read, specific enough to settle an argument before it starts.

The 45-minute glossary workshop

Do not write this alone and send it out like a policy. Build it with the team, then keep it alive. Here is a format that works in Kula.

Before

the session

Collect the words. Spend ten minutes scrolling the last two weeks of chat, tickets, meeting invites, and handover notes. Ask everyone to nominate three phrases that cause friction. You will get overlap. That overlap is your shortlist.

During

the session

1. Five minutes: set the frame. This is not a dictionary for outsiders. It is a decision about how we work together. The goal is fewer guesses, not perfect language.
2. Ten minutes: cluster and choose. Group the nominated words. Pick six high-friction terms. Do not try to define everything. You can add more later.
3. Twenty minutes: define each one. For every word, write a plain-English definition, one example, one anti-example, and an owner. The anti-example matters. It shows where the word stops.
4. Five minutes: agree a review date. Monthly or quarterly. Put it in the calendar now.
5. Five minutes: publish and pin. Put the glossary where people work, not in a folder nobody opens.

After

the session

Add the glossary to onboarding. Link it from meeting note templates and task descriptions. Use the definitions in your status labels. If your team says 'in review', make sure the board means the same thing as the glossary. Otherwise you have created a document and not a habit.

Make it stick in Kula

Create a 'Team Glossary' page in Kula. Use a simple table: Word, What we mean, Example, Not this, Owner. Pin it to your team space. Link it from your new starter checklist. Add a line to your weekly team note: 'New word to define?' Let people nominate terms in comments. Review it in the monthly retro, not in a quarterly panic.

Keep it to one page. If it grows into a handbook, split it by team or by workflow. A glossary that takes ten minutes to read is already too long. The test is simple: can someone join a thread, see the word 'done', and know what to do next? If yes, it is working.

And do not let it become a weapon. The glossary is a clarity tool, not a compliance document. If someone says 'ASAP', a gentle 'which definition are we using?' is better than a policy citation. The point is to reduce friction, not to win the argument about whether 'quick call' should be hyphenated.

The bigger point

Software cannot fix a team that has not agreed what 'done' means. A new app will just give the confusion a nicer interface. Before you buy, define. Then buy only if the definition still needs a tool. For UK teams, this matters more than we like to admit. Politeness can hide ambiguity, and ambiguity is expensive. Being clear is kind. A shared glossary is a small productivity habit with outsized returns.