Triple your team's productivity with a glossary

Early in my career, I had one fix for every problem on a team: more words.

Somebody felt misunderstood? More writing. A decision wasn't landing? More talking. Two people saw the same project differently? Let's get everyone in a room – another meeting. I genuinely believed that if communication was the problem, more communication was the answer. It mostly made things worse, because spending more time saying the wrong words doesn't get you anywhere. You just make more of them to untangle later.

Here's what I wish someone had told me: the goal was never more communication. It was getting the team speaking the same language. And that's a much smaller, much more deliberate piece of work than it sounds.

Most teams are quietly speaking different languages

Watch a team closely and you'll notice that a lot of the friction isn't disagreement – it's interpretation. One person says "done" and means the code is written. Another hears "done" and assumes it's tested, reviewed, and shipped. Neither of them is wrong. They're just running different dictionaries and don't know it yet.

That gap is expensive, and it's not a new discovery. Fred Brooks wrote about it back in 1975 in The Mythical Man-Month: most of the time an organization loses gets lost in the communication between people and teams, not in the work itself. Adding people doesn't fix it. Adding meetings doesn't fix it. The words are where the time leaks out.

You already know how to do this

The fix is almost boringly simple: write down what your words mean.

If you build software, you've already done a version of it. A definition of done is exactly this – a small, shared agreement about what has to be true before a piece of work counts as finished and moves to the next hand. Acceptance criteria are the same move. You're not writing prose; you're building a glossary, one term at a time, until everyone reaching for the same word is reaching for the same meaning.

So you know how to do it. You just do it for the software and not for the team. Point that same skill at the words your people lean on every day – "ready," "blocked," "launched," "supported," "good enough" – and write down what each one actually means here, in your shop. Get your own team aligned first. Then carry it across the boundary to the next team, and the one after that, until "shipped" means the same thing in engineering, support, and sales.

Why this comes first

Everyone wants to talk about velocity, tooling, headcount, the next process framework. Shared language is the thing that has to come before any of that pays off. Skip it and every one of those investments leaks back out through the interpretation gaps. Do it first and the rest starts to compound.

I've watched this play out enough times to stop being surprised by it. Every time I've walked into a business and done the unglamorous work – figuring out what people actually mean when they speak, then helping them mean the same things to each other – the team's productivity roughly triples. Not because anyone started working harder. Because they stopped bleeding hours into quiet misunderstanding.

Something to try this week

Pick the five words your team says most and can't function without. Ask three different people, separately, what each one means. Write down what you hear.

If the answers match, you've got a shared language, and you can build on it. If they don't – and they usually don't – you've just found where your team is losing its time, and you didn't need a single extra meeting to see it.

It does come down to communication. Just not more of it. The right words, not more words.

– Matthew