How do I understand/leverage my company ecosystem?

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:

1. Start with understanding the services adjacent to the ones you own. Don't try to learn about every service all at once. If your service calls theirs, or their service calls yours, it's likely that those systems will be easier to understand for you.
2. I would focus on a conceptual understanding of why these services exist rather than what they do or how they do it. This can usually be summarized in a sentence or two but is sometimes difficult to get at because the folks that work on these systems want to talk about the finer points of how they do things.
3. I've found that in a microservices architecture, when trying to draw a box and arrows diagram it's easiest to collapse several services together that share similar responsibilities. Once a diagram goes beyond 10-12 elements it gets too complicated to be useful.
4. Give yourself time to internalize things. This is complicated stuff, if it was easy to understand then anybody could do it.
5. I know I have enough understanding with a system when I can read a document produced by another team and understand what it's saying. When trying to figure out what a suite of services does, see if you can't get access to some of their documents. Note the terms you don't understand, and then try to figure out what they mean. I have found that people are happy to help if you make a concerted effort to understand what they work on and batch your questions so that you are respectful of their time.

Hope this helps.

-Steve

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:

Be More Active In The Meetings

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:

• Take meeting notes - By writing down what these senior engineers are saying, you have a much better chance of retaining that knowledge and being able to incorporate it into your work or in future meetings. You will also build up social capital as people generally appreciate teammates taking on the scribe role.
• Ask questions - There are many reasons to do this:
  • You completely don't understand something that was just said - To help with this, I recommend the advice in this discussion around maximizing the effectiveness of your question: "How do you overcome the fear of asking stupid questions / bothering people when you need help?"
  • You think you understand what was said but want to make sure - This has a lot of value by clarifying complex points and helping you paraphrase them for the aforementioned meeting notes. I cover this tactic in depth here: "I struggle to come up with things that add value to a meeting - What do I say?"
  • You want to expand on a point - This is very relevant as your goal here is to get a broader understanding of systems. For example, let's say a senior teammate says, "We can't structure the response this way - The API latency will be too high." From here, you can ask something like "Why would the latency be too high? What makes this JSON response structure slow?" From there, the senior teammate teaches you that the front-end parsing library isn't good with 3+ layers of nested custom objects.

Here's more resources around being more effective in meetings:

• "How can I be more active in meetings and earn the respect of senior engineers?"
• "E5: How to participate in discussions effectively without context?"

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.

Just Talk To Senior Engineers

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.

Work In Other Domains

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:

• "How do I identify the core things to learn when picking up a new tech stack?"
• "How do I balance slow code spelunking on my own vs. asking questions to speed things up?"
• "What is the effective way to understand new repository in order to make the required changes in that repo?"