Big companies have multiple teams across. There will be a team just for the login, a team for backend logic, etc. There are so many teams and microservices and internal jargon all around.
Problem is during team meeting, seniors have more in depth discussion where I'm unable to provide value as good as them.
How do I get familiar with them fast? Or am I focusing on the wrong idea and should just narrow down what I'm working on and just let time do its thing?
So being at a similar big company I had the same problem because I wanted to learn everything and never shared my troubles with the people around me. When I started to do that, I gained more leverage and I started to understand who can do what and how to not be a mess navigating the political side of work. Show interest, take charge, ask people how they would approach a problem if you're unsure, help others with their problems that you've overcome before, go where you want and build the skills you know will make an impact in your career. Pay attention to delineations, maybe you reach out and make a mistake, maybe a whole team is offboarding and you need to take over their work. Maybe you start asking folks on how you can better advance your career. These should work wonders for you.
The difference between seniors and non-senior staff is not technical ability but rather visibility. With a micro-service architecture, junior and mid-level staff tend to only have visibility in the services they own. At my company this is a feature, not a bug. There are at least 2000 microservices in my organization.
So to increase your understanding I would:
Hope this helps.
Of course, the passage of time will help you here, but I strongly don't believe in the strategy of "just let time do its thing". This is a very reactive line of action instead of a proactive one, which means that your returns from it are going to be incredibly marginal. In order to really make progress here, you need to put yourself out there. Here's my thoughts on how:
If I were to guess, you are mostly passive in these meetings as the other more established engineers on your team have more stuff to say - I totally get that. However, this is a mistake I see a lot of earlier-in-career engineers make: Not having something super insightful to say doesn't mean that you should just be a complete bystander. Here's some actions you should do to level up your presence in these meetings:
Here's more resources around being more effective in meetings:
On a side note, here's a more extreme scenario which could be correct: If you genuinely don't find much value in these meetings, even after taking these steps to have a stronger presence within them, just stop going to them. One way to figure this out is to evaluate the "closeness" of these other components like Steve mentioned. Are these other services directly related to what you own? Or are they 3+ steps away? (i.e. your domain communicates to another one which talks to another one which then connects to the domains covered in these meetings) If they're very far away, it's not worth your time to learn this massive sprawling picture, especially as a more junior engineer.
If you already have existing meetings with them, this should be incredibly easy. If not, just ask them if they're okay with a 30 minute 1 on 1 to walk through the domain they own at a high level with you. You can frame it in a way where the incentives make sense by saying that you want to learn how to be a better full-stack partner.
For example, I'm a mobile engineer. The apps I write regularly consume APIs. So when I talked to back-end tech leads, I would ask something like: "I want to learn more about the back-end works, so the mobile app can communicate with it as seamlessly as possible. Can you walk me through the major steps behind how API responses are generated?"
If you're a back-end engineer, you can flip it: Say that you want to understand how the front-end works (mobile + web), so you can create a client-server protocol that's more seamless for them and easier to ingest.
As I have talked about many times before, the most effective way to learn is by doing. If you truly want to get a deeper understanding of these other parts of the ecosystem, you can try doing work in them - Talk to your manager and tech lead to see if that's feasible. However, since you're earlier-in-career, I only recommend doing this if you have an expertly tight grip on your current domain (i.e. "In those meetings, are you at least fielding most questions about what you work on?").
Here are some great resources around picking up another domain/tech stack fast: