Hacker News Reader

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.

I suspect they’re talking about Senior Staff IC’s - aka TL’s of TL’s.

Hell, I’d happily be Lundberg for $1.3M/year. Shoot, I’d probably even do it for just $1.0M — and the Bobs would be pleased!

It also sounds like the 10x developers are underpaid by a factor of 100!

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.

Google and Meta/Facebook have generally aligned and numerically equivalent levels for the main Software Engineer and Engineering Manager ladders.

levels.fyi has this

Adding a correction on above ->

L7 is Senior Staff Engineering Manager (M2)

L6 is Staff Engineering Manager (M1)

they are of equal level to the SWE ladder L6 and L7 titles

What's the difference between Staff and Senior engineer?

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?

No.

I believe a TLM is an IC on this scale.