How do you come up with effective projects that will drive team direction?

From my POV, the best way to start is to write more code. People trust based on competency, and the more direct way to prove competency is by writing code. If you're able to ship code significantly faster and better than your mid level peers, people will naturally bias towards trusting you more. The more code you write and actively think about, the more you'll passively build more muscle to write code faster and better. Once you're able to turn that into a consistent track record of delivering and shipping projects, the trust your peers have in you and your understanding of the domain will naturally grow.

Another line of thinking around the code is one of main growth vectors expected to grow to senior is being able to succinctly communicate technical concerns to stakeholders with little to no context (often, these won't even be engineers). Your understanding of the world as an engineer is built on code and the systems they support. If you have little either understanding of either and try to drive things your way, your peers will be quick to notice and they'll likely just ignore you (since they either don't trust you and/or it's frustrating that you're trying to do things when there's clearly not that level of trust). This is a very common trap many junior and mid level engineers fall into (myself included when I was more junior): don't do this. You'll likely waste your team's time and your manager will likely tell you (politely) that you don't know what you're doing and you're wasting everyone else's time (my manager had this exact convo with me when I fell into this trap). It also hurts you since that time is gone & could've gone to something that provides more consistent growth value (like improving the speed and quality of your code).

Don't try to rush things: take your time to understand the code and system you're working in. Once you have this understanding and there's clear trust in you from your peers, then start thinking about influencing the team. If you jump into influencing too soon, you'll likely end up with no results and even less time to avoid up-or-out (for the non-FB folks: mid level engineers have 3 years to get a promotion or they're fired). The only guaranteed way to make the process of building up trust and domain knowledge faster is by improving the speed you ship projects at (which circles back to writing code faster and better): I have yet to see a senior level promo in less than a year without the individual clearly being 2x-3x more efficient than every other peer at that level. Relative to their peers, these individuals have a mix of (to name a few):

• Significantly more PRs landed per half
• Faster turnaround for putting up a PR
• Needing less support to ship projects
• More projects shipped every half
• Work across more stacks than their peers
• Consistently and quickly helps other with no significant productivity loss

What is the best way to quickly learn and understand what the priorities are in the org?

Talk to people and look at data. This is something Meta is uniquely positioned to do as the culture is very open, and it logs everything. You should ask the following people what they care about when it comes to adding user value/advancing the team:

• Your manager
• Tech lead
• Product managers
• Designers
• Data scientists

For each of these people, ask them what dashboards they regularly look at (and what they mean if you're unable to interpret it, some Meta dashboards are unintuitive).

That being said, a new E4 going too deep into this is putting the cart before the horse. As Jonathan mentioned, your priority should be to establish yourself as a very solid IC first, because strong "Engineering Excellence" is the bedrock for an E4 meeting expectations and going to E5. Here's a good thread that dives into this process around building technical influence here: "How can I get better at my technical influence?"

I also recommend our mid-level to senior playlist: [Taro Top 10] Mid-Level Engineer To Senior Engineer (L4 To L5)

I have something called "talk & observe" which should help :) https://www.jointaro.com/blog/talk-and-observe-a-framework-for-engineering-onboarding/