GOOG has made a systemic push to eliminate the role starting ~3 years ago. At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM.
In those last 3 years I've only seen TLMs used to assist an overloaded EM.
The pattern I've seen is something like:
Principal EM
|- Staff EM (7 reports, project A)
|- Staff EM (8 reports, project B)
|- Staff IC (projects A, B, C)
|- Senior IC (projects A, B)
|- Senior IC (project C)
|- Mid level IC (project C)
|- Mid level IC (project C)
Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time.
So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc.
Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM.
Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.)
> At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM.
I am obviously not disputing your experience, but wanted to mention that this was not the standard pattern. The standard pattern for forced conversion at L6 (Staff) was either 6 or 7 reports (I don't remember exactly).
> Principal EM
I don't want to be overly pedantic, but there's no Principal EM on Google eng ladders and so it's not entirely clear which level you're referring to.
The IC ladder runs Staff SWE (L6) - Senior Staff SWE (L7) - Principal SWE (L8) - Distinguished SWE (L9)
The Eng Manager ladder runs EM II (L6) - EM III (L7) - Director (L8) - Senior Director (L9)
P.S. I hope I got the EM II/III designations right. I think EM I is L5, though almost never seen in practice.
P.P.S. Confusingly, the IC ladder allows a limited number of reports (the limit increases with level).
>> At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM.
>I am obviously not disputing your experience, but wanted to mention that this was not the standard pattern. The standard pattern for forced conversion at L6 (Staff) was either 6 or 7 reports (I don't remember exactly).
I think you're both saying the same thing. By "forcibly converted to EM", I think B-Con was saying the person was given more reports.
> I am obviously not disputing your experience, but wanted to mention that this was not the standard pattern. The standard pattern for forced conversion at L6 (Staff) was either 6 or 7 reports (I don't remember exactly).
Given more reports and forced to be on the EM track.
I think 4 is still OK for L6 (L7 can have up to 19!).
> I don't want to be overly pedantic, but there's no Principal EM on Google eng ladders and so it's not entirely clear which level you're referring to.
I meant L7 EM - I have no idea why I wrote Principal (probably because I was moving too fast), and now it's too late to edit.
Wait, so you have ICs who work on multiple projects, and report to a different manager depending on the project? That sounds like a nightmare. Having one manager to manage is usually enough work...
It's actually quite common and it's called "matrix management". Multiple people to give you orders and no one to take accountability. You'd be surprised how wide spread it is.
levels.fyi doesn't appear to use the term "Technical Lead". There is "Technical Program Manager" and "Technical Account Manager" that sound like they'd be similar (someone technical transitioning into a full-time non-technical role). And then roles such as "Product Manager" and "Program Manager" seemingly for those who are currently 100% non-technical in their work.
Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day?
TPM and TAM are completely different roles. TPMs are essentially project or program managers across wider parts of the org, and the "technical" means they have something beyond a surface understanding of the technical aspects, but are likely not writing any code. TAMs are account managers in the sales org with a focus on giving clients more technical support or planning integrations etc.
"Technical lead" is not a role profile or ladder, it's what you're doing. You could be a TL at L4 on a small project, and you could not be TL at L7 if it's a big enough project. All very subjective.
The point of this thread is that there are teams with a manager who is the defacto TL for the projects the team is doing, so they have IC responsibilities, and then there are teams where the manager does manager things and there's one or more separate TLs.
I've worked on teams in both structures, both in and out of Google, and whether TLMs vs EMs work well depends on so many factors: who the manager is, their management style, the org's priorities, the projects, etc.
> Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day?
In house solutions architects are not really a thing at FAANG. Designing and implementing systems is what mid+ level SWEs are expected to do. The solutions architects I have seen were all in the sales org helping external customers better use the cloud. My experience isn't exhaustive of course.
It's been a few years, but from what I recall, a Principal is a Director-equivalent (L8) level.
The prior poster is missing the L7 tier, which is Senior Staff Engineering Manager for the Engineering Manager Ladder.
L8 is a Director on the Engineering Manager Ladder
L8 is a Principal on the Software Engineer (SWE) Ladder.
Tech-Lead Managers (TL/M or TLMs) were on the SWE Ladder.
For reference:
Software Engineer Ladder
L8 - Principal Software Engineer
L7 - Senior Staff Software Engineer
L6 - Staff Software Engineer
L5 - Senior Software Engineer
L4 - Software Engineer II
L3 - Software Engineer (new graduates would start here)
----------------------
L2 and below exists in rare occasions.
Engineering Manager Ladder
L8 - Director
L7 - Staff Engineering Manager
L6 - Engineering Manager (M1)
L5 - Engineering Manager (M0 - normally this level does not exist for external hires and is for the rare situation when a SWE is converting to the Engineering Manager ladder)
One of the problems is that large corporations have such complicated role structures, and another problem is that they are also different from all other large corporations. A third problem is that the compensation models are again vastly different. A fourth problem is that they change over time.
All of this means as an individual you suffer from extreme information asymmetry.
Even if you got two offers from two different FAANGs, it would perhaps be hard to figure out which one is better.
Has anyone defined any mapping tables between role names across Amazon, Meta, Alphabet etc. and figured out salary ranges for them in a public spreadsheet?
BTW, has anyone got a leaked (anonymized) copy of FAANG employment contracts so one can compare the various clauses across employers, and track changes of their standard templates over time? (I haven't seen this topic discussed much on here in the systematic way that it deserves.)
Given the developer community invented open source it is surprising that corporations have so far succeeded in keeping such obvious things relatively secret (compared to, say, the emails of Sarah Palin and Ehud Barak ;-).
This is not really an accurate representation of FAANG hiring and job searching. In reality, there is a very very high amount of job hopping and also connections to people at other FAANGs (and there's also levels.fyi and blind) so we're well aware of comp structures, what employment agreements, levels, etc are across companies and how to compare then. There's very little information asymmetry in fact people go into negotiations with recruiters very well equipped, far better than at small companies.
> BTW, has anyone got a leaked (anonymized) copy of FAANG employment contracts so one can compare the various clauses across employers, and track changes of their standard templates over time
If this doesn't exist it's only because it's incredibly uninteresting. levels.fyi will tell you all you need to know. (also they aren't employment contracts, in the US we do agreements because we're at-will)
I've hopped multiple FAANG+s now across my career.
Senior engineer is usually focused on a single project, and knows it deeply. Usually directing and mentoring more junior engineers in the process.
Staff engineer typically is overseeing multiple projects, providing deep technical oversight and guidance on those projects, and mentoring Senior engineers. They start to influence technical culture. They are actively involved in ensuring business needs get met by the technical solutions their group is building.
Senior Staff Engineers will be overseeing a product function, and multiple Staff engineers. They build the correct technical culture. They ensure larger architectural issues get resolved. They are actively involved in ensuring the technical work being done is meeting business needs, and identifying business needs their technical org can be meeting - and working to make that happen.
Principal engineers are setting the tone for an entire large product (typically), and ensuring the Senior Staff engineers are doing the right things - and also often involved in driving strategic product direction.
Senior Staff and Principal tend to be increasingly political, but even Staff will get pulled into that type of thing somewhat regularly.
TPM, TAM, and PM have nothing to do with this. A technical lead is usually a semi-formal role for an IC or a TLM that implies that they are leading a project with other folks working on it. There are situations where the Mid, Senior, or Staff IC could all be a technical lead of various sized projects.
> Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day?
I've always been perplexed when I see 100s-1000+ people work on software product development and very little happen with the product for YEARS while there are tons of obvious (to me) improvements possible. Only tiny bug fixes released on a pretty slow release cycle. Then I also just think of the twitter/X example.
Occasionally one reads stories of how people get paid pretty hefty salaries to mostly just work very casually. Contrast with the usual software engineering types I know that work insanely hard solving difficult problems day-in and day-out.
When I was younger I remember a lot of project managers (almost exclusively ladies in my environment back then) that mostly just ran around interrupting the programmers and relaying feedback and status and a lot of chitchatting and busy work. Often there can be tons of support roles, wellness officers and who knows what that can probably be slashed. What shocks me is when a lot of these really low value-add positions are given high seniority with crazy paychecks and very little real skill required and fairly low responsibility or accountability for anything vaguely tangible. I suspect in tech companies generating huge cashflows that almost seem decoupled from headcount in comparison to non-tech businesses, this stuff just get covered up. A big machine that is very profitable due to massive competitive advantage/network effects, can hide a ton of HR waste.
> I see 100s-1000+ people work on software product development and very little happen with the product for YEARS while there are tons of obvious (to me) improvements possible
I worked in an org with about 60 engineers all working on the same product and I have to actively _not_ fix small issues to keep my sanity. Whenever I see a small issue I would have:
0) If it changes anything visible to the user discuss it with UX or PM (very annoying)
1) Fix it (easy part, usually)
2) Create PR and explain issue
3) Get someone from the other overworked team to look at it (not as bad if it is from my own team)
4) Get comments for often trivial things (depends a lot on the changes)
5) Get asked to refactor some related functionality because the fix is a bit messy without it (workaround) or to address the root cause of the issue (this is usually a big deal)
6) Possibly several rounds of reviews
7) Someone break my fix next time anyone makes a change to that part of the code
All to get something done that wasn't asked of me, that my manager will probably not see or know about unless I bring it up, that if I do bring it up my manager will probably tell me to not waste time on it since "it is the other team's problem".
So I would either ignore the issue or create a ticket that will probably be ignored. Only if it is a really trivial uncontroversial change would I bother to actually proactively do it.
Thanks. This explains Android. Because the only other explanation would be no dev at Google actually uses it day to day as their phone because it has so many dumb little infuriating things.
Example: Why does my kitchen bluetooth, that I connect to the most, and that I am located nearest to, always go to the bottom of my bluetooth list, meaning I can't select from the quick screen and have to unlock and pull up another screen (when my hands are kitchen dirty)? I consume media on bluetooth the most showering and in the kitchen. The devices used should be 1 and 2, but they never are. EVERYTHING on Android is this 'devs must not actually use this' unfriendly. I still can't use the timer function using voice because if I don't wait for my phone to repeat back all the timer info and I touch something it just blanks out my timer, so I've learned I can't trust it after ruining too much food. These are my two most common use cases for my phone and where it ads value to my life, and both are needlessly annoying on Android causing me to hate the platform because in 2025 these little details should work. Someone at Google must cook things that need timers. Someone at Google must listen to music/audiobooks and have enough devices they spill over to the secondary screen. If feels like Android has zero actual world love/care from the devs or these daily annoyances would bubble up instantly.
I see your Android, I raise you a google home speaker. Please someone help me understand, why is it a freaking pain to use these speakers with bluetooth? Why can I not use them as output for the tv? Is the audio lag just an artificial limitation? I got them assuming they were bluetooth speakers with the Assistant and streaming stuff. But apparently not. Which sick product manager came up with that?
Many large organisations inadvertently, with reasonable intentions create a structure with a powerful bias towards inaction.
It's reasonable, when a company is looking into buying a new SaaS product, that the legal team review the contract.
It's reasonable for legal to ask for variations in the contract, if there's something in it they can't approve.
It's reasonable for the product to be reviewed for compliance with our privacy laws, before we order employees to start using it.
It's reasonable that the information security team get to be consulted before a new product is adopted, we don't want insecure products sneaking in.
It's reasonable that we want single-sign-on from our vendors, that's good for security. And we want SOC2 compliance if possible, as we're trying to be SOC2 compliant ourselves.
It's reasonable that a vendor have a record in our finance database, so we can pay them and know who we've paid what.
It's reasonable that, before approving a vendor, we get a statement from them that they do not use slave labour in their supply chain.
It's reasonable that every expense be attributed to a project or department within the business.
It's reasonable that the project or department's budget have an owner, who has to approve major expenditures.
It's reasonable that the work above is split across quite a few teams, and that each team have a queue of work where non-emergency requests can take a week or two.
But take those reasonable policies together, and it takes 3-6 months to adopt a new SaaS product - so it's a heck of a lot easier to stick with an under-performing, over-priced vendor than it is to get a new vendor approved.
> Contrast with the usual software engineering types I know that work insanely hard solving difficult problems day-in and day-out.
Well you just know some... not effective or smart folks then, unless they literally enjoy living such life. There is time for some hard work, but if that's one's default modus operandi long term, rest of their lives suck pretty badly, no realistic way to avoid that.
That's failure to manage one of most critical aspects of life. Especially bad fail if employed at some heartless mega corporation, or just usual often amoral FAANGs of these days (unless the goal is to earn enough money in few years and move to saner place in life, but few achieve that even if they plan for it, ie mortgages and kids happen).
Some of us live to work, and the rest work to get some good actual life.
Except few companies can do what musk did on an ongoing basis without losing all experienced staff and system knowledge. It's short term gains at the expense of long term gains. People only put up with it if they think they can capitalize on the prestige.
In those last 3 years I've only seen TLMs used to assist an overloaded EM.
The pattern I've seen is something like:
Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time.So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc.
Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM.
Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.)
(Edit for formatting.)