I am working on product in which I am a newbie, but in my group there are coworkers that know that product deeply in all the details. Those coworkers are busy with high-priority tickets and I am new to the product and I am learning it. I have own small knowledge area in which I am learning the product step-by-step.

I see the need of creating tools for speeding up the development process and I have opportunity to create such tools and learn more about the product. I have often calls with one coworker and he explains me the product but he is very involved to that business area and project and he explains me all that stuff very very deeply, so I don't know many things that he tells me (I am not on his level). I am asking him for short simple questions, but every time he starts explaining one question, he goes very deeply into the topic and it is hard to say stop.

This is quite awkward because I forget 80% of knowledge that he is saying and also my manager told me to not abuse him but let him do his work. We have usually long 3/4 hour calls and he tells me everything about that product and business area. This is problematic also because we work in different time zones, I work from EU and he works from USA. So we should have 4 working hours in common, but sometimes I work 10 hours a day when I have call with him.

So my question is how to tell him to shortly describe things I need to know for my "small" knowledge level, in a polite way, as to be not understood like "I am not interested in what he is explaining to me".

  • 2
    "This is quite awkward because I forget 80% of knowledge that he is saying and also my manager told me to not abuse him but let him do his work." - Are you taking notes?
    – Donald
    Commented Oct 29, 2021 at 14:15
  • 4
    @Donald : in a 45 minutes call without enough basics to understand what is said, notes would not have much value.
    – gazzz0x2z
    Commented Oct 29, 2021 at 14:31
  • 1
    A 30 minute meeting slot wihere you need to be elsewhere afterwards? Can you record your sessions? Commented Oct 29, 2021 at 21:44
  • 2
    @gazzz0x2z Highly disagree. I've taken notes from 5 minute meetings and been grateful for them later. Commented Oct 30, 2021 at 5:57
  • @Donald, yes, every time we have a call I am doing notes, they are not so long but every topic that I understood I am taking notes of this
    – shjeff
    Commented Oct 30, 2021 at 12:36

6 Answers 6


Well, short questions don't necessarily have short answers ... IMHO, it would be best to be clear about this problem upfront, and let them know what's in it for them:

I appreciate the amount of time and effort you usually spend to explain me the details about certain topics, like the last time with [topic X]. However, I also know you are working on many high priority tickets, so a short explanation will suffice for now. Could you help me with some directions how to solve [issue Y]?

This is probably easier than to 'interrupt' them in the middle of their story, which can indeed be hard as you describe.


Consider having this interaction by email, not a phone call.

  • Drafting your questions by email will force you to refine and clarify them.
  • Your coworker can deal with it when they have time and mental clarity for it.
  • Your coworker likely won't want to spend 45 minutes drafting a very long email, and is more likely to give you the brief pointers you're looking for.
  • The coworker may be more likely to give links or references to existing written documentation on the issue.
  • Whatever your coworker shares by email is automatically documented for future reference, and not forgotten.

I am now in your coworker's boots. There are a lot of new developers on the team and the lead is making me introduce them to the product/tool-chain/environment.

So it's really hard for me to mention ten new things and keep saying "we'll talk about this later" or "you don't need to know this right now". As I don't want to seem exclusive or hold back on information.

What you can do, is ask for a clean and easy feature or part of the product to read the code and try to understand it and then start reading more and more of the code to understand how it all fits together. You can say it's an opportunity to see how well you can understand their code and their 'developing approach' and it's an opportunity for the 'old guard' to have a set of new eyes on the code that might give insights into the readability and the maintainability of the code.

You can ask specific and targeted questions about one functionality in particular. Like: "How is a new FOO inserted into the database in the BAR module?", or "what do I need to understand to know how the 'whatever' module works?"

By asking to read a sample of the code you are showing that you are willing to learn and by asking specific and targeted questions you show that you actually learned. This makes the coworker more relaxed knowing that they don't have to hold your hand every step of the way. Because they will see you as their protege and they will feel responsible for your mistakes or performance even if it has nothing to do with them.


So my question is how to tell him to shortly describe things I need to know for my "small" knowledge level, in a polite way, as to be not understood like "I am not interested in what he is explaining to me".

Schedule short phone calls.

Set up times specifically for training sessions. Keep them to 15 minutes. Then, once the 15 minutes is over, end the session and move on to other work.

Take good notes, so you won't keep forgetting 80% of what you heard. Follow up with emails to clarify whatever parts you didn't understand, and then update your notes.

  • I like this approach and will try that, but I need somehow to convince him to end up the meeting earlier
    – shjeff
    Commented Oct 30, 2021 at 12:46
  • 2
    Shedule the right before some other meeting you have so that you HAVE to say. Sorry my other meeting starts now, I have to go.
    – lijat
    Commented Oct 30, 2021 at 18:53

Before asking the question, decide on a few Action Items that you want to take away from the meeting. These are things that you could actively work on as a result of asking the question. Then, anytime they head off towards the lecture, focus back in on the action item in question and don't let them stray too far off:

Hi x, I'm working on streamlining our deployment process and I noticed there's this step that doesn't seem to do anything. I would like to delete it, is that okay?

Well actually, the deployment process is made of 35 steps and at the start we do x on this microservice, which is made to ....

I'm sorry, in the interest in not wasting your time, I'm really just focusing in on this one particular step. Based on the git blame, the last time it was touched was 5 years ago, and the functions don't seem to do anything anymore.

Umm, yeah looking at it, it doesn't seem to be used anymore. Try commenting it out, running the deployment, and make sure everything works. Then delete it.


"Awesome! Hey, I feel like I'm a bit overloaded with such good information at the moment. Can be stop there so I can work with what you have told me so far? It will help me to work with it a little more on my own. That way I can ask better questions in the future or better understand the details you know and want to teach me."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .