How can I deal with my coworkers using unknown jargon and acronyms?

Question

I'm exactly 1 month into a new job. I really like all my coworkers and we have lots of great conversations outside of work settings, easily the best manager I've ever had and the workplace is pretty nice. But when anyone's talking about work they use terms I've never heard of and I never know how to respond.

Here's an sentence I heard today, I've bolded the words I don't know:

"I've called this meeting to establish a buy-in for the LSC to cover BNN's usecase."

No one else ever seems confused by any of this. Any time I ask a question like "What does use-case mean?" I get a response that doesn't answer it like:

"It's defined in MOP #8132's BNA"

"Where can I find MOP #8132?"

"It'll be in your PLR. Now we have to get on with the meeting.".

I've had to do this around 8 times a day every day I've worked here and I still have no idea what anyone's ever talking about. It's a startup of around 30 people so I don't know why it's so corporate-sounding.

I know everyone here knows how to speak normally. No one ever uses acronyms to describe their weekend. How can I politely ask people to stop using these terms with me?

Answer 1

Though many answers are rightfully telling you that the use of jargon and acronyms is normal, it should be noted that their use is not universally appreciated. Elon Musk famously dislikes acronyms, and has even instructed employees at SpaceX to use as few acronyms and jargon as possible.

Despite the majority of people telling you that you should learn to deal with the jargon, there are are in fact people whose opinions matter who feel as you do. If that gives you consolation, then let that consolation be your way of dealing with the flood of jargon that you will endure. Finding one's consolation and "dealing with it" is actually a terrific life lesson.

Answer 2

While "usecase" is a general term, it's normal to take more than one month to learn company specific and industry specific jargon and acronyms.

Equally, after just one month, your coworkers should consider it normal for you to still be getting your feet wet and they should be willing to explain acronyms and other concepts specific to the company and industry.

So do not ask your coworkers to stop speaking in acronyms. Ask them to clarify their acronyms for you. Then write down the definitions so you can remember.

Answer 3

Step #1

Change your frame of mind.

"How can I politely ask my coworkers to speak normally?" is quite accusatory and I'm sure no one in the office will enjoy being criticized by the new guy that doesn't understand the acronyms.

However, if the entire meeting was held in Klingon and your company is in no way related to the usage nor development of the language then you would have a strong case for requesting that your coworkers speak normally.

Step #2

When you encounter acronyms, take the time to write them down. It is unwise to stop someone 8 times during 30 seconds of speech especially if it is in a group setting.

If the meeting topic is a project which you are involved in or responsible for then make sure to take extra good notes that you can translate later. Chances are that even if someone told you what "PLR" stands for, you still won't know what it means, what it's used for, nor where to find it. These are all things which you should be actively seeking the answer to during your working hours.

If you are talking one on one with someone then you can humbly ask for each acronym's definition if the speaker doesn't seem too annoyed or flat out let them know that you're having trouble with acronyms.

Step #3

If you've been writing down acronyms then find someone you trust during some down time and ask if they can explain the acronyms you've written down. If they introduce a new acronym then add it to the end of your list.

---

Acronyms are a part of all businesses. Many of them are esoteric within a specific company but stuff like "buy-in" and "use-case" are easily Google-able.

Not sure what industry you are in but 0.28 minutes of Googling reveals that MOP seems to be a Maintenance Operation Protocol.

If I had to guess then you will probably find many more acronyms along with their definitions spread across the MOPs so you should definitely seek out these documents.

Quite frankly if you don't know what an MOP is during one meeting and still don't know during the next meeting then you are the issue, not the acronym.

Answer 4

Jargon is an important communication tool both for speeding up communication and making it more precise. I do not think it would be useful, or even possible, to constrain your colleagues to using only standard English for work discussions.

The first thing to do with any unfamiliar term or abbreviation is to feed it to your favorite search engine and Wikipedia. That will work for industry terms like "use case". You may be able to do that in a meeting without stopping the meeting flow.

Doing so will reduce the questions you have to ask. Only ask in the meeting if really necessary, if not knowing the word is preventing you from following something you need to understand. Otherwise, write it down and ask someone afterwards.

Answer 5

Use this experience to make your company's onboarding better

1. When you hear or see people using acronyms or terms you don't know, write them down. Keep a notebook with you with a page dedicated to this.

2. At your weekly one on one with your supervisor, ask about the new terms you've encountered that week. If you don't have a weekly one on one with your supervisor, ask for one--you especially need one as a new employee who's unfamiliar with the industry.

3. Note the definition for each term, and expand on them if you need to later.

4. At the end of six months, put together a document with the terms and definitions. Recommend that HR give this to all new employees. If these terms were new to you when you started, they're going to be new to other new hires.

This is slightly similar to @MonkeyZeus's answer, but in a different direction.

Answer 6

You might have a bigger problem than acronyms here. If you think the entire company should stop using technical terms just because you don't understand them, your career in any company is going to be difficult.

Of course, this is assuming you get an answer if you ask, and it does seem that you do. If the answer is not satisfactory, keep asking until you have the information you need to learn. But make sure to find an appropriate time to ask.

Also, if there's a company documentation or wiki, it probably has a search feature. Terms like "usecase", "standup" or "kanban" are also easily googlable. Just enter "what is X in IT" in your favourite search engine.

Answer 7

There is little else to do but have the acronyms explained - either by Googling them later or - if needed - by asking in real-time.

As other answers hint, only ask if their use causes outright confusion; interrupting a meeting just because you are curious could be annoying.

In addition, I'd actively and visibly write down any answers - as people seem to be more willing to explain when they get the feeling that you will only ask once.

Most people have some tolerance towards newcomers asking 'stupid' questions; it's the repeat offenders that get on peoples' nerves.

Answer 8

Multiple people has suggested asking if there's a glossary. There probably isn't if it's that small, but absolutely ask. Then be prepared. If the answer is, "No, we've never needed a glossary. Doesn't everyone know these terms?" offer to start the glossary yourself. Tell your boss, "We're only 30 people now, but we're going to grow, and as we try to incorporate new employees, a glossary will really help. I know that I still feel like you guys are speaking a foreign language at times!"

My company bought another company two years ago and with ~50 employees spread in four states, we didn't have need for a ton of documentation. Then we added a whole new group and we're paying the price. Onboarding documentation is hugely important and often forgotten. We actually deal with a ton of documents from other corporations and we have to read and analyze them, so we rely pretty heavily on https://www.acronymfinder.com/ for a new company we're unfamiliar with. The nice thing about Acronym Finder is that you can dial into the specific industry which narrows your choices down significantly.

Answer 9

There's an old joke about programming:

There are two hard problems in programming: naming things, cache invalidation, and off-by-one errors!

Naming things is the hardest problem in programming.

Jargon is a required aspect of any technical communication. Don't believe those who claim otherwise. Musk rails against acronyms because they are imprecise jargon, and that's fine. But the fact remains, you must learn the jargon, to do your job.

It can be intimidating, but it's required. Just about every one of those terms exists and its use adopted by your group because there was no better alternative.

I worked for... well, it's basically an appstore, which sells "extensions" to a framework. It has a bunch of terms, including these closely-related terms:

• Extension: The product that users buy.
• Archive: A zipfile the developer uploads, containing a single version of the Extension.
• Package: Mostly means the same as Archive.
• Shared Package: a package that's included as a library for other packages.
• MetaPackage: a package that includes shared packages as libraries.
• Version: The zipfile, and its associated metadata.
• Product: Synonym for Extension, used when referring to the Developer Portal, rather than the Store.
• Product Detail: Synonym for Version, used when referring to the Developer Portal, rather than the Store.

Each one of these is a very, very specific thing. Any one of them can be confused with another, and often is. A developer, asking for help uploading their zipfile, might call it any of these, or zipfile, file, software, or more. And Support needs to be prepared for that.

But internally, when I say "is this data part of the Extension?" my colleagues will know exactly what I'm referring to and say "ProductDetails feels a better fit".

They don't need to add "This is data that varies with each uploaded version of the developer's software, and it's data that only DevPortal uses, so it would be better to store it in the Product Details database table." They can say that, to explain their rationale, but it's all implied by our common knowledge of the terms used.

These terms didn't arise by accident.

We sat down, every time there was confusion within the team, and hammered out exactly what we meant by each one. We did our best to pick and define terms that pre-empted confusion. And still we sometimes wrote code that used one term but meant another.

As others have suggested here, we defined them in writing so that people coming to the team could wrap their head around the great swathes of technical, domain-knowledge-dependent language... or jargon.

You need to learn these terms to do your job

If you come to the team, you need to use these terms. There is no point using your own language or terms. That's actively counterproductive.

In another term, we had terms like "sprite", "avatar", "frame", "pose", "species", "character" and "player" - each a distinct layer of abstraction in the display of a character in a game. Despite very carefully defining each term, we had two teams developing two different systems, and when we linked them together, we discovered that both teams' usages hadn't quite lined up...

Naming things is hard. But not doing it at all? Not having a shared technical vocabulary? That way lies craziness.

Answer 10

There is plenty of jargon and acronyms not just in workplaces, actually in all organisations for that matter: at work, in university, in your board game club, or surfing tribe.

You are frustrated at it, as everybody else would. The only sensible thing you can do is to

• happily google the industry-wide ones, as you will need them later in your career

• quietly and patiently ask about your company-specific ones; a gentle way is to ask your colleagues if a glossary exists, and your manager for explanation of the most frequently mentioned.

Jargon and acronyms main official reason to exist are speed and accuracy. However, they fail miserably in both places. The speed intent is promptly nullified by the long learning curve for newcomers to understand organisation-specific jargon. The accuracy too, as jargon often actually introducing imprecision, and provides a comforting cover to hide the lack of full understand of the concept.

Where Jargon and acronyms succeed is in community-building; people speaking an organisation-specific language perceive themselves as serving a common goal. For the same reason, jargon is an explicit barrier for outsiders- “you don’t belong here until you become one of us”. This is why jargon and acronyms are present in any organisation. Rejecting jargon and acronyms would amount to rejecting your organisation culture, ultimately defining yourself as an outsider, doomed to be ousted from the community.

Answer 11

The very simple answer is to take notes during meeting, ask a co-worker later in the day what they mean.

Try remember as many as possible, but don't worry about it, you will pick them up pretty quickly.

More annoying is when company A uses BOM as 'bill of material' you move to company B where it means 'base order model' urrrghhh

One day it will be you using the acronyms, just remember that when working with some one new.

Answer 12

Prepare before the meeting

First, some of the words in your example (buy-in and use case) are not actually technical jargon, just standard business lingo, so they're not specific to a company or industry. Unless this is your first job (but you seem to imply it isn't), your first job where you speak in english, or you were restricted to a very limited technical role in previous jobs, it's surprising you didn't hear them.

In this case,

I've called this meeting to establish a buy-in for the LSC to cover BNN's usecase.

means that the LSC (a department in your company, probably) is doing things a certain way, and BNN (a customer, probably, or possibly a new product/service) has a specific need (use case), so they need to have LSC agree (buy in) to cover this need. Depending on who is in the meeting, the meeting may have people from LSC who are here to understand the new need and accept to cover it (possibly with conditions), or it may be a meeting to decide how this is going to be presented to LSC.

Next, I'd like to add to all the "look it up after the meeting" answers a "look it up before the meeting" answer:

• A meeting should have at least a short blurb to tell you what is going to be discussed. Depending on how formal the meeting is, you may have a detailed agenda, or in some cases full documents to be discussed during the meeting (which could vary from the infamous Powerpoint presentation to the detailed 400-page specifications). Also, you should know in advance who is going to be present at that meeting.

  In this specific case, you should have at the very least been told in advance that the meeting is about "getting buy-in from LSC for BNN's use case", since this is the subject of the meeting. You probably also got a few details about "BNN's use case".

• If you are not provided with any of these in advance, ask for them as soon as you are invited to the meeting. Meeting participants want you to be prepared, and you can't be prepared if you don't know what is going to be discussed and with whom.

• Prepare for the meeting. Read the documents. Look up any term you don't understand. Look up the people who are going to be present in the meeting, what team they are part of, what their job is. Take notes. If needed, either ask questions before the meeting, or prepare a list of questions for the meeting. But do you own research first, you don't want to be asking questions that everybody knows (or thinks) you could easily have found the answer for if you had done your research.

Finally, depending on your role in the meetings, your immediate reaction may vary. If you are asked direct questions, or are assigned tasks, you need to be clear on what you are asked about or what you need to do. So there you should most probably ask when you don't know. In this case, you are probably not in the LSC and not directly involved with BNN, so you probably weren't directly involved.

Otherwise, as others have suggested, take notes. You should takes notes anyway, but you should highlight in your notes (use a special color, or a special section in your notebook) all the things you didn't understand and need to do further research into.

Note that in many cases, the meaning of a term may become clear during the meeting itself as people continue using it and discussing things around it.

Answer 13

In software we have the corresponding terms silent failure and noisy failure.

The former happens when a bit of code does not work, but processing continues as if the code had worked properly, and the user is given no indication that things have gone wrong.

The latter case is when a failure is brought to the user's attention in some way, either by a warning message, complete interruption of work, or whatever.

Anyone working in software will tell you that it is much better for a piece of piece of code to fail in a noisy way than to fail silently. This is because a silent failure can go unnoticed and uncorrected and eventually cause problems that are much worse than noisy failure. Noisy failures tend to be fixed sooner.

As a boss, I would much rather have a meeting interrupted in order to explain something to someone who didn't get the memo, than for just about any alternative. It may be that a decision made while this employee is in a confused state will be the wrong decision, and would have been made correctly if the clarification had been made when it was first needed. Even having the employee wait until after the meeting to get clarification could cause some of the work done in the meeting to be wasted.

There is also the principle that many problems that crop up during the course of business happen because management has failed to do its job.

If my company hired a guy who didn't know some piece of information, it is because we didn't check or didn't care. If we didn't enlighten him during the new employee training, and then put him into a work situation where he needed to know that piece of information, it is our fault, not his. If this disrupts work, it is our fault that work was disrupted, and not his.

When it is your turn to speak, feel free to request clarification of anything you don't understand.

Answer 14

You could try doing what I do:

Learn the jargon, so that you understand it when you hear or see it, then stubbornly refuse to ever use it yourself.

Don't lower yourself to their level!
Speak properly, using full words - real ones, which can be found in real dictionaries (preferably printed on real paper, not your newfangled e-ink (it's not even ink!)) and not Urbandictionary.com or Acronymfinder.com or some such nonsense - and using full sentences, so that everyone understands what you're saying.

People (like the ones who are currently pretending that they understand what all these things mean) will thank you for it. They'll appreciate your drive to use plain simple language. And the next new starters will have a much easier time settling in.

Answer 15

Something I used in the past when thrown into a meeting outside my expertise:

• Use google/wiki on your phone to look up the meaning of jargon/acronyms
• If I can't find them, write them down and after the meeting try to catch a coworker to explain them to you. If possible I would try to catch a meeting participant as that person will already be familiar with the context.

Answer 16

"Hey there, you used the word 'usecase' but I'm not familiar with what it means, can you point me in the right direction?"

You're in a new environment, so you're going to have to rely on your teammates to help you, and you can do that by clearly and politely asking specific clarifying questions, either in the moment, or later once you've written a few of them down as you have done.

I'd be hesitant to ask anything of my new coworkers that I could do myself, in terms of asking them to modify their behaviours.