For this upcoming half, I'm working in four different areas: reliability, sourcing, delivery, and datastore table. It just seems like it's too much and I'm not building any depth? Feels like I won't be able to build expertise in anything and be unable to contribute as a good team member if I'm working on everything?
My TL has also informed me they are struggling to scope out work due to a lack of senior engineers. This has resulted in me getting menial tasks such as better engineering work and refactoring in some of these projects (i.e. delivery, sourcing, and reliability). It's great for my diff stats, but I want larger scope and less narrow work to be considered for E4. I'm discussing with EM, but the EM and TL seem like they are on different pages. I'm most interested in sourcing, but seniors are struggling to scope out work.
Any suggestions on what to do here? I feel a bit lost overall and I'm struggling to understand how to get scoped and larger non-menial project work. Should I involve my skip manager here? A couple of questions in this one question but appreciate all the help in advance.
I'm discussing with EM, but the EM and TL seem like they are on different pages.
When in doubt, you should follow your EM, but you should try reconciling this. You can start a group Work Chat with you 3 to get alignment and what makes the most sense for you. If you want to be very deliberate with it, have an actual meeting and label it as an "Alignment Exercise". Both your EM and your TL are going to give you PSC feedback - If you want to get to E4, they almost certainly need to be on the same page.
I'm most interested in sourcing, but seniors are struggling to scope out work.
This makes sense if there's a lack of E5+ on your team. It is very common at Meta where you'll be in a situation where nobody is going to come save you - This seems to be one of them. It will be tough for an E3, but I recommend trying to scope out the work yourself. Flip the dynamic:
If you're able to do this, you will definitely fast track your promotion to E4. Here's some resources on how to do this:
Should I involve my skip manager here?
Unless you have a good relationship with them, I'm leaning away from this. A skip will generally be very hands-off with E3 engineers. It's more of your direct manager's job to sort this out - Go through them first.
Lastly, for what it's worth, E3s, even those targeting E4 promo, are generally not held responsible for impact. You can get promoted with an array of disconnected work instead of one, big focused project. The depth component is more important when going from E4 -> E5. However, I'm unsure if this is still true in the current Meta PSC.
Thank you for sharing the context.
I first want to question the assumption around what is needed for E4 promotion. You may be totally right that you need wider scope, and you have to become a mini-TL for one of the domains you point out, but that's worth clarifying. Have you already had the discussion with your manager about how you're trending relative to E4 expectations, and whether the work across 4 projects might suffice?
At E3 --> E4, I feel like the need to have one major launch is not essential. Especially in your case, if your team is strapped for senior engineers, I'd expect that the "let's get the job done" mentality is sufficient for a promotion to mid-level engineer. And sounds like you have good code output, which IMO is most important.
However, I can still understand your frustration since it's probably less fun to work in this scattered approach. And having depth in one area is generally better for long term career growth, where people think "I can definitely come to you with any questions about this system".
I wonder if you could do that on the side, e.g. you pick an area where you dive deeper into, and spend your extra cycles in improving documentation, adding tests, and going above the call of duty. So you become the de facto lead of that area anyway.
Finally, I agree with Alex that I don't think your skip-level manager has much value to offer here, unless you can connect this issue with a broader team dynamic that is worth their attention. The failure mode of going to your skip is perceived as complaining about the situation you're in.