How to ask for less project jargon on meetings and task assignment?

Question

I've started a new ongoing project where the team members developed for some time. Most of them are having less overall experience than me. The issue comes with the conversation and tasks assignment. They are using a jargon they developed during the project that is completely obscure for an outsider.

Check what users see

for example, means:

Log into database X, with user A, check permissions for tables Y and Z and then double check with user B.

I have to ask questions for A, B, X, Y, Z because I not familiar with the project domain and documentation is missing - things are changing too fast.

I'm bringing experience here because of some untold premise among project's managers that experienced people are not asking many questions.

How can I ask for more detailed explanations and also keep questions relevant?

Answer 1

You can't ask only relevant questions if the details are lacking, since you simply can't understand everything to only be asking relevant questions. Ask what you don't understand, even if it means asking tons of clarification questions that feel annoying to the developers. Explain why you're asking all the questions. Then write it down and build the documentation that is now lacking so the next person that joins the team doesn't have these issues. Discuss with higher-ups to make this mandatory from the conception of new projects.

Answer 2

If you are joining an already ongoing project, there won't be be a way around learning the jargon. Don't be afraid to ask questions. But make sure that you note down what is explained, to prevent you asking the same question multiple times.

EDITED I misread your question. First I thought with "Jargon" you mean technical talk. It seems the opposite is true, your project peers use abbreviations.

If everyone but you always understands what that shorthand phrases mean, you'll have problems changing that. If you notice that those abbreviations cause misunderstandings, insist on exact communication.

Unrelated to that, insist on proper documentation. No doc "because the project changes too fast" is no excuse. Ideally you write documentation first, code second. Chances are high you won't be the last employee joining the project, so every effort made for documentation is worth it in the long run.

Often the best doc is written by the newest team member, because all others already started longer ago and don't remember the problems they had. So you seem to be in the best position to change the lack of proper doc.

Answer 3

Log into database X, with user A, check permissions for tables Y and Z and then double check with user B.

Those terms are not jargon. They're identifiers

Identifiers are paramount.

If I tell you to log into the database of customers for instance, chances are likely there are several databases used for customers. And accessing the wrong database for your tasks, when you were meant to access another one, could lead to disastrous consequences.

No, you need to keep notes, draw diagrams/mind maps, ask lots questions, and then use spaced repetition to make sure you remember what those identifiers mean.

In some cases, and once you're familiar with the system, you may be able to suggest names that make more sense. But until then, you should tread lightly.

Answer 4

You don't

Project jargon develops because it's practical and less ambiguous than standard terms. You're probably missing the context.

• Me: "What does X. mean?"
• They: "It's a <insert project related details>."
• Me: "Oh okay, so it's xyz."
• They: "No, Bob's team is working on xyz."

It might be that the simple term

• has a special meaning in the company (e.g. the previous deprecated solution for the same problem)
• is not clear enough because it has different meanings in different context
• is used only for the general concept but not for the implementation to avoid confusion
• is too long or complicated for quick chats

So better get used to it.

Besides that it seems that you're missing documentation, which explains that special terminology. That's something you should fix.