What are some L7 and L8 level projects you've seen?
A few months ago, I was bad at understanding the expectations for each level. Thanks a lot for the Taro courses and the community, you made a real impact on me. I now have a better understanding of L3, L4, L5, L6 levels.
I'm now curious about some things that L7 and L8s do. What do their projects look like? What's the size of the team/org that they have to manage?
Would be nice if you can provide some example projects to get a better idea.
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(6 comments)- 5a month agoStaff SWE @ YouTube, Engineering Mentor, SWE Guru
There's wide variety of archetypes at L7 and L8 levels. You cannot prescribe a fixed/minimum size of the org as a factor. However, outsized impact is a minimum at those levels.
For example, one recent L6->L7 promotion in my organization: technical lead for 60+ engineers from my organization, working with x-fn/x-team for an year, to launch a $XB+ ARR product for YouTube. This is a typical project TL type of role.
There's other archetypes where you solve a deeply technical problem, with a very small group of engineers even. I had a mentor who saved Google millions of SWE hours by redesigning core search infrastructure.
- 0a month agoMid-level Software Engineer [OP]Taro Community
Oh my goodness! So, basically we need to make a billion dollar impact to become L7? Is that a minimum threshold to become L7 in big tech? That seems really really hard.
- 2a month agoTech Lead/Manager at Meta, Pinterest, Kosei
A well-known Meta story is from Michael Bolin, who reached E9, one of the most senior engineers in the company.
You can read his LinkedIn to see how he continuously invented frameworks that were then adopted by 100s or 1000s of engineers. Notably, I believe the project that got him to E7 was creating Buck. Buck is a build tool used by most teams at Meta now, and has gained adoption at other companies like Uber as well.
- 1
a month agoEngineer @ RobinhoodAn E7 iOS engineer in Robinhood built a cross-platform frontend framework that saw widespread adoption & has quite a few senior+ engineers supporting it. They did this as a side project too.
- 0a month agoMid-level Software Engineer [OP]Taro Community
So, is it safe to say that E7 engineers are good at building a product from 0 to 1? This is when a lot of design decisions are to be made that will stick for a long-life of the project and hard to change. Eg: What languages and frameworks to use, what's the overall architecture should be, etc.?
E5 engineers are good at taking the product from 100 to 101, i.e., building a project on top of an existing product (like building a like or comment feature on Instagram). E6 engineers are good at owning and helping a team of E5 engineers. - 2a month agoEngineer @ Robinhood
E7s+ solve broad problems that cover the scope of a significant portion of the company and/or a significant number of people (usually both).
I would put it like this:
- E5s generally own projects.
- E6s generally own a team (it's more complex than just helping E5s, but that's another discussion).
- E7s own org-level problems (defining an org as at least 2 teams/collectives of people). Often, a lot of these org-level problems are not scoped to their reporting structure & are happening outside of the org of their reporting structure.
For the E7 I mention, they just simply saw a gap around the company lacking a cross-platform framework that could run the shared code locally on device. So they built one. This problem is E7 because:
- Technical depth is really high. Cross platform frameworks are not easy to build, yet one was built from scratch despite existing solutions (meaning they were technical enough to identify what wouldn't work for existing solutions + align others on this).
- The solution had a positive impact on all Android and iOS engineers (which is 2 collectives of ~70-80 engineers).
