There do exist those rare creatures who manage to get promoted to, and beyond, L6 as ICs. I've been trying figure out how they do it, but can't say I've been making much progress.

(I'm Staff myself, but would not have got here without management responsibilities.)

It's rare, but possible.

Known of v high level example that is just incredibly disciplined about how they spend their time (e.g. "I did this, but was slowed significantly by poor code over that. Estimate about 30% time loss. I'm going to spend N weeks more in this area, so it's worth me spending 3.5 days fixing that code, but no more. I think I can fix it in about 2 days, so I will fix it. If I can't see the end of the fix by the time I'm 4 hours in, then I'm probably wrong about the expected time, so will abandon the fix").

The result is ridiculous productivity. They don't work long hours (strictly 9-5), but just very, very focused on making certain that there will be meaningful results from those hours.

So they exist, but absolutely it's not going to be common!

I don't know about other places, but volume of work does not matter for L5->L6 at Google. The kind of work you do is what matters. So doing 50% more doesn't get you there.

The L6 (and L7) ICs I know got there by implementing really tricky components way down the tech stack that are very difficult to update due to insane implicit dependencies and also enormously impactful in terms of savings across the entire company.

It's not rare at all in my experience. You just have to have a combination of skills that pays more than average on the open market (big data runtimes or distributed systems, say, or AI, in addition to other domain expertise perhaps), and you'll be L6 or L7 IC, no problem. No managerial duties whatsoever. L7 is more nebulous, but L6 is absolutely doable for anyone with a modicum of marketable skill.

You see, in spite of their internal promo treadmill and brainwashing, companies have to compete on comp regardless. Comp ranges, in turn, are tied to levels. If, say, someone who knows a distributed query plan from a hole in the ground costs $1M/yr, they'll get that and the "level" will be adjusted accordingly, as much as necessary, ignoring the elaborate formal descriptions of job responsibilities.

It's the proles in the trenches that take the levels seriously. People who actually run things understand that levels are merely a hamster wheel, put in place to give you something to look forward to, and to keep your comp expectations in check. Lack of "broad organizational impact" is _the_ most often used cudgel to deny promotions to the more senior level, unless your skill stack allows you to bypass this bullshit entirely.

That sounds entirely logical, but unfortunately having never worked in a FAANG or FAANG-like company[1] I can't tell whether this is the reality or not.

I would very much like other readers here with experience in FAANG or FAANG-like companies to comment on your comment.

[1] Most Corporates and enterprises are different - they resolutely refuse to match based on market-value of skills. There's also very little a developer (senior or not) can do to have a company-wide impact, because the fiefdoms that are in place will resist any attempt to "lose" their territory.

Largely false. Managers have pretty wide latitude to approve compensation matches for employees they want to keep without up-leveling them. So if you're a star L5 at Google and Facebook is giving you a $MM E7 package, you could end up with a $MM stock grant (which would normally be reserved for L7+) at Google. Compensation raises are tied to level, but that just means that you'll sit and vest your existing stock grant without further raises or refreshers until your formal level matches your comp package. This happened semi-frequently in the ~2010-2011 era when Facebook was recruiting heavily out of Google with pre-IPO stock.

The promo process is based on your value to your employer, and at least at Google is done by committee, which is drawn from a selection of high-level employees outside of your manager's department (so they have no incentive to keep you) and has a packet of information that does not include anything about your market value outside the company.

Stock ranges (as well as refresh grants) are also tied to levels you're hired at. "Largely false" my ass. All of this BS applies _only_ to people with weak skill stacks. Committee doesn't even know your "previous" level elsewhere. They know that you've e.g. built this very impressive distributed system here and now and hopefully it made $MM revenue difference (which you'd be smart to quantify and mention). So if you can do it, you'll get rewarded appropriately. If you can't, you won't. And sure, you can't go E5 to E7, there's just no way. But getting from E5 to E7 (or T5 to T7 at Google) is doable in two promo cycles for someone who's in the right place at the right time, and has the right skill stack. Or in fact in the immediate if they are willing to move to another FANG company.

Distributed system & big data knowledge is table stakes for Google engineers. At L4 you will be expected to deal with large distributed systems handling petabytes of data. You probably don't need it for L3 (which includes new grads who would never have had an opportunity to develop that skillset elsewhere), but by the time you're at L4 you should be dealing with that regularly.

This is one of the perks for moving from FAANG to non-FAANG; hiring managers elsewhere know that simply by being an engineer there you will have had exposure to distributed systems and big data, and so bring a transferrable skillset to their company.

I thought about whether your comment is true in the context of Speech & Image recognition and other AI technologies. The Speech leads do seem to have an awfully high number of Distinguished/Fellow engineers (this is the top of the eng ladder, where you can basically write your own ticket and your comp package is enough to retire on). However, there are still an awful lot of L4 engineers working on Speech, many training deep-learning models as part of their daily duties.

FB may be different.

> Distributed system & big data knowledge is table stakes for Google engineers

True, but observe that knowledge is very different from _experience_. In anything sufficiently complicated there's tons of stuff you won't find in books, and even if you do, you won't pay sufficient attention to. E.g. you could sorta know how a database works (from a university course or something), but if you haven't implemented e.g. a state of the art query engine or a storage manager, you'll still be SOL in practice until you write one or more of those things and actually gain experience.

Knowledge by itself is darn near worthless, it only becomes valuable with experience, particularly if it's in 2 or more related fields.

I'm an L6 IC. Basically I had a track record of delivering projects that other engineers said couldn't be done yet were a high priority to upper management. That's actually on the (Google at least) ladder: "At this level...most Google-caliber generalist SWEs could not own and solve the problem this person is owning and solving."

Note that even though I'm a coding-heavy L6 (meaning I spend ~50% of my time coding vs. the 0% that most L6s do), the majority of my time is still spent interfacing, negotiating, and communicating with other teams. The ability to silo in a particular problem domain and just become a local technical expert ends at L5.

Can you give an example of a project like that? Or at least a hypothetical example if they are confidential.

I can’t think of a project like that that people said couldn't be done, its usually just people saying “we cant do it at this time unless we get more time or reprioritize something else.”

My current project is confidential, but one from 2013-2014:

We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations, and our execs really wanted to bring that to Google's webapps. At the time, there was this big perception that mobile web sites were slow and clunky and you absolutely had to go native app to get smooth 60fps transitions. I did some profiling with the Chrome profiler and found that the bulk of time was spent in layout & reflow, and that one single reflow would blow your entire frame budget and then some for 60fps on mobile. So then I went to the Chrome GPU team and got a quick tutorial about exactly which operations were handled on the GPU (basically just transform and WebGL, at the time), and put together a visual language that basically involved rendering portions of the webpage to GPU textures and manipulating them only with 2D transforms, which could be GPU-accelerated. The work later formed the foundation for how Material Design was implemented in Search.

As a side note, I learned a lot about how browsers work under the hood with that project, and one of the things I learned is that the entire premise that React was sold with was false! At the time, the big selling point with React is that "DOM manipulation is slow, so we create a virtual DOM that's fast and then diff the changes to the virtual DOM so we make only the minimal set of DOM changes we need." Except that every major browser by 2013 used a dirty-bit system for DOM manipulation, so changes to the DOM are actually quite fast (roughly the speed of a couple pointer manipulations in C) as long as you don't trigger reflow. And you can trigger reflow with any one of about 2 dozen method calls, as well as automatically when you return from a Javascript script fragment, so basically every Angular and JQuery website was triggering multiple reflows per event. React was fast because it was declarative and didn't let you execute user code until it was done batching up all DOM manipulations, it wasn't fast because of the virtual DOM. And I believe there have been re-implementations of the React API that do away with the virtual DOM and they are equally fast (oftentimes even faster, since they're simpler and don't need the DOM diffing), but at this point React is popular because it's popular and everyone knows the API, not because of any purported performance benefits.

What about this project made it L6? Is it because it was a high priority for execs? Is it because you had to get a lot of buy-in from external team(s) in the Chrome org?

It's the combination of it being an exec priority + the industry consensus at the time being "It's impossible". If you deliver a high-priority project that any engineer can glance at and have an immediate idea how to solve, that's L4 work. (Say, you're shuffling data from protobuf to a bunch of Javascript on screen.) If you deliver a high-priority project that most engineers are declining to work on or saying "It can't be done", that's L6 work. If you deliver a high-priority project and then publish it externally and then the rest of the industry actually says "Woah, this is revolutionary and really valuable to us" and then Doug Cutting clones it over at Yahoo and releases it as open-source and spawns a whole sub-industry, that's L9 work.

This is all for IC engineering. I actually prefer to think of the ladder in organizational terms which also encompass management, but the sub-thread here is specifically interested in what it takes to be an L6+ IC.

Thanks this is really illuminating, how did you find projects like this? Where did u get the visibility to be able to find problems like this that were priorities for leadership?

It was quasi-assigned to me (I had the option not to work on it, but management would've been disappointed with that).

Management thought of me specifically because I'd built a reputation as someone who could tackle difficult projects, particularly those surrounding browser UI. I'd worked on the last 3 visual redesigns of Google Search (as the first engineer of the 2010 one, a consultant for the 2011 one, and the tech lead of the 2013 one), plus I started the Authorship project within Search, plus I'd done a bunch of little visual easter eggs like the [let it snow] holiday one (also a project that many people thought was impossible because it was started after the last binary push of the year). Management takes note of who delivers; it takes a while to get noticed, but once you are you get all the high-profile projects.

Not OP, but I image they are more projects that span multiple teams, disciplines, and stakeholders.

There's nothing (unless it hasn't been invented yet) that can't be implemented in software in a silo given infinite time, but the ability to deliver complex solutions to difficult business/process problems that require buy in and coordination from a lot of people are probably these kinds of projects, particularly if these projects are alterations or additions to other pieces of complex processes that already exist and are hardened but need improvement or overhaul.

Here's an example from my work. We use a legacy version control system alongside git. This causes tons of issues and the way forward would be to deprecate the legacy version control, but doing so without disrupting current engineering work and making tangible improvements going forward is a very complex task that spans a whole lot of teams and is risky and tricky to implement

Is the legacy vcs ClearCase or DesignSync?

no

Thanks! That makes a lot of sense.

I've seen this track described as a "Solver", a sort of internal mercenary who can join a project with a critical, difficult problem, research it to a very detailed level and drive a solution.