What are the hidden and easy cherry picking to do for E7 promo?
Ultimately, there is no shortcut to a promotion at this level—it requires significant, consistent contributions that demonstrate your readiness to operate at a higher level of responsibility and impact. And I understand that it might not be easy on those levels, but most of the things described in the official documentation are pretty intense. Is there an easier path to get to the top by doing things smarter and not harder? For instance, there are things that people could do in other companies for bonus points like organizing hike for the team, building Movember type of volunteering event or soccer tournament for the org?
How about the following examples?
Mentorship and Team Development:
Actively mentor junior engineers and contribute to team development. This can include leading internal workshops, contributing to onboarding processes, or providing regular, constructive feedback to peers.
Community and Culture Contribution:
Contribute to the company's engineering culture and community. This can involve contributing to open-source projects, improving internal tools, writing engineering blogs, or participating in company-sponsored volunteer events.
Discussion
(5 comments)- 2
a month agoTech Lead @ Robinhood, Meta, Course HeroSo the necessary projects to get to E7 are definitely hidden (it's up to you to create scope by finding it), but they're definitely not "easy cherry picking". 95% of Meta engineers never make it to E7, because it's incredibly hard. There is a reason E7s are paid $1,000,000+ per year in the US.
Both of the examples you mention are not paths to E7, at least not at the scale they're currently described. Mentoring junior engineers (E3s) is not enough for an E7 - You need to be mentoring E6s or high-performer E5s at least. "Improving internal tools" is more like E3/E4 or even intern scope; however, if you create a massive internal tool like BUCK, that is E7 scope (BUCK was an E7 -> E7 EE project). Rahul has a good example of making a powerful internal tool as an E6 project here: [Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story
People axis also isn't weighted as heavily now so stuff like organizing a soccer tournament are terrible ROI if your goal is to get to E7 ASAP (you should only do these things if you're genuinely passionate about it). My advice to get to E7 is to develop a nose for impact. Here's a good story for inspiration: Rockstar Software Engineer Story: SW2 -> Principal In Just 4 Years
- 1a month agoStaff Software Engineer [E6] [OP]Meta
How do you mentor E6s or E5s high performers? Where do you find them and what if they don't need your mentorship how to force them in a good way? The tool described got him from E5 to E6, what about E6 to E7 tool ideas - probably more engineers usage is the key?
The idea of developing nose for impact is obvious and I am looking for something creative here, other ideas anyone?
- 2a month agoTech Lead @ Robinhood, Meta, Course Hero
The vibe I'm getting here is that you want to force things (given that you're literally using the word), but these things shouldn't really be forced. If you are doing something purely for promotion, you won't do a great job of it and toxic vibes can easily come out.
What you should be doing is looking for opportunities to add value and organically move forward from there. For example, if you are paired with an E6 or a top E5 on a project and you feel like you can teach them a lot from your experience, you can start doing that and hopefully it naturally blossoms into a deeper mentor <> mentee relationship. This is on a more local scale, but the same concepts apply: [Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
The tool described got him from E5 to E6, what about E6 to E7 tool ideas - probably more engineers usage is the key?
Yes, the idea doesn't fundamentally change. I was never E7, but from what I saw, there weren't huge dynamic shifts going from high E6 to E7. It's mostly just expanding on existing scope and behaviors. For example, Rahul's tool was mostly limited to just Portal. If his tool could be spread to a bigger subset of engineers like all of Meta mobile engineers for BUCK, then it would easily be E7 scope.
The idea of developing nose for impact is obvious and I am looking for something creative here, other ideas anyone?
There aren't any unique ideas when it comes to E7 scope. Creating a faster build tool like BUCK isn't new. Making a custom IDE like Atom (this was an E8 project for the guy who made BUCK) also isn't new.
There's no "playbook" to E7 - This is a huge reason why E7 is so hard. You have to develop that nose for impact and figure out what the gaps are in your organization. Build relationships quickly with others, try lots of stuff aggressively, and be humble so you can take in input from anyone anywhere. If you're doing this, you will build up product and org intuition which will allow you to create E7 scope. If you are directly handed an idea for an E7 project, it ceases to be an E7 project (or even an E6 project for that matter).
- 2a month agoStaff Software Engineer [E6] [OP]Meta
This is great conversation. I appreciate the ideas. It brings me to the important question on top of my question. What not to do? I mean what are the common mistakes that people had in this journey to get to top levels, maybe forcing mentorship is good one here, making things organically is the better way. What else is the common issue when people tried and failed?
- 1a month agoTech Lead @ Robinhood, Meta, Course Hero
Great question, I love it! There are so few cases of E6 -> E7 (just ~3% of Meta is E7 or higher), so here's just common themes I've noticed among engineers struggling to push for E6+ promotions in general:
- Reactive instead of proactive - It's the classic "I'm not getting promoted because my manager/director isn't giving me the best projects". If you're waiting for that sweet promotion project, you will wait forever. At E6+, you have to be creating scope.
- Thinking inside the box - E7 is the level where the manager you report to pretty much doesn't matter (this is why many E7s report to a Director of Engineering directly). However, most E6s report to a front-line engineering manager (M1). It's crucial to ascend past this barrier and start thinking more holistically, outside of your team's immediate charter. E7 projects regularly bring together 5+ teams from the overall Director of Engineering (D1 or D2). Another aspect here is being complacent and just accepting things the way they are. "There's no way we can optimize our build speed - There's just too much complicated code" - This is something weaker engineers say all the time. While making excuses is fine at E3/E4/E5, it's not fine at E6 and certainly not at E7. An E7 engineer should believe that every problem is solvable and consistently prove the world wrong by solving those seemingly impossible problems.
- Lack of relationships - A classic understandable misconception among software engineers is that they believe the quality of the argument is all that matters. They believe that if the facts are on their side, they will definitely win. But that's just simply not true. Engineering is done by a collection of humans, and humans are imperfect and emotional. I have seen engineers get to E5 off of their raw talent and bulldozing people instead of building relationships. I have seen even fewer E6s do it. And finally, I have seen pretty much 0 E7s do it. Every E7+ engineer I have met was incredibly kind and charismatic. People underestimate how high the ceiling can get when it comes to trust-building and communication - It really is infinite. Here's a great thread: "How do I lead without authority?"
