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?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Dec 1, 2019 at 15:23

16 Answers 16


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.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Nov 29, 2019 at 18:39
  • 21
    So what's the answer? What action should be taken? As a native English speaker I'm having trouble understanding your bold closing sentence. Please edit to clarify. Commented Nov 30, 2019 at 7:31
  • @Z.Cochrane: I've changed the emphasized sentence to the sentence that includes the point of the answer. You are correct, the answer is a bit clearer this way. Thank you.
    – dotancohen
    Commented Nov 30, 2019 at 13:51

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.

  • 13
    Indeed, and rather than cluttering up the group communication better to just catch some regular participant or someone you are friendly with at the side and ask for explanation of an unfamiliar term. Commented Nov 27, 2019 at 4:06
  • 201
    Don't just write them down for yourself... start a Wiki or document that can be shared with new starters to help them ramp up more quickly on the industry terms. If your company has a starter pack or induction process it could be included in this.
    – amcdermott
    Commented Nov 27, 2019 at 9:21
  • 52
    Also, don't ask in a meeting unless mandatory. I've your not playing an important role in the meeting, write the terms down and ask afterwards when your teammates can give you proper attention.
    – Bernat
    Commented Nov 27, 2019 at 12:46
  • 16
    When Muhammad insists the mountain come to him, and not vice versa, Muhammad should take a second to reconsider. This applies doubly for those who are not historical/ficticious characters...
    – Stian
    Commented Nov 27, 2019 at 14:12
  • 15
    There's a slackbot at my company for help with this -- type /? <acronym>, and it returns a definition, or the option to write your own. Fairly simple to build, and incredibly useful for everyone.
    – Itinerati
    Commented Nov 27, 2019 at 16:35

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.

  • 9
    To add, a quick Google also returns BNN = Bloomberg, LSC is most likely Logistics and Supply Chain (in this scenario), BNA could be British North America (Canada), Business Network Alliance (referring to the section within the MOP). So the likely meaning of the first phrase in the question is: "We need to get Logistics and Supply to provide input regarding Bloomberg's requirements for the product/service".
    – Aaron
    Commented Nov 27, 2019 at 23:24
  • 3
    That last paragraph is the key, really. Nobody's born knowing English terms. You learn them. That's your responsibility. Commented Nov 29, 2019 at 1:00

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.

  • 7
    I would argue that jargon does nothing for precision
    – Strawberry
    Commented Nov 27, 2019 at 14:11
  • 22
    @Strawberry Jargon can help with precision, too. I've had situations where there were 2-3 words that I though were relatively interchangeable, but found out that while similar, they had very delineated meanings. That way, when someone says "foobar" they mean that very specific thing, and not "foo" or "bar" which for someone less familiar, could think that the other terms could have been used instead. For those familiar with the jargon, it allows for single-word specificity, for which you would have to compromise on either the exactness or the brevity of the phrase to replace it. Commented Nov 27, 2019 at 15:52
  • 36
    @Strawberry Jargon does nothing for precision? "Pull throttle to idle and neutralize the ailerons" is a lot more precise than "pull the little stick out and put the big stick in the middle." It's possible to be as precise as the first sentence without using jargon, but it'd require a lot more words. Commented Nov 27, 2019 at 19:17
  • 3
    @Strawberry confused - what are you arguing for now?
    – Solar Mike
    Commented Nov 28, 2019 at 5:06
  • 3
    @GreenstoneWalker That's an example of an abbreviation (initialism) which can be jargon or just regular abbreviation (for example most wouldn't call UN or CNN or US jargon). Jargon is trade specific words, not necessarily abbreviations, that means something specific in trade specific contexts. Examples of jargon include: throttle (no, it does not mean to choke someone), aileron, alibi, current (no it does not mean flow of water), cache (no, it does not mean hidden treasure) and onboarding
    – slebetman
    Commented Nov 29, 2019 at 7:53

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.

  • 5
    This. Acronyms are fairly normal, as are the issues of not knowing them when you're new. Easy solution.
    – Martijn
    Commented Nov 27, 2019 at 15:45
  • 2
    I started writing a glossary when I began a new job at a startup, and shared it with later new-hires through until the startup was acquired by a big corporate. Some thanked me, some submitted corrections. Noone ever said it was bad.
    – Criggie
    Commented Nov 28, 2019 at 9:02
  • 1
    As a native British English speaker, I had to look up "onboarding"! It's what is known as induction outside the USA. Commented Nov 28, 2019 at 18:53
  • It appears that the company already have such documents: "It's defined in MOP #8132's BNA" but perhaps no introductory/onboarding document to tell newbies where to find everything. When I was at Nokia-Siemens they gave me a sheet of paper with a list of URLs for most things I need to know.
    – slebetman
    Commented Nov 29, 2019 at 7:56
  • @AndrewMorton It depends on the context. Onboarding employees means introduction/orientation while onboarding customers means setting up their account and integrating with their system
    – slebetman
    Commented Nov 29, 2019 at 7:58

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.

  • 3
    Good point on using the search feature of an internal portal/wiki. You may not find a complete definition but finding the acronym in different contexts helps a lot to understand or confirm its meaning.
    – zakinster
    Commented Nov 28, 2019 at 8:33

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.

  • Upvoted for the recommendation to search for the answers online. 50% of the jargon in the first example are common enough terms that a quick search will reveal the answers. For the others, I agree not interrupting the meeting is the way to go - instead, make a note of anything that's confusing and ask someone outside of the meeting when there is more time. The problem with them stopping to explain in a meeting is that it wastes the time of everyone at the meeting who does understand, so instead remove that issue and people will be more willing to help.
    – delinear
    Commented Nov 27, 2019 at 8:40
  • 6
    I'm sure workplaces differ, but Google would be absolutely useless for decoding the vast majority of any of our internal acronyms or jargon. Asking a coworker is always the fastest, best, and easiest way.
    – J...
    Commented Nov 27, 2019 at 14:58
  • Don't Google acronyms (obvious exception - being at Google itself and searching inside) - there is very good chance that meaning is different in every company (and if company big enough even between different parts of the company). At very least confirm each definition you found online with someone who works in the same group as you ... Commented Nov 28, 2019 at 5:24
  • Context helps too. "I've called this meeting to establish a buy-in for the LSC to cover BNN's usecase." says that BNN is a user or customer, and LSC is a thing that does something for the customer. The meeting is to find a way to help BNN learn they need/want the LSC item/service. So this simplifies the unknowns to exactly what is LSC and who is BNN.
    – Criggie
    Commented Nov 28, 2019 at 9:05
  • Also, an honest and straightfoward "I'm new here, what is LSC ?" can get OP a brief and succinct answer immediately. Trick is not to ask the same person all the time, and to remember/write down the answer, not ask the same question again.
    – Criggie
    Commented Nov 28, 2019 at 9:07

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.

  • 2
    This is just what I was thinking. OP should wander around everywhere with a notebook (I mean dead tree, not a laptop), and write down every initialism they hear. Once they've found out the meaning of each initialism, document them all somewhere, and publish it as the "initialism guide for new recruits". The next new employee will be very grateful. Commented Nov 27, 2019 at 23:32

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.


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.


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.


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.


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.


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.

  • 1
    I've often wondered if this overuse of acronyms in SERIOUS BUSINESS speech depends a lot on the sector? When I worked in advertising I found they really loved to come out with some utter rubbish, that I haven't seen to the same extent in other industries.
    – Aaron F
    Commented Nov 27, 2019 at 20:12
  • 5
    Refusal to use shortcut terminology is not always practical. If the proper name of a commonly used type of document in your business is "Predicated Plan Predictions Document", you will quickly find yourself tongue-tied and your listeners annoyed if you have to say this more than once in a conversation. It's going to become some variant of "PPP", "PPPD", or "Triple-P" in common conversation, or people will likely find some excuse to banish you as being difficult to communicate with.
    – Forbin
    Commented Nov 27, 2019 at 20:50
  • 2
    @Forbin hah! :-D in any place I work, it'll quickly become commonly known throughout the department as "that blasted document we have to do every bloody month". Although being banished does sound appealing, letting me work in peace and quiet and all that, but I would probably find some excuse to come back and grumble at people every now and then anyway.
    – Aaron F
    Commented Nov 27, 2019 at 21:48
  • 2
    I must say I also do this. I find too much jargon puts people in an exclusive (rather than inclusive) mindset and gets people stuck in fixed patterns of thinking. I think there are several good reasons to make exceptions, such as when natural language is insufficient to express concepts, or imprecise, or when the terms are impractically long/frequent.
    – Artelius
    Commented Nov 27, 2019 at 23:36

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.

"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.

You must log in to answer this question.