(I'm Staff myself, but would not have got here without management responsibilities.)
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!
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.
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.
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.
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.
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.
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.
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.
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.”
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
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.
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.
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.