1

What are some L7 and L8 level projects you've seen?

Profile picture
Mid-level Software Engineer at Taro Communitya month ago

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.

601
6

Discussion

(6 comments)
  • 5
    Profile picture
    Staff SWE @ YouTube, Engineering Mentor, SWE Guru
    a month ago

    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.

    • 0
      Profile picture
      Mid-level Software Engineer [OP]
      Taro Community
      a month ago

      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.

  • 2
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    a month ago

    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
    Profile picture
    Engineer @ Robinhood
    a month ago

    An 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.

    • 0
      Profile picture
      Mid-level Software Engineer [OP]
      Taro Community
      a month ago

      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.

    • 2
      Profile picture
      Engineer @ Robinhood
      a month ago

      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).