It’s easy to miss the importance of terminology, especially in siloed environments. This can lead to disagreements between teams and potentially wasted resources as incorrect solutions are developed.
Recently I encountered a situation where three different teams used the same term for three different items. The confusion created by this was significant when the teams tried to integrate into a single product. The particular case I’m thinking of was the term “feature flags”; it was used by one team as a setting to enable a feature across the product, by another team as an account level setting, and by the third team as a user level setting. The meeting in which the disparity between terms became evident was effectively wasted time as all off the teams left the meeting more confused than when they arrived. Ultimately all the teams were encouraged to update their terminology to differentiate between “feature toggles”, “account features” and “user permissions”.
This situation demonstrated to me the importance of using the correct terminology, acknowledging and working around cross-domain differences in terminology and avoiding potentially ambiguous terms.
Also part of this issue is the barrier that can be created by terminology (or jargon if you prefer). This is extremely evident in the information technology industry. A great example of this is when I hear someone say “Just put it on a USB”; those in tech know that USB is a bus (yes, I know that’s jargon, but it’s just an example, so I won’t explain), but the name “USB flash drive” was too complex or long for non-technical people to use in daily communication, “thumb drive” was used for a while, as was “USB stick”. Now think about trying to communicate with a non-technical person about a limitation of USB; they’re going to be thinking you mean a storage solution, when you’re actually talking about inter-device communications.
Now that we’re aware of the basic problem, how can we solve it?
The first (and hardest) step is to look at the situation from the other party’s point of view. How good is their domain knowledge? Could the terminology have a different meaning in their domain? If we recognise that there could be a terminology conflict, we need to find a better way to reference and differentiate between the conflicted items; often the best solution is the simplest, talk to the other people involved and agree of standardised terms, even if that means adding a qualifier to the terms.
Once you’re comfortable negotiating terminology when the need rises, the next step is to take steps to avoid the conflict from occurring in the first place. To do this you need to be conscious of the use of jargon, and identify the potential conflicts before the term is adopted. This may mean looking at systems and roles you will potentially interact with, and taking steps to avoid the conflict before you use a term. This step will require additional effort with no immediate benefit, but in the longer term it will be invaluable. To action this you may find you need to search acronyms on the Internet or talk to people in the domain you’re likely to interact with.
In some cases it just isn’t possible to avoid a terminology conflict. Terminology is often dictated from external sources. When this occurs you need to ensure there is clarity around the use of conflicting terms, this may mean using a full term instead of an acronym, or may just require a qualifier to ensure all parties are aware of the meaning.
So, to summarise this, when you’re using jargon ensure that everyone understand the meaning, and try to actively avoid terms that conflict with terms in other domains, yes I’m looking at you “Business Development Service Management” people!