This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers.
It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.
This is being sold as an efficiency win for the sake of the stock price but it’s really just moved a few people around with the TLMs now 100% focused on programming.
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.
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...
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 ;-).
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.
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.
TLM role has always sounded like a trap to me, I would never say yes to it personally. I’m sure it’s sold as an expected 50% code, 50% management but everyone I’ve talked to who has been near it says the expectation is more like 80% code 80% management.
TLM roles are a trap, but not in that sense. There's no expectation that you do two jobs at once.
It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time.
Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those managing dead-end projects on dead-end teams; or those who desperately cling on to the engineering past and actively refuse to take on more people. From a corporate point of view, none of these situations are great, hence the recent pushback against TLM roles in the industry.
> There's no expectation that you do two jobs at once.
I laughed out loud when I read this. I've never seen anyone at any company in a hybrid tech/manager role that wasn't expected to do two jobs at once. Or at least they felt like they were, which is still the same problem.
80% coding & 80% management for that role sounds about right.
I've been in engineering, TLM, and management roles in multiple companies. In terms of output, TLMs are not held to the same standard as full-time engineers at the same level, period. Their engineering contributions are dissected only if their performance as a manager is in serious doubt.
In any role, there are some folks who push themselves too hard, and there is no one to tell them "stop", but that's their choice.
Management requires a birds-eye view of the project in all its breadth, and quickly responding to issues, as well as reporting up (proactive stakeholder management).
The job of the manager is to keep the CXOs happy (inform/manage expectations) whilst protecting their own team so they can focus on getting their work done with minimal disruption (isolate).
Coding requires the opposite, zooming deeply into the code and retaining focus.
The job of the IC coder is to deliver (design and implement) beautiful and pragmatic architectures that do what is expected.
I recommend anyone to reject to fill roles where these two are combined into one. Note that this is not a comment about workload, but about irreconcileable differences. (The perfect candidates for each even match different personality profiles...)
As alternative explanation, even if there's no pressure to do so, the thing is these people came to do dev, and probably enjoyed their job enough to get recognized for their work.
So when asked to split between dev and management, outside of a few exceptions they'll want to do 80% of tech by choice. But the management part doesn't go away of course, so it will still be at least 50% (and 80% if they want money, because that's the part they're actually evaluated on)
I've been a TLM at two big companies and in my experience there was no expectation to do two jobs at once - I did majority of management with very very little hands on coding. More like frequent pair programming with more junior staff, code reviews etc. My last manager told me explicitly when I started - there is zero expectation on you to do any hands on work, you need to make sure your team performs and keeps going in the right direction first and foremost.
Usually it means you have to manage people but you have no real input on their career trajectory, and in the worst case, if they need to be fired you do not have the power to do so.
This was my experience in a TLM role - you have to manage down to your ICs but you have little lateral or upward power. You're basically just conveying whatever your manager decides to do with your team, but with all the additional responsibilities of a staff engineer.
In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.
> If you don't suck at management, your team inevitably grows
Inevitably because why?
> those who suck at management
If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
> those managing dead-end projects on dead-end teams
If "dead-end" just means "not growing" then that sounds fine. When a company does thousands of things only a small fraction of them need to be growing.
> those who desperately cling on to the engineering past and actively refuse to take on more people
"Desperately cling" is a wild way to refer to someone sticking with a job they like. And if they're a TLM it's not the past, it's the present. Wanting to keep your present job is very normal.
And is the end goal to have zero TLMs in this expanded team? If you're going to pick new TLMs to go under the one you push into higher management, what's bad about leaving them in place and putting someone else above them?
Look, I'm trying to describe reality; you seem to be expecting me to defend it. But briefly:
> Inevitably because why?
Because proven, effective managers are always in short supply, so when you hire new people, or if any of the existing managers leaves, it's the default pick.
Plus, most people want to make more money over time. And on the management track, this means angling for that director / VP role down the line, even if it wasn't your childhood dream.
> If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
They can, but in big and / or growing companies, performance problems are addressed less vigorously than they probably should. This cuts both ways: neglecting problems is wrong, but cutthroat performance management makes people cranky too.
I mostly found TLM a disservice to people who reported to TLMs. They didn't have to earn a promotion as both an engineer and a manager at the same time, so many optimized for their own engineering promotion and any managing they did was out of the goodness of their hearts.
As a devil's advocate (I don't work in Google or in a similar role) but if the requirements for engineering promotion are similar for technical managers and engineers, while the first have to manage people then this is just how the system is set up. In this case I think blaming the system more than people is justified, and Google decided to dismantle the role for some reason.
This has largely been my experience in TLM roles. You’re a staff/principal level engineer so people still expect outputs from you. However, you now have the job of managing your teams’ impact and outcomes as well.
Impact and outcomes are far more important than outputs, so it makes sense to for you to spend a lot of time on that. But, when performing review time comes around, you’re still bounded by hard metrics around outputs.
When you become a good enough IC, “ As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.” is no longer reasonable. Then your managers role is to maximize your ability to make an impact by putting you in the right place/project.
As a manager of people who know far more about the things they do than I do, my goal is to assist and ensure in the right place (for them and the org). It’d be foolish for me to hire peons who know less than me.
Not sure why you'd take the leap from the idea of technical people managing technical people to "hiring peons who know less than me", that wasn't my intention. Also "as an engineer" was rhetorical -- I'm a manager myself and it's been over 15 years since I've been an engineer. So I do see the point you're trying to make. I still feel the immediate management layer above mid-level ICs should have some level of hands-on knowledge of the system they're developing. At the next level up, I think engineering fundamentals and past technical experience would suffice.
GP made the point that early in your career, your boss should absolutely know more than you do about your technical work, but at some point (fairly early), that inverts and your leader unavoidably knows less than you do about your technical work, because you’re the expert on the team at it and they can’t know more than all 5-8 of their reports like you can when leading 3-5 junior/new devs.
In post 1, you want your lead to preferably know more, someone says that’s not realistic, and in post 2, you profess to not understand their point while changing the goal post to now be “some level of hands-on knowledge”, which sounds like you do understand their point.
TLM is fine. TPM is the awkward one. I don't understand what hierarchy (if any) there is to TPMs, they kinda float around and ask people to do stuff. Some projects get passed around to different TPMs like hot potato. The skilled TPMs stick around and make things happen, but even then idk how that works because they lead people without having any actual reports.
That is the point of a TPM. They're supposed to be the neutral third party that makes sure you're doing the work, and can explain to upper management why the work is not getting done. As such, they don't have any decision-making power on what the work is or how long it's going to take. Generally the manager and IC negotiate back and forth on what needs doing and on what schedule, they set their own deadlines based on the realities of the project, and then the TPM holds them to what they committed to.
Much of the reason the TPM job exists is simply so your manager can be an advocate rather than a nag. The nag job is offloaded to the TPM, but the TPM has no decision-making power, so you don't get perverse incentives where the manager burns all their relationship capital making you do your work, or sandbags the deadlines so they don't have to.
In many orgs TPMs are also in charge of goodies like fun events or device/swag distribution, as a way to offset the negative emotions that come from them basically being nags.
But were all the other managers in the team in a TLM role?
The problem I foresee here is, there would be escalation meetings and all the non-technical managers would sit back and point fingers at the TLMs until they leave.
It sounds to me like Google is moving to a more typical "technical lead" model where leads have substantial authority and some mentorship responsibilities, but they're essentially an IC and someone else up the chain actually handles proper management. Informally, tech leads can gently chew out less senior devs, but if someone actually needs to be disciplined then the lead needs to talk to the manager.
TLM is an odd role. I understand big tech companies have their own culture but it does seem like a poor management strategy regardless of efficiency.
The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers.
Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people.
But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
> But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done.
A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles.
At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in.
I’m a staff engineer.
Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
> Being very visibly anointed by some VP helps, but that's essentially tapping into the exec's leverage - an illusion of IC influence.
Of course that’s the play. Even a lind manager can’t get major initiatives through without getting the buy in from their manager. When I was working for startups, the director (1st company I had influence at) and the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
Fast forward past BigTech to where I work now - a third party AWS consulting company, after convincing the powers that be of the market, I had it escalated to be one of the companies initiatives for the year.
But more so in BigTech, promotions aren’t completely on your manager. At least at AWS you had to have recommendations by I believe two or three people one level ahead of you and it had to go through a committee.
From talking to a couple of L4s that I mentored when they were interns and when they came back, they were both complaining about the promotion process even though their manager supported them.
> the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
But that mean those people have the power, not you. Without that formal power structure you wouldn't do so much work trying to convince these people, the formal power structure forces everyone to try to manipulate and work with it, even you.
So it makes it so much easier to do anything if you are that high up person, imagine that was you, now instead of having to convince these people to do it now you just do it.
Power structures exist in any group of size. Companies can choose how formal to make them, but they can’t avoid them.
Imagine instead of having to convince the Director, VP, or CTO to support your good idea, that instead you had to convince 100 out of 700 people to support it, while at the same time, those 100 people are hearing good-sounding ideas from 99 people who aren’t you.
I’d way rather work in the former than the latter.
Eh, maybe at faangs or at the executive level but at non faangs you might not notice a role having power because most roles with the Manager title are no longer actual managers but supervisors.
I had more agency over where capital was deployed as a teenager deciding how many people were going to be on the shift for closing, then I have making over 200k/yr as a Senior Manager.
Any role that has decision making power over where money goes automatically has a massive amount more power than a role that does not
The article is mostly about first level managers. I’ve never had any “manager” that really has any power over raises more than 3-4% or any real control over budgets.
When I was being hired as a strategic hire for startups - and was being interviewed by the director or CTO - I specifically asked would I be reporting directly to them or another manager. I actually refused one job because I saw that the expectations they had from me and how far I was down in reporting structure was incongruous.
Maybe for faangs. At every company I have worked at with a manger title from 2019 to present, this was expected of people with "director" in their title and below.
You are not a manager if you do not get to decide where capital is deployed, without your boss's approval.
For anyone reading this comment, if you think you are a manager, ask yourself this question
"If I decided tomorrow that the company would be better off if I hired someone to do role {X}, can I open a new req for that role without permission?"
If the answer is no, you are a supervisor with less agency than the a Walmart deli leader circa 2010
I've worked at places where the "senior executives" couldn't do any of these things without CEO approval. Even if they claimed to "have budget" for something, it still needed sign off.
There's tons of title inflation out there, especially at smaller firms.
By make-up I think most TLs at Google had no reports even before this change. The idea of ICs in leadership has always been a common occurrence at Google. If anything I don't really see it as commonly outside of Google.
Yeah, that helps put this in perspective. At first the headline sounded like a somewhat jarring and sudden staff cut, but if we're essentially just seeing Google migrate TLMs to TLs, that actually makes sense.
we had this in my company it was pretty hit miss. Almost always the 'TLM' was someone who was in the role for a really long time and it warranted a second person, so it ended up being a 1-2 junior reporting in absorbing the knowledge that the tlm had.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
I wouldn't actually say that, but I would say that the TLM role works at a very specific stage in a company's lifecycle, and many companies that use it (including Google itself from around 2010 onwards) have long since past that point.
IMHO, the conditions where a TLM role is appropriate are:
1.) You need to be in the company growth phase where you are still trying to capture share of a competitive market, i.e. it matters that you can execute quickly and correctly.
2.) There needs to be significant ambiguity in the technical projects you take on. TLMs should be determining software architecture, not fitting their teams' work into an existing architecture.
3.) No more than 3 levels of management between engineer and person who has ultimate responsibility for business goals, and no more than 6 reports per manager. The mathematically inclined will note that this caps org size at 6^3 = 216, which perhaps not coincidentally, is not much larger than Dunbar's number.
4.) TLMs need to be carefully chosen for teamwork. They need to think of themselves as servant-leaders that clarify engineering goals for the teammates who work with themselves, not as ladder-climbers who tell others what to do.
Without these, there is a.) not enough scope for the feedback advantages of the TLM structure to matter and b.) too much interference from managers outside the team for the TLM to keep up with their managerial duties. But if these conditions are met, IMHO teams of TLMs are the only way to effectively develop software quickly.
Perhaps not coincidentally, these conditions usually coincide with the growth phase of most startups where much of the value is actually created.
I assume you're referring to my other comment, since I didn't mention my team size in this one.
I'd love to say that the answer is "because I'm a good manager", but I think that the real answer is "because there was money=headcount available, the layers of management above me successfully presented our value and inflated our needs enough to convince a VP to give it to us, and my own manager physically did not have enough hours in the day to have 1:1s with all the new incoming headcount without introducing some layers of management under us". If it weren't me, it would've been some other manager. For that matter, I wasn't a manager when I joined the team, but I was interested in managing and of sufficient level that I could pass department policies, so I ended up more than doubling my team size within 6 months of becoming a manager. The team was pretty busy for the first year or two after that - we'd gotten all that headcount by arguing that we were critical to some big strategic initiative, after all - but there were long periods after where we were oversized by a factor of about 2, so I just let everyone work 20 hour weeks and phone it in until the next big project came.
The more time I spend in the corporate world, the more I become convinced that success is a matter of meeting the minimum qualifications, bullshitting, saying yes to opportunities created by people who are themselves bullshitting, and doing the minimum amount of work needed to avoid being called on your bullshit. Businesses don't hire because they actually have work to do. They hire because they have money and money=headcount and headcount is the only way for a manager to get promoted or pad their resume.
I passed on a similar opportunity, kept the team small. This was back in the pandemic when headcount flowed freely. What you describe sounds about right. My experience is that having a capable team goes a long way creating those expansion opportunities.
only if you're cynical, google found a much better solution though, make them IC's again and redistribute the junior talent to places they can grow and offer buyouts for anyone who feels like they're not into it anymore.
I am cynical. Better for what? I can only interpret moves made by large companies across the board as ways to move the stock price and consolidate control.
If your position has no upward mobility juniors will change jobs, likely change companies, once they have the experience and all the effort you spent training them will be wasted.
Statistically you should charge companies. Even if you get promoted, you’ll make less than someone hired in at the same level. Even if you like the company, it’s best to “boomerang”
Its tricky to use statistics for personal decisions. In general something might be correct but not for your specific subgroup. I know many people who changed for worse.
If you are in a bad position then change, but if you like the company and role, don’t take it for granted and think carefully.
This advice is consistent with the broad statistic if more than half of the sample is currently in “bad position”.
Since we are talking about BigTech, I can’t imagine to a first approximation any IC up to and including senior or a low level manager being at any BigTech company for a reason besides wanting to maximize their income via cash and RSUs.
Does anyone stay in the same position/team for more than two or three years even at the same company?
The U.S. military actually uses precisely that system for officer promotions. And in practice most of the U.S. military branches do essentially the same thing for their enlisted force too, deliberately allowing high attrition for the sake of frequent promotions.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
This kinda brings up a question I've often thought about. Why is it that we structure growth in a company to be so biased towards moving into management roles?
I mean there is the obvious part of the answer in that managers are the ones that are given the power to define that growth ladder, but I'm not sure this fully explains things. If people are transferring from technical positions to managerial positions then should they also not be aware that there is a lot of advantages to allowing people to keep climbing the ladder through technical positions? That institutional knowledge can be incredibly valuable. It's often what leads to those people being such wizards. They've been with the code for so long that they know where things will fail and what are the best parts to jump in to make modifications (and where not to!). But every time you transfer one of these people to a non-technical role that knowledge "rots". More in that code just keeps evolving while their knowledge of it remains mostly frozen.
Which what you say sounds like maybe the worse end of that. Taking that person with institutionalized knowledge and hyper focusing their capabilities on one aspect. That doesn't sound like an efficient use of that person. Though the knowledge transfer part sounds important for a company's long term success, but also not helpful if it's narrowly applied.
This hasn't been true in a lot of companies for like my entire career. You can move up as an ic. Titles like Staff, senior staff principal. A Staff and Sr manager would be paid the same
> This hasn't been true in a lot of companies for like my entire career. You can move up as an ic.
You can, but it's a dead end ultimately. I've been a distinguished engineer which is about as far as one can go (some companies have Fellows, but it's just a few people so basically impossible). If you have any desire to grow beyond that, management track is the only possibility.
Also, moving to management from a DE level is harder because you're basically around a Sr.Director level (give or take, depending on company) but have no management experience.
If you care about career growth (and I'm not saying you have to, geeking out on the IC ladder is way more fun), I suggest as soon as you are at the equivalent level of a manager on the numeric ladder, switch to management.
do they report to the same level? every place I've seen a "technical track" and "management track" it seems the higher level technical people report to someone on the same or even lower level in management. I.E. a manager can have technical reports that are equal level or higher. that obviously doesn't happen in the management track.
not that these are first level managers but if a principal engineer not reporting to a VP, the it doesnt seem like the tracks are equal.
What do those roles do? Where I work there's a managerial track and a technical track, but if you actually read the job descriptions the technical track is basically either the same as management track, or a devrel role (effectively managing people outside the company).
I think this is a good thing. Every time I've seen people in dual tech/management roles at any company, they've always been incredibly stressed about their job, and always have way too much to do.
I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. Even if your TLM is pushing a bad technology choice, you might not want to push back too hard because they're also responsible for your performance review and comp changes and whatnot.
>always been incredibly stressed about their job, and always have way too much to do.
So, no different from any other dedicate IC or manager at these companies?
>I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there.
How is this different from any other manager or higher up making decisions? If your boss or boss's boss really wants something and you're not in a good market, it's never a good time to poke your head out.
>How is this different from any other manager or higher up making decisions?
Non-technical managers usually don't have strong opinions about which framework or database to use. Among engineers these decisions are usually made in a meritocratic way (weighted by who is the loudest sadly), but if your manager says "let's use X" it has a different weight than if your peer does.
> It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.
The hybrid role idea has always been ridiculous. It's two different jobs, like being a mechanic and an accountant. Do you need a mechanic? Cool, hire a mechanic. Do you only need a mechanic part-time? Cool, hire a part-time mechanic. But I don't want my mechanic stopping and starting the work on my engine 3 times a day because somebody has tax questions.
The whole point behind the division of labor is to specialize, and get really good at your specialization. Picking up multiple very different jobs and trying to do both is the opposite of efficiency. People knew this 250 years ago.
I was a TL and then a TLM in my org, and am now an EM. I'm actually pretty happy about it, personally. I am organizing an eng summit tomorrow between my team and a sibling team (which is onsite and visiting from elsewhere) in my org, and I noticed that about 18 months ago, I would have been the person to give 4 out of the 5 main talks at the summit (as the expert / TL on that system). Now it's five different eng. This tells me I've been able to nurture / elevate the other engineers on the team, get them all into technical leadership roles, and then have them reach out and be ready to talk about their work to other teams.
Overall: this is a good thing. By taking up less room on the technical side, I've replaced one of me with four strong engineers. Previously, I was split between TL work and EM work and as a result, did a half job of each, leaving too much un-done.
The other thing I'll note is that engineers are basically the only role with this distinction. Product Managers, Program Managers, Sales, Marketing, all those roles seem to combine management with seniority. Only on the engineering side do we have both a TL and Manager hierarchy (while typically the TLs for a team report to the same manager that the line manager for the team does, they exert authority differently). This works out okay on the eng side when there is a strong alliance between the TLs and the EMs, but that doesn't always happen.
A recruiter in India was talking to me about some roles for some time and then disappeared. After a few weeks, when I was ready for interviews, I reached back. I was informed that those roles didn't exist anymore. I enquired further asking wahether those roles were filled, and the reply was something on the lines that no, they didn't exist anymore. Bit of a bummer because Google was one of the very few companies here that actually interviewed you pretty fairly even after a considerable employment gap. Those were L7 roles (not sure whether those are around TLM).
Not at Google but I'm in such a role right now and I really dislike it. Can't really get much focused coding in because you constantly have to jump in to review something or help fix something or handle a live site juniors cannot handle, or update some TPS report on what everyone is doing, or some PowerPoint or whatever. I dislike all of these to start with, but getting my own (expected) features in is an exercise in frustration. And when I ignore people and try to have uninterrupted time it feels like I'm neglecting all this other stuff. I wonder who thrives in such a mixed role...
Not OP, but I think TLM works best when it's a transitional role. You have someone you want to groom into a full-time manager, and you have a team that you plan to grow over time. TLM itself is not that efficient, but can lead to strong full-time managers who understand the team really well and had time to grow into the role.
I was thinking this too. Tech lead/developer and manager are two completely different jobs. I can see TLM as a useful transitional thing, while the person is being trained or mentored at being a manager (and hopefully not just thrown into the deep end). But 6 months, max 12, I think. Otherwise it just becomes a role where someone has two jobs and ends up overworked.
It's a rather awkward role as you have to carve out a maker's schedule within a manager's schedule [1]. As others have mentioned, it only makes sense as the person ramps up for full management or decides against that career path.
This is a funny question to me, because my entire career (mostly small companies/small tech depts) I've never reported to an EM. It's only when I moved to big tech that EM-who-doesn't-code became a thing, and it took some adjustment for me. All prior roles had TLs (aka TLM) which led the team while being the expert - aka the "surgeon model" from Fred Brooks' book.
As far as I can tell, the main function of an EM is to enforce the company policy. I'm not sure there really is a need at a smaller place.
As someone who has worked in companies from <30 to >100k, I would say that what an EM does is more about communication. Think of a company with m employees as a m by m matrix, with a 1 where there regular communication and a 0 where there is no communication and a 0.5 for those hallway meetings which our CEO's assure us are why RTO is so important.
In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."
Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project."
Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out).
But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.
Thanks for this message, this is actually helpful :).
I have been a TLM/EM for the last 4 years, and I still struggle at times to define what my role is about...and in downtime moments (which are rare, most of the time, you are overloaded), what the fuck should I spend my time on.
Former TLM that was involuntarily reclassified as an EM because I had too many reports. I'm from old-line (pre-2011) Google, so was an engineer back when the TLM role was one of our unique competitive advantages.
I have a lot of thoughts on this. IMHO, it's appropriate for the state that Google is in now, where it is a large mature conglomerate, basically finance & managerially driven, built around optimizing 10-K reports and exec headcount & control. It's not a particularly good move from the perspective of shipping great software, but Google doesn't really do that anymore.
The reason is because software construction and management is unintuitive, and concrete details of implementation very often bubble up into the architecture, team structure, and project assignments required to build the software. TLM-led teams have a very tight feedback loop between engineering realities and managerial decisions. Your manager is sitting beside you in the trenches, they are writing code, and when something goes wrong, they know exactly what and why and can adopt the plan appropriately. Most importantly, they can feed that knowledge of the codebase into the new plan. So you end up with a team structure that actually reflects how the codebase works, engineers with deep expertise in their area that can quickly make changes, and management that is nimble enough to adopt the organization to engineering realities rather than trying to shoehorn engineering realities into the existing org structure.
Now, as an EM with 10+ reports, I'm too far removed from the technical details to do anything other than rely on what my reports tell me. My job is to take a slide deck from a PM with 10 gripes about our current product, parcel it out into 10 projects for 10 engineers, and then keep them happy and productive while they go implement the mock. It will take them forever because our codebase is complex, and they will heroically reproduce the mock (but only the mock, because there is little room for judgment calls in say resize behavior or interactivity or interactions with other features and nobody's holding them accountable for things that management didn't have time or bandwidth to ask for) with some hideously contorted code that make the codebase even more complex but is the best they can do because the person who actually needed to rewrite their code to make it simple reports up through a different VP. But that's okay, because the level of management above me doesn't have time to check the technical details either, and likewise for the level of management above them, and if it takes forever we can just request more headcount to deal with the lack of velocity. Not our money, and it's really our only means of professional advancement now that product quality is impossible and doesn't matter anyway.
Ultimately the value of the TLM role was in that tight bidirectional feedback between code, engineers, and management. As a TLM, you can make org-structure decisions based on what the code tells you. As an EM, you make org-structure decisions based on what your manager tells you. But at some point in a company's lifetime, the code becomes irrelevant - nobody reads it all anyway - and the only thing that matters is your manager's opinion, and by transitivity, your VP's opinion. A flattened org structure with as many reports per manager as possible is a way for the VP to exert maximal control over the largest possible organization, mathematically, and so once that is all that matters, that is the structure you get.
I can't say for Google, but at work it's more or less how it works at the office (mostly software dev, half a team does some firmware/hardware), but it's more ad-hoc than as a rule. Like all the teams are small, all the TLM equivalents started as devs before being promoted to their management position, so they have time to do some technical work; how much and what technical work depends on the team, some are still directly contributing to the team's products, others are more on (technical) ancillary tasks, which can be interrupted by management questions with less impact on the development.
I find that it works well, the TLM keep a foot in the action, so to speak and has a better idea of what's happening with the product being developed, what issues we're facing (also in terms of tools, environments...) and it keeps their knowledge of the product more up to date. Of course with their background, I wouldn't say they are all the greatest at managing, but I don't think they've ever done big mistake on that side of their role. So in short in our case it works, but it could just be a consequence of the local organisation and people working there.
10 is a lot for a first time manager, but too few reports is also bad for a new manager. 4-5 direct reports is probably the sweet spot where you actually get some experience and the team is big enough that interpersonal stuff averages out.
speaking from personal experience, it's not that good to have TLM as your manager because in some ways you're competing with your manager on technical scope, and you'll lose
The is funny to read because it captures my feelings on this exactly: when you're a company of passionate people driven by a mission from the top down (very important this alignment is genuinely top down), the drawbacks of the TLM-like position are totally workable: the org gives some grace and flexibility to everyone involved knowing that the TLM is sacrificing some effectiveness as an IC, those under them are losing some room for direct impact. It all works out as long you're able to "grow the pie" and make up for the smaller slices by executing.
Once you're late stage though, that's done. TLMs are probably being held to 100% of IC standards and manager standards, people under them are jockeying for "impact" and don't want to compete with their manager, etc.
I totally see why it wouldn't work at today's Google. Honestly maybe it's a positive sign they recognized that.
I think the idea of a leader on the line makes alot of sense. Someone should represent the work and be able to navigate the hierarchy. These types of roles always exist informally anyway.
There’s always a downside to anything, and the merits/demerits are all about the politics of the org.
I'm essentially in a TLM position currently. We're a small company, with a small codebase. I oversee three junior to mid-level developers, and I represent the team in our product/roadmap planning process. I also write a lot of code, review a lot of code, and make a lot of architectural decisions. At our current scale, and with our current resources, I think it works pretty well. Moving fast is one of our biggest priorities, and having a TLM definitely reduces overhead versus a more traditional separation of responsibilities.
I really never intended to have a management position, but this has been an incredible opportunity to experience a portion of it without fully committing. Other replies have described this as a transitional role, and I don't think they're wrong. In the long term, especially if the company grows, I can probably be more valuable by committing to one path or the other. However, for the right person and situation, I could see us minting a TLM again, regardless of size.
Doesn’t work when headcount stagnates because the teams never grow to full teams and the junior reporting engineers eventually become peers in a too small team.
Simple as that. It’s fine during times of growth but that’s not happening right now.
The value of that kind of role is that the person interfacing with the bureaucracy and the business hierarchy and its many demands also actually does the technical work and knows things about what they are working on.
Without it, nobody on the management side of things actually writes any code, or has first-hand experience with working on the product. The line managers just end up as a go-between between the workers and their directors, because they only know what their reports tell them. They don't know much for themselves.
You can't quantify this sort of loss on an earnings report, but among many other things, it does a great job of diluting ownership of the product away from the teams working on it.
TLM role was both the best and worst role in tech.
Best in that the TLM generally has complete control over the product execution (and can commonly bulldoze the PM). It's amazing if you have a solid vision of what you want and you want to get it done.
Worst in that the workload can be intense as the team grows.
> This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers.
Ohhhh this explains so much. My career is pretty much entirely at b tier companies who try to implement what faangs/mag7 type companies do but always fuck it up because they don’t understand the fundamentals or are unwilling to part with any of amount of power or money even if they got more after all was said and done.
Anyways post covid all of a sudden every company was expecting me as part of the Software Engineering Manager roles I was getting, to have 7-10 direct reports, do 30 hours of project management per week, _and_ simultaneously be better versed in every single project my direct reports were working on or at least be the initial architect for the project.
I just ignored it and kept my people productive since that was an impossible ask of me, and for 5ish years that was good enough for companies but I guess if the faangs are wiping that role clean I better switch career niche again
We did something like this but called it a different name. It was absolute garbage. Its really no surprise to see those roles move back to a more traditional alignment.
Managing skills and techlead and IC skills are pretty different disciplines.
Being 50/50 makes it hard to advance/develop in either one of them significantly.
The biggest issue is that management requires a lot of "wasted time" paying attention to whats going on around you and IC skills require a lot of "heads down time". It's a big fight between those two modes.
I've done it at a startup but it required doing most of my IC work after hours. Which isn't that sustainable.
It was terrible because the "managers" had very little training which made them mostly useless and a legal liability to the company in regards to employment law cases. In many instances they weren't even on the same direct team but an adjacent team, so rhey hahd very little interaction. This completely invalidated the premise that a technical/coding manager would be a better mentor since there was never any time for it. Of course the company paid them the same rate as the senior devs that weren't managers. I'd say at least 50% of the first year cadre left the company or reverted to a regular senior dev after one year or less. Most divisions of the company don't use this model now. The only real reason they did it was because Google did it.
It’s the only point in one’s career where you’re expected to do both programming and managing and it’s hard to do both at the same time and at a good level.
Having worked in organisations of various sizes, my observation is that the network effects issue rings true, and large companies feel horrendously bureaucratic.
I had one Engineering Manager joke that his year at Volvo Cars had been one long meeting. Even the then-CEO at the time complained about the number of meetings the company held.
I also remember a tale from a colleague in a startup that had come from a much bigger company talking about how colleagues in India were asking for promotions or pay raises every year. Why? It turned out the colleagues in India had strong expectations from their parents to consistently be progressing in their career, hence they had to show progress in the form of being promoted or having increased salary.
What did the company do? They started creating job titles to essentially create the impression of being promoted without much changing in terms of the day to day job.
It seems like a kind of inflationary effect on organisation structures, where you solve one issue but potentially create other issues, namely bureaucracy.
First they laid off the non-technical employees. As a big tech company, Google needs to focus on coding. But that wasn't enough, so they laid off the middle managers in charge of coders. As a big tech company, Google needs to focus on coding. But that wasn't enough, so they laid off the low-level managers who were the domain experts on each product. As a big tech company, Google needs to focus on pure coding, and anyone who isn't doing 100% coding is extraneous. But, that won't be good enough, so next they'll lay off the senior engineers. As a big tech company, Google needs to focus on coding, and senior engineers spend too much time doing "architecture" (whatever that means). But that won't be enough, either. So they'll lay off the regular engineers, too. As a big tech company, Google needs to focus on only the purest coders, meaning junior engineers who don't actually understand the product (understanding the product considered harmful). But that won't be enough. So they'll lay off all of the juniors and only keep one guy named Greg who will adopt the title "webmaster of google dot com" and rewrite the whole thing in PHP. Then this big tech company can really prosper!
Google is probably doing what everyone else is doing. The entry level managerial positions are being eliminated by pretending the people doing the work are not actually manager and are therefore paid less.
It’s reached ridiculous proportions in some companies I have worked for. I have seen transversal project managers and delivery leads in charge of up to 80 persons sometimes with an intermediate level of management actually reporting to them but not directly attached to them be paid as IC.
It gets even more funny because some positions in said companies doing a lot less management but occupied by people who suck up a lot are actually considered managerial.
Most modern big companies are completely f* up. The only reason we don’t see more disruption is regulatory capture.
The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
If you oversee 0-2 people, in most cases that’s probably not an efficient ratio. How did Google get so many folks in that position in the first place? And I assume the other 65% take up the slack to fluff their teams? Or what? Leave the other 65% managing 0-2 people?
For a team that size, you would assume the manager is only spending around half of their time on people management and probably around half their time working directly on whatever the team does. It can be a good arrangement if the goal is just to give a little more leverage to the manager, but it's also equally possible that the manager doesn't have time to do anything particularly well. Also, a lot of time a part-time line manager like that won't have enough organizational clout to look out properly for the team.
Having tried that arrangement a few times, I think it's better to have small pods where everyone is an engineer and then all the pods report up to a dedicated people manager.
From my experience: re-orgs and limiting backfills for attrition can lead to these awkward states. Someone starts off with a sensible number of directs, but it can devolve over time.
IMO, overseeing 0 people is great. I'm not likely to take any position where I have to oversee more or less than that; although I'm willing to compromise and oversee one person where they're actually independent and I don't have to do much overseeing.
Overseeing 0 people is great if your role is an individual contributor. If your role is a manager and there is no one for you to manage, it would seem that your role is redundant.
When I started, I was told that one of the easier ways to get promo at L5 was to become a manager. I don't know how true that was at the time, but I think this could be a consequence of that sort of local optimizing. I think now they don't even allow you to be a manager at L5 unless you're grandfathered in?
Search and ads, at least, had the L6 requirement for manager going back as long as I’m aware. I was under the impression that the requirement was relaxed at some point in some of the less revenue critical orgs, but that the L6 restriction actually goes back a long way.
FWIW I was L5 manager (on the SWE ladder) in two PAs. The L6 requirement did exist but in my experience was quite soft. All that my management had to do was justify to the VP that I was capable of doing the job and would soon be ready for promo to L6 (though the first org got nuked and the promo took a long time).
Not a Goolger but my experience is that this is usually an optimistic promotion where someone is made a manager with the expectation of growing headcount later. But later never happens, or coincides with turnover to the degree that they never bubble up to a decent span of control.
Sometimes there are products where 1-3 people is the right size of team for that product; letting a team that size exist can be better than trying to smush together two or three unrelated products to fit a bigger team. Per other comments these are TLM positions where the manager is also expected to contribute technically.
In some circumstances it can be an effective way to lose efficiency in exchange for velocity- basically there are large tasks that can’t be developed by a team any faster than by an individual ( mythical man month) because they are fundamentally sequential not parallel. In these cases there are often parallel subtasks, so you can buy some speed by having one individual forging ahead as if they are the only one on the project, and then rope in the team for parallelizable subtasks. Instead of any amount of decision-making or communication overhead, everyone jumps when the team lead says jump – this is the step that bounds performance to not be slower than a solo project.
Being the team lead in this sort of structure is grand fun, of course, but being a team member is brutal on the ego, and requires enormous skill to be a boost to velocity instead of a drag. Thus, it requires ridiculous compensation, even if you’re mostly sitting idle when the project is in a serial phase. it’s the sort of play that I could believe 2012 google could profitably execute and 2025 Google can’t.
Fewer than 3 people? That almost never makes sense. Right on Google to sort that out but I’d have a lot of questions for whatever leaders allowed such nonsense to develop on their watch in the first place.
Also 35% is way too low if it’s really less than three. Should be more like eliminating 95% of those scenarios.
The article says they were converted to ICs so these were TLMs or similar people. It sounds like the headline is clickbait and what's really been eliminated is small teams.
In certain types of company, it's workers without management responsibilities who do the work that brings in the money.
Think of a delivery company, for example, where drivers make deliveries, which is what the company gets paid for. Too many managers - AKA too few employees per manager - will sink the company, because managers draw a salary but don't make deliveries.
Of course, this analysis might not work as well for a company like Google. I'm pretty sure I can publish an ad without any human intervention on Google's end, so maybe they have no equivalent to the drivers, making the ratio incalculable.
I guess it depends on what other responsibilities the manager has. If a manager has too little to do, they might over-manage their small team, constantly checking in on their work, which is inefficient and demoralising.
Imagine you have a cohesive system that has 10 services, each service requires 1-3 people. The head of the system can assign 10 tech leads responsible for the overall quality of the services or they may have over 20 direct reports, most of whom have nothing of interest to report to the higher-up.
It’s that semi role of being a “manager” while still writing code. They’re just doing away with that role and having dedicated people managers and dedicated engineers.
Around 5 is the correct number for a first line manager of a technical team. Go to 10 and it’s impossible to keep track of things. The day has only so many hours. Managing takes time.
For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
> Go to 10 and it’s impossible to keep track of things. The day has only so many hours. Managing takes time.
I've actually had better experiences with higher employee:manager ratios for this reason.
When the manager can't possibly be involved in everything they're forced to let go, delegate, and skip the management busywork.
My worst experiences have been at companies with one manager per 2-3 employees and skip-level managers who were expected to be involved as well. It was a never-ending stream of meetings, weekly hour-long 1:1s with multiple people, goal setting, personal development exercises, and a growing list of scheduled distractions.
The managers felt like they needed to make work to justify their managerial roles, so our time got filled with meetings and activities that didn't contribute to anything other than making the manager feel good about doing things they heard about in podcasts and books.
Same. With so few reports, those "managers" don't have much to do, so they invent nonsense and start aggravating the actual people doing the work. In one case, the guy was totally not receptive to my feedback about the performance issues of other team members. "I'll talk to him."... and literally did nothing. I was more experienced than everyone on the team, including the "manager." He's gone now.
This is my experience as well. I currently have two managers for a team of three people. One manager basically wants nothing to do with us, and the other wants hourly activity reports that I'm fairly certain he's never looked at.
At that ratio a technical manager should be first on every code review, should be testing the hell out of everything, and should be sitting in design reviews catching bugs well before they hit the IC's plates.
Every time I see manager with 5 people I know it will be daily 30m standups, friday “summary” meeting, weekly 1:1 and other nok work related activities. If team of 5 people need a babysitter fulltime it means there are no adults on that group.
No, 5 is about ideal. If you are micromanaging with that many people on your team then you are neglecting other aspects of being a manager. More than about 7 and you start being unavailable to your team when they need you, and won't have time to do the planning and process tasks.
That's been the mantra in the tech world for at least a decade now, and I've grown to really disagree. Managers should have 10 at minimum. Most should have 15-20. They should specialize in being a manager and shouldn't be solving problems except pure management problems. (Good) teachers easily manage classrooms of 10-30 kids, even in private schools. The low direct report count ends up creating managers that have too much power, too much say, and too much time to mess around.
> For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
that described internal Apple hardware teams i was on for years, as having as flat as possible an org was a priority to prevent bureaucracy and fiefdom forming middle manager nonsense
I've never directly reported to someone who had that few people reporting to them. Team sizes of ~5 work well but managers can have multiple teams. They don't need to be involved with most people on a day to day basis.
Im convinced the big tech firms are so overly bloated simply because they do not possess high-quality leadership at the top who are able to clearly distill a vision of where they want their sub-ordinates to go.
That's not to say it's easy - its absolutely not. But Apple is living off of Steve Job's visionary prowess and continues to do so.
I agree. What's worse is, the upper layer and middle layers of management are filled with bozo's looking out for their own interests and have no desire to find those with potential and hone them.
Business school is a terrible proxy for future business leaders.
It boggles the mind how these firms have bloated to the size they have - it's the cost of ill-disciplined management from the top.
> The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
I wonder why these people are made managers in the first place. That too this kind of title seems quite prevalent in the company given they found 35% of all managers are like this. Either the statistic is just plain false or google is really dysfunctional
Honestly as an outsider this is the not the most important role for them to have eliminated. I have interacted with google a couple of times in the last few years and the company I work for are considered a priority account that they want to do more business with.
In every meeting, they put forward one engineer (who is usually quite capable) and 6 or 7 spreadsheet-trackers who all come from McKinsey or straight out of MBA school and seem to have no function other than to consume the oxygen in the room. Every meeting another one shows up and introduces themselves as being the person in charge of the relationship (this has become a running joke between me and the CTO).
At one stage I stopped going to one of the weekly meetings that these people put on my calendar so the guy called me up to ask why. I explained I got no value from the meeting as all the meeting was for was so he could read through a spreadsheet that everyone already had shared so if I was interested (which spoiler I wasn’t) I could just read it for myself and didn’t need a 45min meeting. He was most offended and disappeared soon after to be replaced by some other person who introduced themselves as the head of the relationship.
So in short if they get rid of everyone on the client-facing side who describes themselves as head of some relationship they would cut a lot more dead wood than TLMs.
Managing dev teams is a tough job and I respect the ones who find a way to add value.
The good managers I know have been good in spite of all the incentives that surround them. The rest have mostly been going with the flow and responding to the environment they are in, and the result is usually a whole lot of upward management and little real value—just more TPS reports delivered on time.
Note to the publisher: when I was about 2/3 through the article the article disappeared and I was scrolled to the footer. When I scrolled back to the top there was only the title, key takeaways, and about 3000px of Taboola. Bad form.
I'm curious, what did the management part of the TLM role entail?
As someone who used to be an engineering manager, I was always surprised at how inefficient the division of responsibilities seemed to me. I mean, when I was an eng. manager, a substantial portion of my time was just taken up by logistics - like when we did a move to a new office building, a huge time sink was stuff like seating charts. Perhaps a company as big as Google has more folks taking care of stuff like this, but I still think the following breakdown makes sense:
1. A "technical mentorship" role: someone who codes, but is also explicitly responsible for skills growth and technical feedback of ~5 junior engineers. This person would not be responsible for stuff like salary/raise negotiations, promotion decisions (but would obviously feed into that, more on that below), logistics questions, etc.
2. A "directing manager" (obviously that name kind of sucks, but I didn't want to confuse this with other "director" or "manager" terms). This person explicitly does not need any technical skills. They are responsible for all logistics/salary negotiations, etc. They would be responsible for around ~5 technical mentors, so then up to 25 people under that. Promotion decisions, for example, would be made amongst the 5 technical mentors, deciding who on the team is most deserving to move up. But then the actual salary decision would be made by this "directing manager".
I'm sure this could be tweaked, but the overall idea is to separate technical vs. non-technical skill sets more efficiently.
I thought the same thing. Some of the commenters said this move might be related to stock price or appeasing shareholders, so I wonder if that, too, was directed at them, as in “we’re big and we plan on getting even bigger”
Good riddance. 7 years too late. I worked as a Google Cloud consultant for a major part of my career. We had this really large client, we were bleeding money because one of our ex-employees promised the client a cost reduction strategy that was impossible and I took over his role - literally a hot seat. We walked into Google's office, it was fantastic, they had something like 12 cuisines in the dining area, multiple game rooms with Table tennis and all. Sleeping rooms, you name it. It was more of a 5 star luxury resort experience than anything.
We walk into the meeting room, past the employee desks, over 50% of it was empty. I asked one of the colleagues showing us around where they all were - "they just work when they like!". Wow, what a dream! Google has/had? this rule where you can take some 20% of your time in a given day for yourself. But, mostly people used something like 40% of it in reality. I thought this was the perfect working culture with great work-life balance. I had very high expectations for the employee quality until I met the TLM and his team we were supposed to meet.
What a bunch of clowns. They suggested we use Cloud Spanner - one of the most expensive offerings at the time and our bottleneck (and bleeding) came from legacy MySql. He didn't even know that Spanner was more expensive than their Cloud SQL offerings, not to mention completely different offerings (it's No-SQL). None of them even knew when to use Spanner for and when to stick with SQL for. It was their own product line-up and we had more knowledge than them! I didn't pass any GCP exams even, at the time. That was the funniest part. We just needed help with some re-architecting of the client's application on a legacy PHP-MySQL combo. They didn't even have suggestions on what stack to migrate to! No idea whatsoever and they tried to talk their way out of it. In the middle of the meeting, my boss leaned over to me and told me "Neya, I think you probably know more than these guys, let's leave" and we wasted no time. To Google's credit, they did offer us some credits to use, but it was far too less than what were bleeding.
I went back to office and out of curiosity searched for how much these guys make - It was easily 120k - 250k (back then) depending on their experience. That's when I literally stopped trusting Google with anything at all. I could never be that laxed when I take that much money from anyone. Later, I learned a lot of these people were just there because depending on the country, you had to maintain a quota (ratio) of certain demographics within Google, most of the TLMs and their teams just conveniently fit into that. Why fix something that's not broke, right?
The Google we knew with the original startup culture was long dead and this story is atleast 7 years old now. For over 5 years since then, they did nothing but make money by simply increasing prices for GCP offerings. I remember our costs rising up suddenly after they just pulled the rug on us with Cloud storage price increase at random. No innovation, nothing. The AI mode they launched now after ChatGPT took the market by storm was what should've been 5 years ago. They are following the pattern exactly as described in the book we learned in our Masters' - "How the mighty fall" (really good book) and well deserved. You reap what you sow.
7 people with one manager seems fine. It could go up to 10 maybe, but that's just my own vibes.
7 layers thick of management feels like too much to me. You'll get a company full of professional middle management who's jockeying define the company culture and strategy. Is that the point? Vibes seem off though.
> 7 layers thick of management feels like too much to me
Yeah, so having more than that was banned. They didn't say you need 7 people between employee and CEO, just that there shouldn't be more than 7 people between them.
When you ban something you want to allow reasonable levels so you take a reasonable level, pad a bit, and ban that unreasonable level, so you agree.
But, also note for large companies, like 100k people, you need around that many layers or managers will have too many people to manage each.
I never really understood the concept of small teams. Managing a small team really does not provide the scale and benefit that a medium to large team does. Lost bandwidth of manager of said small team or extra salary of the same manager seem like something the company could use in other places.
But often such teams in faang come up as a by product of someone’s empire building and that is unfortunate for others involved in it.
The lead is also doing a lot of the regular dev work. Their work is small and self-contained enough that it doesn't need more headcount but also doesn't make sense to merge into another team.
I could even see there being a 1-person team, but their slow tooling and red tape creates the need for extra headcount.
can someone with experience doing this shine some light? i have been offered this type of role from engineer to 50/50 (as i feel it) or 80/20 (as they say) IC and managing. in a series C startup. i feel like it’s never good to context switch. i never seen a tech lead or manager who did well both roles at once. am i crazy to think that the tech lead or manager role should be 100%? either go the IC track or the manager track. but i lack evidence to substantiate this idea of mine.
I’m in this position now. The longer I’ve been in it, I’ve come to realize can be summarized as:
You experience some the benefits of being a manager but bear all the responsibilities of managing others. It becomes challenging to make sound judgments when you must consider two different perspectives of a problem. Essentially, you’re taking on the duties of two jobs. I’ve found it incredibly difficult to step back and allow the team to make decisions without my input. My technical bias compels me to intervene when I perceive a decision as clearly incorrect. However, this approach hinders growth and may be perceived as micromanagement. While it’s a challenging position, it’s an excellent opportunity to explore management and determine if it’s a long-term career path you’re interested in.
At early startups where people are focused on building and you have self motivated, mostly senior+ engineers or hands-on founder types, the 80/20 thing can work. The problems happen when you bring in a lot of other roles, less experienced folks, and more and more distractions build up. The 80% will become more like 30%.
Will be worse when they "scale up" to funnel a larger fraction of revenue to shareholders (directly or indirectly by accumulating a larger hoard) by paying less people to provide the same service.
Fewer managers with fewer direct reports seems impossible. If you eliminate managers, then the remaining ones will naturally absorb the direct reports. So one of these cannot be true. Unless people don't report to anyone.
Managers with fewer than three direct reports were either let go or forced to find new roles (typically as individual contributors, given the overall push to have fewer layers of management).
I met a long time Google employee this week interventions that most of the senior management were ex oracle people.
It’s nearly 20 years since Google had a category defining product - they haven’t built or acquired a single thing that dominates in the same way that android, maps, search, docs, etc. has since about 2006. It figures.
Gemini is absolutely not a category defining product. ChatGPT is. That’s why people talk about looking something up on ChatGPT but not on Gemini. I will hold your beer while you go outside, talk to people outside tech and confirm this.
Google Research/Deepmind is a different thing altogether.
Product wise, Perplexity has them beat by a mile - that said PPLX doesn't quite have the same ads buy-in (or all the Chrome-tricks Google plays to keep tracking alive).
If "beating" is just bleeding money then yes. This is the same playbook that Uber had. Offer an exceptionally good service, until you have to make money. Then it becomes shitty.
So nope, it isnt hard to do what Perplexity is doing. The question is, when the music stops will Perplexity be around.
I currently am an "individual contributor" on a very large (15+) "game team". It is hilariously inefficient to have one manager supporting that many people, as the manager just makes decisions based on heuristics and buzz words. They almost always make the wrong decision, and we just silently ignore those decisions. Since they're so busy, they don't notice.
I have advocated many times and been told no for a situation like, "hey I know a major core problem we need to solve, give me one extra engineer in addition to myself and maybe a part time tech artist and we can deliver this to you."
It is repulsive how many large corporations follow such outdated and rigid processes, and follow the logic of "more engineerer betterer"
Managers of 15 shouldn't make lots of decisions. The team should come together and use decision processes to make good decisions. Manager makes sure individuals are growing and are able to contribute at that level.
I agree with you. Based on what others have said about this article, it sounds like Google doesn't agree with us.
If anything, I would go further than the "two pizza" team sizing. Teams should be no larger than 4 people, one of whom is a lead who is extremely well compensated and is held to extremely high standards, else they are shitcanned ASAP.
Small team management is dead. Long live small team management. Yes. You fire them then your senior engineers fill that gap. Its just not formally part of the process. The cost didnt disappear. Either borne by employees working longer hours or lost velocity.
I’ve never worked anywhere where managers added value, in fact the best places I’ve worked are where the product people have very little power over what the technical team do and instead of specifying what they often specify why, giving the team the opportunity to suggest much simpler solutions.
This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers.
It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.
This is being sold as an efficiency win for the sake of the stock price but it’s really just moved a few people around with the TLMs now 100% focused on programming.
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:
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.)
> 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.
Yeah principal EM is confusing here. Wouldn't EM I report to EM II? At Meta it's typically M1 -> M2
I think L5 Manager at Google is EM1 which is what Facebook calls M zero. So L6 manager (vast majority of line managers) would be EM II at Google.
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 chaos. This is standard corporate management in 2025 though.
In the company i work at this is the standard. Its all pure waterfall and its dreadfull
It’s generally just fine if they all boil up to the same manager and that manager has a direct line to that IC.
Can someone explain the various acronyms?
IC -- individual contributor, EM -- enginering manager, TLM -- technical lead manager
EM = Engineering Manager IC = Individual Contributor
Do you have a mapping to roles/levels[1], for example:
Principal EM - USD$1.3m/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Staff EM - USD$664k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Staff IC - USD$557k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Senior IC - USD$410k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Mid IC - USD$290k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
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?
[1] https://www.levels.fyi/companies/google/salaries/software-en...
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 ;-).
levels.fyi has this
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.
I believe a TLM is an IC on this scale.
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.
Everytime I see such charts and explanations it helps me understand how Musk could fire 80% of Twitter with no visible effect on product.
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.
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 extreme outages? Their reliability went to shit for a while. Fortunately half their users and advertisers quit too so the load downscaled a lot
In addition they reduced API by a lot, some backend and advertiser focussed things are gone and the big thing: we can't know what would have come.
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.
How was there no effect on product? What has 'X' even been able to launch since the acquisition?
All he showed was you can an existing thing running with 20% of staff.
Furthermore, a bunch of functionality was entirely deleted, and the effect on the quality of discourse has been... Profoundly negative.
TLM role has always sounded like a trap to me, I would never say yes to it personally. I’m sure it’s sold as an expected 50% code, 50% management but everyone I’ve talked to who has been near it says the expectation is more like 80% code 80% management.
TLM roles are a trap, but not in that sense. There's no expectation that you do two jobs at once.
It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time.
Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those managing dead-end projects on dead-end teams; or those who desperately cling on to the engineering past and actively refuse to take on more people. From a corporate point of view, none of these situations are great, hence the recent pushback against TLM roles in the industry.
> There's no expectation that you do two jobs at once.
I laughed out loud when I read this. I've never seen anyone at any company in a hybrid tech/manager role that wasn't expected to do two jobs at once. Or at least they felt like they were, which is still the same problem.
80% coding & 80% management for that role sounds about right.
I've been in engineering, TLM, and management roles in multiple companies. In terms of output, TLMs are not held to the same standard as full-time engineers at the same level, period. Their engineering contributions are dissected only if their performance as a manager is in serious doubt.
In any role, there are some folks who push themselves too hard, and there is no one to tell them "stop", but that's their choice.
Management requires a birds-eye view of the project in all its breadth, and quickly responding to issues, as well as reporting up (proactive stakeholder management). The job of the manager is to keep the CXOs happy (inform/manage expectations) whilst protecting their own team so they can focus on getting their work done with minimal disruption (isolate).
Coding requires the opposite, zooming deeply into the code and retaining focus. The job of the IC coder is to deliver (design and implement) beautiful and pragmatic architectures that do what is expected.
I recommend anyone to reject to fill roles where these two are combined into one. Note that this is not a comment about workload, but about irreconcileable differences. (The perfect candidates for each even match different personality profiles...)
80 / 80 is sure close to reality.
As alternative explanation, even if there's no pressure to do so, the thing is these people came to do dev, and probably enjoyed their job enough to get recognized for their work.
So when asked to split between dev and management, outside of a few exceptions they'll want to do 80% of tech by choice. But the management part doesn't go away of course, so it will still be at least 50% (and 80% if they want money, because that's the part they're actually evaluated on)
Most work 40 to 50 hrs per week. Some places even a more extreme 60.
For this to be accurate, you're saying 160% aka 1.6 or 64 to 80 hrs per week, with 96hrs as the extreme?
I mean, 64 - 80 hours a week can be the expectation, and then it's just that almost nobody is living up to the expectation.
Anecdotally, a hybrid technical manager I had in the past worked 60 hours a week pretty much minimum. Which sucks.
I've been a TLM at two big companies and in my experience there was no expectation to do two jobs at once - I did majority of management with very very little hands on coding. More like frequent pair programming with more junior staff, code reviews etc. My last manager told me explicitly when I started - there is zero expectation on you to do any hands on work, you need to make sure your team performs and keeps going in the right direction first and foremost.
Usually it means you have to manage people but you have no real input on their career trajectory, and in the worst case, if they need to be fired you do not have the power to do so.
This was my experience in a TLM role - you have to manage down to your ICs but you have little lateral or upward power. You're basically just conveying whatever your manager decides to do with your team, but with all the additional responsibilities of a staff engineer.
In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.
its called the straw boss.
as in "and the strawboss said well a-bless my soul, you load 16 tons.."
> If you don't suck at management, your team inevitably grows
Inevitably because why?
> those who suck at management
If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
> those managing dead-end projects on dead-end teams
If "dead-end" just means "not growing" then that sounds fine. When a company does thousands of things only a small fraction of them need to be growing.
> those who desperately cling on to the engineering past and actively refuse to take on more people
"Desperately cling" is a wild way to refer to someone sticking with a job they like. And if they're a TLM it's not the past, it's the present. Wanting to keep your present job is very normal.
And is the end goal to have zero TLMs in this expanded team? If you're going to pick new TLMs to go under the one you push into higher management, what's bad about leaving them in place and putting someone else above them?
Look, I'm trying to describe reality; you seem to be expecting me to defend it. But briefly:
> Inevitably because why?
Because proven, effective managers are always in short supply, so when you hire new people, or if any of the existing managers leaves, it's the default pick.
Plus, most people want to make more money over time. And on the management track, this means angling for that director / VP role down the line, even if it wasn't your childhood dream.
> If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
They can, but in big and / or growing companies, performance problems are addressed less vigorously than they probably should. This cuts both ways: neglecting problems is wrong, but cutthroat performance management makes people cranky too.
I mostly found TLM a disservice to people who reported to TLMs. They didn't have to earn a promotion as both an engineer and a manager at the same time, so many optimized for their own engineering promotion and any managing they did was out of the goodness of their hearts.
People that selfish shouldn't be managing people.
As a devil's advocate (I don't work in Google or in a similar role) but if the requirements for engineering promotion are similar for technical managers and engineers, while the first have to manage people then this is just how the system is set up. In this case I think blaming the system more than people is justified, and Google decided to dismantle the role for some reason.
This has largely been my experience in TLM roles. You’re a staff/principal level engineer so people still expect outputs from you. However, you now have the job of managing your teams’ impact and outcomes as well.
Impact and outcomes are far more important than outputs, so it makes sense to for you to spend a lot of time on that. But, when performing review time comes around, you’re still bounded by hard metrics around outputs.
A few thoughts:
(1) As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.
(2) A manager who actually understands the tech is often better at unblocking the team.
(3) Since senior IC openings tend to grow very thin as you become older, TLM path might be a viable career path for at least some.
Can this role work if we don't expect IC output from the TLM beyond what they themselves take on for their own satisfaction and growth?
When you become a good enough IC, “ As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.” is no longer reasonable. Then your managers role is to maximize your ability to make an impact by putting you in the right place/project.
As a manager of people who know far more about the things they do than I do, my goal is to assist and ensure in the right place (for them and the org). It’d be foolish for me to hire peons who know less than me.
Not sure why you'd take the leap from the idea of technical people managing technical people to "hiring peons who know less than me", that wasn't my intention. Also "as an engineer" was rhetorical -- I'm a manager myself and it's been over 15 years since I've been an engineer. So I do see the point you're trying to make. I still feel the immediate management layer above mid-level ICs should have some level of hands-on knowledge of the system they're developing. At the next level up, I think engineering fundamentals and past technical experience would suffice.
GP made the point that early in your career, your boss should absolutely know more than you do about your technical work, but at some point (fairly early), that inverts and your leader unavoidably knows less than you do about your technical work, because you’re the expert on the team at it and they can’t know more than all 5-8 of their reports like you can when leading 3-5 junior/new devs.
In post 1, you want your lead to preferably know more, someone says that’s not realistic, and in post 2, you profess to not understand their point while changing the goal post to now be “some level of hands-on knowledge”, which sounds like you do understand their point.
Control issues prevent experienced IC from just roaming the halls looking for trouble.
TLM is fine. TPM is the awkward one. I don't understand what hierarchy (if any) there is to TPMs, they kinda float around and ask people to do stuff. Some projects get passed around to different TPMs like hot potato. The skilled TPMs stick around and make things happen, but even then idk how that works because they lead people without having any actual reports.
That is the point of a TPM. They're supposed to be the neutral third party that makes sure you're doing the work, and can explain to upper management why the work is not getting done. As such, they don't have any decision-making power on what the work is or how long it's going to take. Generally the manager and IC negotiate back and forth on what needs doing and on what schedule, they set their own deadlines based on the realities of the project, and then the TPM holds them to what they committed to.
Much of the reason the TPM job exists is simply so your manager can be an advocate rather than a nag. The nag job is offloaded to the TPM, but the TPM has no decision-making power, so you don't get perverse incentives where the manager burns all their relationship capital making you do your work, or sandbags the deadlines so they don't have to.
In many orgs TPMs are also in charge of goodies like fun events or device/swag distribution, as a way to offset the negative emotions that come from them basically being nags.
But were all the other managers in the team in a TLM role?
The problem I foresee here is, there would be escalation meetings and all the non-technical managers would sit back and point fingers at the TLMs until they leave.
It sounds to me like Google is moving to a more typical "technical lead" model where leads have substantial authority and some mentorship responsibilities, but they're essentially an IC and someone else up the chain actually handles proper management. Informally, tech leads can gently chew out less senior devs, but if someone actually needs to be disciplined then the lead needs to talk to the manager.
TLM is an odd role. I understand big tech companies have their own culture but it does seem like a poor management strategy regardless of efficiency.
The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers.
Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people.
But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
> But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done.
A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles.
At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in.
I’m a staff engineer.
Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.
> Role power is by far the least effective.
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
> Being very visibly anointed by some VP helps, but that's essentially tapping into the exec's leverage - an illusion of IC influence.
Of course that’s the play. Even a lind manager can’t get major initiatives through without getting the buy in from their manager. When I was working for startups, the director (1st company I had influence at) and the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
Fast forward past BigTech to where I work now - a third party AWS consulting company, after convincing the powers that be of the market, I had it escalated to be one of the companies initiatives for the year.
But more so in BigTech, promotions aren’t completely on your manager. At least at AWS you had to have recommendations by I believe two or three people one level ahead of you and it had to go through a committee.
From talking to a couple of L4s that I mentored when they were interns and when they came back, they were both complaining about the promotion process even though their manager supported them.
> the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
But that mean those people have the power, not you. Without that formal power structure you wouldn't do so much work trying to convince these people, the formal power structure forces everyone to try to manipulate and work with it, even you.
So it makes it so much easier to do anything if you are that high up person, imagine that was you, now instead of having to convince these people to do it now you just do it.
Power structures exist in any group of size. Companies can choose how formal to make them, but they can’t avoid them.
Imagine instead of having to convince the Director, VP, or CTO to support your good idea, that instead you had to convince 100 out of 700 people to support it, while at the same time, those 100 people are hearing good-sounding ideas from 99 people who aren’t you.
I’d way rather work in the former than the latter.
And wielding all three at once is the most effective.
> Role power is by far the least effective.
Eh, maybe at faangs or at the executive level but at non faangs you might not notice a role having power because most roles with the Manager title are no longer actual managers but supervisors.
I had more agency over where capital was deployed as a teenager deciding how many people were going to be on the shift for closing, then I have making over 200k/yr as a Senior Manager.
Any role that has decision making power over where money goes automatically has a massive amount more power than a role that does not
The article is mostly about first level managers. I’ve never had any “manager” that really has any power over raises more than 3-4% or any real control over budgets.
When I was being hired as a strategic hire for startups - and was being interviewed by the director or CTO - I specifically asked would I be reporting directly to them or another manager. I actually refused one job because I saw that the expectations they had from me and how far I was down in reporting structure was incongruous.
>The article is mostly about first level managers
Maybe for faangs. At every company I have worked at with a manger title from 2019 to present, this was expected of people with "director" in their title and below.
You are not a manager if you do not get to decide where capital is deployed, without your boss's approval.
For anyone reading this comment, if you think you are a manager, ask yourself this question
"If I decided tomorrow that the company would be better off if I hired someone to do role {X}, can I open a new req for that role without permission?"
If the answer is no, you are a supervisor with less agency than the a Walmart deli leader circa 2010
I've worked at places where the "senior executives" couldn't do any of these things without CEO approval. Even if they claimed to "have budget" for something, it still needed sign off.
There's tons of title inflation out there, especially at smaller firms.
I think the common vernacular for that cutoff is “director” rather than “manager”.
Directors direct (including opening hiring reqs without higher-level approval).
Managers manage (which doesn’t include unreviewed role openings).
Both do useful work in a well-functioning company.
By make-up I think most TLs at Google had no reports even before this change. The idea of ICs in leadership has always been a common occurrence at Google. If anything I don't really see it as commonly outside of Google.
Yeah, that helps put this in perspective. At first the headline sounded like a somewhat jarring and sudden staff cut, but if we're essentially just seeing Google migrate TLMs to TLs, that actually makes sense.
we had this in my company it was pretty hit miss. Almost always the 'TLM' was someone who was in the role for a really long time and it warranted a second person, so it ended up being a 1-2 junior reporting in absorbing the knowledge that the tlm had.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
I wouldn't actually say that, but I would say that the TLM role works at a very specific stage in a company's lifecycle, and many companies that use it (including Google itself from around 2010 onwards) have long since past that point.
IMHO, the conditions where a TLM role is appropriate are:
1.) You need to be in the company growth phase where you are still trying to capture share of a competitive market, i.e. it matters that you can execute quickly and correctly.
2.) There needs to be significant ambiguity in the technical projects you take on. TLMs should be determining software architecture, not fitting their teams' work into an existing architecture.
3.) No more than 3 levels of management between engineer and person who has ultimate responsibility for business goals, and no more than 6 reports per manager. The mathematically inclined will note that this caps org size at 6^3 = 216, which perhaps not coincidentally, is not much larger than Dunbar's number.
4.) TLMs need to be carefully chosen for teamwork. They need to think of themselves as servant-leaders that clarify engineering goals for the teammates who work with themselves, not as ladder-climbers who tell others what to do.
Without these, there is a.) not enough scope for the feedback advantages of the TLM structure to matter and b.) too much interference from managers outside the team for the TLM to keep up with their managerial duties. But if these conditions are met, IMHO teams of TLMs are the only way to effectively develop software quickly.
Perhaps not coincidentally, these conditions usually coincide with the growth phase of most startups where much of the value is actually created.
If you don't mind me asking, why did your team get bigger? Did your scope increase?
I assume you're referring to my other comment, since I didn't mention my team size in this one.
I'd love to say that the answer is "because I'm a good manager", but I think that the real answer is "because there was money=headcount available, the layers of management above me successfully presented our value and inflated our needs enough to convince a VP to give it to us, and my own manager physically did not have enough hours in the day to have 1:1s with all the new incoming headcount without introducing some layers of management under us". If it weren't me, it would've been some other manager. For that matter, I wasn't a manager when I joined the team, but I was interested in managing and of sufficient level that I could pass department policies, so I ended up more than doubling my team size within 6 months of becoming a manager. The team was pretty busy for the first year or two after that - we'd gotten all that headcount by arguing that we were critical to some big strategic initiative, after all - but there were long periods after where we were oversized by a factor of about 2, so I just let everyone work 20 hour weeks and phone it in until the next big project came.
The more time I spend in the corporate world, the more I become convinced that success is a matter of meeting the minimum qualifications, bullshitting, saying yes to opportunities created by people who are themselves bullshitting, and doing the minimum amount of work needed to avoid being called on your bullshit. Businesses don't hire because they actually have work to do. They hire because they have money and money=headcount and headcount is the only way for a manager to get promoted or pad their resume.
I passed on a similar opportunity, kept the team small. This was back in the pandemic when headcount flowed freely. What you describe sounds about right. My experience is that having a capable team goes a long way creating those expansion opportunities.
This reads like "get rid of the old experienced people so I can get promoted".
only if you're cynical, google found a much better solution though, make them IC's again and redistribute the junior talent to places they can grow and offer buyouts for anyone who feels like they're not into it anymore.
I am cynical. Better for what? I can only interpret moves made by large companies across the board as ways to move the stock price and consolidate control.
If your position has no upward mobility juniors will change jobs, likely change companies, once they have the experience and all the effort you spent training them will be wasted.
If your position has no authority seniors will change jobs, likely change companies, and all the effort you spent on them will be wasted.
I don't know why you think this is an either or situation. Not being a junior doesn't stop you from having a manger.
Statistically you should charge companies. Even if you get promoted, you’ll make less than someone hired in at the same level. Even if you like the company, it’s best to “boomerang”
Its tricky to use statistics for personal decisions. In general something might be correct but not for your specific subgroup. I know many people who changed for worse.
If you are in a bad position then change, but if you like the company and role, don’t take it for granted and think carefully.
This advice is consistent with the broad statistic if more than half of the sample is currently in “bad position”.
Since we are talking about BigTech, I can’t imagine to a first approximation any IC up to and including senior or a low level manager being at any BigTech company for a reason besides wanting to maximize their income via cash and RSUs.
Does anyone stay in the same position/team for more than two or three years even at the same company?
The U.S. military actually uses precisely that system for officer promotions. And in practice most of the U.S. military branches do essentially the same thing for their enlisted force too, deliberately allowing high attrition for the sake of frequent promotions.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
This kinda brings up a question I've often thought about. Why is it that we structure growth in a company to be so biased towards moving into management roles?
I mean there is the obvious part of the answer in that managers are the ones that are given the power to define that growth ladder, but I'm not sure this fully explains things. If people are transferring from technical positions to managerial positions then should they also not be aware that there is a lot of advantages to allowing people to keep climbing the ladder through technical positions? That institutional knowledge can be incredibly valuable. It's often what leads to those people being such wizards. They've been with the code for so long that they know where things will fail and what are the best parts to jump in to make modifications (and where not to!). But every time you transfer one of these people to a non-technical role that knowledge "rots". More in that code just keeps evolving while their knowledge of it remains mostly frozen.
Which what you say sounds like maybe the worse end of that. Taking that person with institutionalized knowledge and hyper focusing their capabilities on one aspect. That doesn't sound like an efficient use of that person. Though the knowledge transfer part sounds important for a company's long term success, but also not helpful if it's narrowly applied.
This hasn't been true in a lot of companies for like my entire career. You can move up as an ic. Titles like Staff, senior staff principal. A Staff and Sr manager would be paid the same
> This hasn't been true in a lot of companies for like my entire career. You can move up as an ic.
You can, but it's a dead end ultimately. I've been a distinguished engineer which is about as far as one can go (some companies have Fellows, but it's just a few people so basically impossible). If you have any desire to grow beyond that, management track is the only possibility.
Also, moving to management from a DE level is harder because you're basically around a Sr.Director level (give or take, depending on company) but have no management experience.
If you care about career growth (and I'm not saying you have to, geeking out on the IC ladder is way more fun), I suggest as soon as you are at the equivalent level of a manager on the numeric ladder, switch to management.
Your making 7 figures? What is left in career growth. You beat the corporate game at that point.
> A Staff and Sr manager would be paid the same
do they report to the same level? every place I've seen a "technical track" and "management track" it seems the higher level technical people report to someone on the same or even lower level in management. I.E. a manager can have technical reports that are equal level or higher. that obviously doesn't happen in the management track.
not that these are first level managers but if a principal engineer not reporting to a VP, the it doesnt seem like the tracks are equal.
Why does the reporting chain matter? They're separate roles and jobs so the manager is leveled differently.
If I'm a jr engineer reporting to a director does that give me more authority then a staff engineer reporting to a manger?
Management is a different job, it would be leveled differently.
Maybe a high level IC needs to work closely with a team for a bit so they just report to the manager of the team.
What do those roles do? Where I work there's a managerial track and a technical track, but if you actually read the job descriptions the technical track is basically either the same as management track, or a devrel role (effectively managing people outside the company).
Ic role has bigger scope of projects. Makes technical decisions. They're not writing performance reports or doing any people management tasks.
I think this is a good thing. Every time I've seen people in dual tech/management roles at any company, they've always been incredibly stressed about their job, and always have way too much to do.
I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. Even if your TLM is pushing a bad technology choice, you might not want to push back too hard because they're also responsible for your performance review and comp changes and whatnot.
I was in such a role and am now being pushed out of it (promoted to PE).
What I really love about it is the leverage. In a technical domain with a good core team it is almost like running your small company.
>always been incredibly stressed about their job, and always have way too much to do.
So, no different from any other dedicate IC or manager at these companies?
>I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there.
How is this different from any other manager or higher up making decisions? If your boss or boss's boss really wants something and you're not in a good market, it's never a good time to poke your head out.
>How is this different from any other manager or higher up making decisions?
Non-technical managers usually don't have strong opinions about which framework or database to use. Among engineers these decisions are usually made in a meritocratic way (weighted by who is the loudest sadly), but if your manager says "let's use X" it has a different weight than if your peer does.
> It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.
The hybrid role idea has always been ridiculous. It's two different jobs, like being a mechanic and an accountant. Do you need a mechanic? Cool, hire a mechanic. Do you only need a mechanic part-time? Cool, hire a part-time mechanic. But I don't want my mechanic stopping and starting the work on my engine 3 times a day because somebody has tax questions.
The whole point behind the division of labor is to specialize, and get really good at your specialization. Picking up multiple very different jobs and trying to do both is the opposite of efficiency. People knew this 250 years ago.
I was a TL and then a TLM in my org, and am now an EM. I'm actually pretty happy about it, personally. I am organizing an eng summit tomorrow between my team and a sibling team (which is onsite and visiting from elsewhere) in my org, and I noticed that about 18 months ago, I would have been the person to give 4 out of the 5 main talks at the summit (as the expert / TL on that system). Now it's five different eng. This tells me I've been able to nurture / elevate the other engineers on the team, get them all into technical leadership roles, and then have them reach out and be ready to talk about their work to other teams.
Overall: this is a good thing. By taking up less room on the technical side, I've replaced one of me with four strong engineers. Previously, I was split between TL work and EM work and as a result, did a half job of each, leaving too much un-done.
The other thing I'll note is that engineers are basically the only role with this distinction. Product Managers, Program Managers, Sales, Marketing, all those roles seem to combine management with seniority. Only on the engineering side do we have both a TL and Manager hierarchy (while typically the TLs for a team report to the same manager that the line manager for the team does, they exert authority differently). This works out okay on the eng side when there is a strong alliance between the TLs and the EMs, but that doesn't always happen.
A recruiter in India was talking to me about some roles for some time and then disappeared. After a few weeks, when I was ready for interviews, I reached back. I was informed that those roles didn't exist anymore. I enquired further asking wahether those roles were filled, and the reply was something on the lines that no, they didn't exist anymore. Bit of a bummer because Google was one of the very few companies here that actually interviewed you pretty fairly even after a considerable employment gap. Those were L7 roles (not sure whether those are around TLM).
Not at Google but I'm in such a role right now and I really dislike it. Can't really get much focused coding in because you constantly have to jump in to review something or help fix something or handle a live site juniors cannot handle, or update some TPS report on what everyone is doing, or some PowerPoint or whatever. I dislike all of these to start with, but getting my own (expected) features in is an exercise in frustration. And when I ignore people and try to have uninterrupted time it feels like I'm neglecting all this other stuff. I wonder who thrives in such a mixed role...
A TLM reduction isn’t any middle management reduction. It’s an IC role still.
Do you have any opinion on the success/value of the TLM role?
Not OP, but I think TLM works best when it's a transitional role. You have someone you want to groom into a full-time manager, and you have a team that you plan to grow over time. TLM itself is not that efficient, but can lead to strong full-time managers who understand the team really well and had time to grow into the role.
I was thinking this too. Tech lead/developer and manager are two completely different jobs. I can see TLM as a useful transitional thing, while the person is being trained or mentored at being a manager (and hopefully not just thrown into the deep end). But 6 months, max 12, I think. Otherwise it just becomes a role where someone has two jobs and ends up overworked.
It's a rather awkward role as you have to carve out a maker's schedule within a manager's schedule [1]. As others have mentioned, it only makes sense as the person ramps up for full management or decides against that career path.
[1] https://paulgraham.com/makersschedule.html
This is a funny question to me, because my entire career (mostly small companies/small tech depts) I've never reported to an EM. It's only when I moved to big tech that EM-who-doesn't-code became a thing, and it took some adjustment for me. All prior roles had TLs (aka TLM) which led the team while being the expert - aka the "surgeon model" from Fred Brooks' book.
As far as I can tell, the main function of an EM is to enforce the company policy. I'm not sure there really is a need at a smaller place.
As someone who has worked in companies from <30 to >100k, I would say that what an EM does is more about communication. Think of a company with m employees as a m by m matrix, with a 1 where there regular communication and a 0 where there is no communication and a 0.5 for those hallway meetings which our CEO's assure us are why RTO is so important.
In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."
That's a large part of it.
Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project."
Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out).
But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.
Thanks for this message, this is actually helpful :). I have been a TLM/EM for the last 4 years, and I still struggle at times to define what my role is about...and in downtime moments (which are rare, most of the time, you are overloaded), what the fuck should I spend my time on.
Former TLM that was involuntarily reclassified as an EM because I had too many reports. I'm from old-line (pre-2011) Google, so was an engineer back when the TLM role was one of our unique competitive advantages.
I have a lot of thoughts on this. IMHO, it's appropriate for the state that Google is in now, where it is a large mature conglomerate, basically finance & managerially driven, built around optimizing 10-K reports and exec headcount & control. It's not a particularly good move from the perspective of shipping great software, but Google doesn't really do that anymore.
The reason is because software construction and management is unintuitive, and concrete details of implementation very often bubble up into the architecture, team structure, and project assignments required to build the software. TLM-led teams have a very tight feedback loop between engineering realities and managerial decisions. Your manager is sitting beside you in the trenches, they are writing code, and when something goes wrong, they know exactly what and why and can adopt the plan appropriately. Most importantly, they can feed that knowledge of the codebase into the new plan. So you end up with a team structure that actually reflects how the codebase works, engineers with deep expertise in their area that can quickly make changes, and management that is nimble enough to adopt the organization to engineering realities rather than trying to shoehorn engineering realities into the existing org structure.
Now, as an EM with 10+ reports, I'm too far removed from the technical details to do anything other than rely on what my reports tell me. My job is to take a slide deck from a PM with 10 gripes about our current product, parcel it out into 10 projects for 10 engineers, and then keep them happy and productive while they go implement the mock. It will take them forever because our codebase is complex, and they will heroically reproduce the mock (but only the mock, because there is little room for judgment calls in say resize behavior or interactivity or interactions with other features and nobody's holding them accountable for things that management didn't have time or bandwidth to ask for) with some hideously contorted code that make the codebase even more complex but is the best they can do because the person who actually needed to rewrite their code to make it simple reports up through a different VP. But that's okay, because the level of management above me doesn't have time to check the technical details either, and likewise for the level of management above them, and if it takes forever we can just request more headcount to deal with the lack of velocity. Not our money, and it's really our only means of professional advancement now that product quality is impossible and doesn't matter anyway.
Ultimately the value of the TLM role was in that tight bidirectional feedback between code, engineers, and management. As a TLM, you can make org-structure decisions based on what the code tells you. As an EM, you make org-structure decisions based on what your manager tells you. But at some point in a company's lifetime, the code becomes irrelevant - nobody reads it all anyway - and the only thing that matters is your manager's opinion, and by transitivity, your VP's opinion. A flattened org structure with as many reports per manager as possible is a way for the VP to exert maximal control over the largest possible organization, mathematically, and so once that is all that matters, that is the structure you get.
Brutal
As a current IC, +1. I don’t know if it’s the case globally at Google, but I certainly know it’s also this way in my org.
I can't say for Google, but at work it's more or less how it works at the office (mostly software dev, half a team does some firmware/hardware), but it's more ad-hoc than as a rule. Like all the teams are small, all the TLM equivalents started as devs before being promoted to their management position, so they have time to do some technical work; how much and what technical work depends on the team, some are still directly contributing to the team's products, others are more on (technical) ancillary tasks, which can be interrupted by management questions with less impact on the development.
I find that it works well, the TLM keep a foot in the action, so to speak and has a better idea of what's happening with the product being developed, what issues we're facing (also in terms of tools, environments...) and it keeps their knowledge of the product more up to date. Of course with their background, I wouldn't say they are all the greatest at managing, but I don't think they've ever done big mistake on that side of their role. So in short in our case it works, but it could just be a consequence of the local organisation and people working there.
(personal opinion)
I thought it was a nice stepping stone for people to learn management without having 10 people dumped on them. But it looked bad on paper.
10 is a lot for a first time manager, but too few reports is also bad for a new manager. 4-5 direct reports is probably the sweet spot where you actually get some experience and the team is big enough that interpersonal stuff averages out.
speaking from personal experience, it's not that good to have TLM as your manager because in some ways you're competing with your manager on technical scope, and you'll lose
The is funny to read because it captures my feelings on this exactly: when you're a company of passionate people driven by a mission from the top down (very important this alignment is genuinely top down), the drawbacks of the TLM-like position are totally workable: the org gives some grace and flexibility to everyone involved knowing that the TLM is sacrificing some effectiveness as an IC, those under them are losing some room for direct impact. It all works out as long you're able to "grow the pie" and make up for the smaller slices by executing.
Once you're late stage though, that's done. TLMs are probably being held to 100% of IC standards and manager standards, people under them are jockeying for "impact" and don't want to compete with their manager, etc.
I totally see why it wouldn't work at today's Google. Honestly maybe it's a positive sign they recognized that.
I think the idea of a leader on the line makes alot of sense. Someone should represent the work and be able to navigate the hierarchy. These types of roles always exist informally anyway.
There’s always a downside to anything, and the merits/demerits are all about the politics of the org.
I'm essentially in a TLM position currently. We're a small company, with a small codebase. I oversee three junior to mid-level developers, and I represent the team in our product/roadmap planning process. I also write a lot of code, review a lot of code, and make a lot of architectural decisions. At our current scale, and with our current resources, I think it works pretty well. Moving fast is one of our biggest priorities, and having a TLM definitely reduces overhead versus a more traditional separation of responsibilities.
I really never intended to have a management position, but this has been an incredible opportunity to experience a portion of it without fully committing. Other replies have described this as a transitional role, and I don't think they're wrong. In the long term, especially if the company grows, I can probably be more valuable by committing to one path or the other. However, for the right person and situation, I could see us minting a TLM again, regardless of size.
Doesn’t work when headcount stagnates because the teams never grow to full teams and the junior reporting engineers eventually become peers in a too small team.
Simple as that. It’s fine during times of growth but that’s not happening right now.
The value of that kind of role is that the person interfacing with the bureaucracy and the business hierarchy and its many demands also actually does the technical work and knows things about what they are working on.
Without it, nobody on the management side of things actually writes any code, or has first-hand experience with working on the product. The line managers just end up as a go-between between the workers and their directors, because they only know what their reports tell them. They don't know much for themselves.
You can't quantify this sort of loss on an earnings report, but among many other things, it does a great job of diluting ownership of the product away from the teams working on it.
I never worked with a TLM who actually wrote code regularly.
I remember TLMs being considered a bad idea in 2010. Looks like the pendulum took a full swing in the mean time.
TLM role was both the best and worst role in tech.
Best in that the TLM generally has complete control over the product execution (and can commonly bulldoze the PM). It's amazing if you have a solid vision of what you want and you want to get it done.
Worst in that the workload can be intense as the team grows.
> This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers.
Ohhhh this explains so much. My career is pretty much entirely at b tier companies who try to implement what faangs/mag7 type companies do but always fuck it up because they don’t understand the fundamentals or are unwilling to part with any of amount of power or money even if they got more after all was said and done.
Anyways post covid all of a sudden every company was expecting me as part of the Software Engineering Manager roles I was getting, to have 7-10 direct reports, do 30 hours of project management per week, _and_ simultaneously be better versed in every single project my direct reports were working on or at least be the initial architect for the project.
I just ignored it and kept my people productive since that was an impossible ask of me, and for 5ish years that was good enough for companies but I guess if the faangs are wiping that role clean I better switch career niche again
We did something like this but called it a different name. It was absolute garbage. Its really no surprise to see those roles move back to a more traditional alignment.
Why was it bad?
Managing skills and techlead and IC skills are pretty different disciplines.
Being 50/50 makes it hard to advance/develop in either one of them significantly.
The biggest issue is that management requires a lot of "wasted time" paying attention to whats going on around you and IC skills require a lot of "heads down time". It's a big fight between those two modes.
I've done it at a startup but it required doing most of my IC work after hours. Which isn't that sustainable.
It was terrible because the "managers" had very little training which made them mostly useless and a legal liability to the company in regards to employment law cases. In many instances they weren't even on the same direct team but an adjacent team, so rhey hahd very little interaction. This completely invalidated the premise that a technical/coding manager would be a better mentor since there was never any time for it. Of course the company paid them the same rate as the senior devs that weren't managers. I'd say at least 50% of the first year cadre left the company or reverted to a regular senior dev after one year or less. Most divisions of the company don't use this model now. The only real reason they did it was because Google did it.
It’s the only point in one’s career where you’re expected to do both programming and managing and it’s hard to do both at the same time and at a good level.
Having worked in organisations of various sizes, my observation is that the network effects issue rings true, and large companies feel horrendously bureaucratic.
I had one Engineering Manager joke that his year at Volvo Cars had been one long meeting. Even the then-CEO at the time complained about the number of meetings the company held.
I also remember a tale from a colleague in a startup that had come from a much bigger company talking about how colleagues in India were asking for promotions or pay raises every year. Why? It turned out the colleagues in India had strong expectations from their parents to consistently be progressing in their career, hence they had to show progress in the form of being promoted or having increased salary.
What did the company do? They started creating job titles to essentially create the impression of being promoted without much changing in terms of the day to day job.
It seems like a kind of inflationary effect on organisation structures, where you solve one issue but potentially create other issues, namely bureaucracy.
First they laid off the non-technical employees. As a big tech company, Google needs to focus on coding. But that wasn't enough, so they laid off the middle managers in charge of coders. As a big tech company, Google needs to focus on coding. But that wasn't enough, so they laid off the low-level managers who were the domain experts on each product. As a big tech company, Google needs to focus on pure coding, and anyone who isn't doing 100% coding is extraneous. But, that won't be good enough, so next they'll lay off the senior engineers. As a big tech company, Google needs to focus on coding, and senior engineers spend too much time doing "architecture" (whatever that means). But that won't be enough, either. So they'll lay off the regular engineers, too. As a big tech company, Google needs to focus on only the purest coders, meaning junior engineers who don't actually understand the product (understanding the product considered harmful). But that won't be enough. So they'll lay off all of the juniors and only keep one guy named Greg who will adopt the title "webmaster of google dot com" and rewrite the whole thing in PHP. Then this big tech company can really prosper!
Isn't it already prospering?
Pretty much. Except Greg here is actually Gemini and they hope he can work 24/7 perfectly under the executives' convoluted, contradictory prompts.
Kudos for getting that fat without mentioning AI
Google is probably doing what everyone else is doing. The entry level managerial positions are being eliminated by pretending the people doing the work are not actually manager and are therefore paid less.
It’s reached ridiculous proportions in some companies I have worked for. I have seen transversal project managers and delivery leads in charge of up to 80 persons sometimes with an intermediate level of management actually reporting to them but not directly attached to them be paid as IC.
It gets even more funny because some positions in said companies doing a lot less management but occupied by people who suck up a lot are actually considered managerial.
Most modern big companies are completely f* up. The only reason we don’t see more disruption is regulatory capture.
The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
If you oversee 0-2 people, in most cases that’s probably not an efficient ratio. How did Google get so many folks in that position in the first place? And I assume the other 65% take up the slack to fluff their teams? Or what? Leave the other 65% managing 0-2 people?
For a team that size, you would assume the manager is only spending around half of their time on people management and probably around half their time working directly on whatever the team does. It can be a good arrangement if the goal is just to give a little more leverage to the manager, but it's also equally possible that the manager doesn't have time to do anything particularly well. Also, a lot of time a part-time line manager like that won't have enough organizational clout to look out properly for the team.
Having tried that arrangement a few times, I think it's better to have small pods where everyone is an engineer and then all the pods report up to a dedicated people manager.
From my experience: re-orgs and limiting backfills for attrition can lead to these awkward states. Someone starts off with a sensible number of directs, but it can devolve over time.
I work for a startup with an engineering team size of about 6, and I manage one person. I agree it's not an efficient ratio but it works for now.
I don't think mature enterprise companies should have managers of 0-2 people though.
IMO, overseeing 0 people is great. I'm not likely to take any position where I have to oversee more or less than that; although I'm willing to compromise and oversee one person where they're actually independent and I don't have to do much overseeing.
I'm sure that some company has managers overseeing imaginary and complex people.
> overseeing 0 people is great. I'm not likely to take any position where I have to oversee more or less than that;
I would have so many questions if I got an offer for a position where I had to oversee less than 0 people
Would that mean you have to undersee one or more people? cue rimshot
Overseeing 0 people is great if your role is an individual contributor. If your role is a manager and there is no one for you to manage, it would seem that your role is redundant.
I am on a team of 2 people with a dedicated manager. That is, the manager does not write code and is not even really technical.
It is awful, send help.
When I started, I was told that one of the easier ways to get promo at L5 was to become a manager. I don't know how true that was at the time, but I think this could be a consequence of that sort of local optimizing. I think now they don't even allow you to be a manager at L5 unless you're grandfathered in?
Search and ads, at least, had the L6 requirement for manager going back as long as I’m aware. I was under the impression that the requirement was relaxed at some point in some of the less revenue critical orgs, but that the L6 restriction actually goes back a long way.
FWIW I was L5 manager (on the SWE ladder) in two PAs. The L6 requirement did exist but in my experience was quite soft. All that my management had to do was justify to the VP that I was capable of doing the job and would soon be ready for promo to L6 (though the first org got nuked and the promo took a long time).
Interesting. Where I was I never saw an exception to the L6 rule.
Not a Goolger but my experience is that this is usually an optimistic promotion where someone is made a manager with the expectation of growing headcount later. But later never happens, or coincides with turnover to the degree that they never bubble up to a decent span of control.
Sometimes there are products where 1-3 people is the right size of team for that product; letting a team that size exist can be better than trying to smush together two or three unrelated products to fit a bigger team. Per other comments these are TLM positions where the manager is also expected to contribute technically.
In some circumstances it can be an effective way to lose efficiency in exchange for velocity- basically there are large tasks that can’t be developed by a team any faster than by an individual ( mythical man month) because they are fundamentally sequential not parallel. In these cases there are often parallel subtasks, so you can buy some speed by having one individual forging ahead as if they are the only one on the project, and then rope in the team for parallelizable subtasks. Instead of any amount of decision-making or communication overhead, everyone jumps when the team lead says jump – this is the step that bounds performance to not be slower than a solo project.
Being the team lead in this sort of structure is grand fun, of course, but being a team member is brutal on the ego, and requires enormous skill to be a boost to velocity instead of a drag. Thus, it requires ridiculous compensation, even if you’re mostly sitting idle when the project is in a serial phase. it’s the sort of play that I could believe 2012 google could profitably execute and 2025 Google can’t.
By plucking employees from larger teams until said teams have 0-2 people.
Fewer than 3 people? That almost never makes sense. Right on Google to sort that out but I’d have a lot of questions for whatever leaders allowed such nonsense to develop on their watch in the first place.
Also 35% is way too low if it’s really less than three. Should be more like eliminating 95% of those scenarios.
It's only inefficient if the manager only had management responsibilities, which I doubt is the case in most of these situations.
The article says they were converted to ICs so these were TLMs or similar people. It sounds like the headline is clickbait and what's really been eliminated is small teams.
How is it not efficient?
In certain types of company, it's workers without management responsibilities who do the work that brings in the money.
Think of a delivery company, for example, where drivers make deliveries, which is what the company gets paid for. Too many managers - AKA too few employees per manager - will sink the company, because managers draw a salary but don't make deliveries.
Of course, this analysis might not work as well for a company like Google. I'm pretty sure I can publish an ad without any human intervention on Google's end, so maybe they have no equivalent to the drivers, making the ratio incalculable.
I guess it depends on what other responsibilities the manager has. If a manager has too little to do, they might over-manage their small team, constantly checking in on their work, which is inefficient and demoralising.
If managers oversee 0-2 people in a company, that means it's roughly just one person managing one person managing one etc.
Imagine you have a cohesive system that has 10 services, each service requires 1-3 people. The head of the system can assign 10 tech leads responsible for the overall quality of the services or they may have over 20 direct reports, most of whom have nothing of interest to report to the higher-up.
It’s that semi role of being a “manager” while still writing code. They’re just doing away with that role and having dedicated people managers and dedicated engineers.
The way the execs talk down to employees now is really depressing to read about. That's a really unfortunate culture change since I was there.
I was there 2013 to 2017 and it was a pretty big shift start to finish just in that window.
Google was actually cool to work at pre 2011
Not too far off the timeline of when Google employees started trying to unionize and when Google started hiring union busters
The fish rots from the head down.
Around 5 is the correct number for a first line manager of a technical team. Go to 10 and it’s impossible to keep track of things. The day has only so many hours. Managing takes time.
For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
> Go to 10 and it’s impossible to keep track of things. The day has only so many hours. Managing takes time.
I've actually had better experiences with higher employee:manager ratios for this reason.
When the manager can't possibly be involved in everything they're forced to let go, delegate, and skip the management busywork.
My worst experiences have been at companies with one manager per 2-3 employees and skip-level managers who were expected to be involved as well. It was a never-ending stream of meetings, weekly hour-long 1:1s with multiple people, goal setting, personal development exercises, and a growing list of scheduled distractions.
The managers felt like they needed to make work to justify their managerial roles, so our time got filled with meetings and activities that didn't contribute to anything other than making the manager feel good about doing things they heard about in podcasts and books.
Same. With so few reports, those "managers" don't have much to do, so they invent nonsense and start aggravating the actual people doing the work. In one case, the guy was totally not receptive to my feedback about the performance issues of other team members. "I'll talk to him."... and literally did nothing. I was more experienced than everyone on the team, including the "manager." He's gone now.
This is my experience as well. I currently have two managers for a team of three people. One manager basically wants nothing to do with us, and the other wants hourly activity reports that I'm fairly certain he's never looked at.
That's an interesting perspective and not one I've heard before, but it resonates with me. Thanks
At that ratio a technical manager should be first on every code review, should be testing the hell out of everything, and should be sitting in design reviews catching bugs well before they hit the IC's plates.
With 2 reports one definitely has time for IC work. At 4-5 is where it gets tricky.
Every time I see manager with 5 people I know it will be daily 30m standups, friday “summary” meeting, weekly 1:1 and other nok work related activities. If team of 5 people need a babysitter fulltime it means there are no adults on that group.
No, 5 is about ideal. If you are micromanaging with that many people on your team then you are neglecting other aspects of being a manager. More than about 7 and you start being unavailable to your team when they need you, and won't have time to do the planning and process tasks.
both can be true
Matches also my experience if they were overseeing only one small team.
That's been the mantra in the tech world for at least a decade now, and I've grown to really disagree. Managers should have 10 at minimum. Most should have 15-20. They should specialize in being a manager and shouldn't be solving problems except pure management problems. (Good) teachers easily manage classrooms of 10-30 kids, even in private schools. The low direct report count ends up creating managers that have too much power, too much say, and too much time to mess around.
Around 5 is when the manager typically creates extra unnecessary work for everyone to justify his/her existence
> For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
that described internal Apple hardware teams i was on for years, as having as flat as possible an org was a priority to prevent bureaucracy and fiefdom forming middle manager nonsense
Interesting! How many people were you? There weren't any other informal power structures emerging?
I've never directly reported to someone who had that few people reporting to them. Team sizes of ~5 work well but managers can have multiple teams. They don't need to be involved with most people on a day to day basis.
Next up: super frustrated ex-google PMs complaining "that's not how it's done at Google" at their new jobs.
Working with one of those right now, on my two-person team, ironically.
This has been happening for over a decade
Having worked with said PMs both at Google and after, it is extremely annoying
Im convinced the big tech firms are so overly bloated simply because they do not possess high-quality leadership at the top who are able to clearly distill a vision of where they want their sub-ordinates to go.
That's not to say it's easy - its absolutely not. But Apple is living off of Steve Job's visionary prowess and continues to do so.
This was how I felt about Google in 2018. It's gotten less bloated and better in some ways, but the CEO is still autopilot.
high-quality leadership is actually so rare in general
I agree. What's worse is, the upper layer and middle layers of management are filled with bozo's looking out for their own interests and have no desire to find those with potential and hone them.
Business school is a terrible proxy for future business leaders.
It boggles the mind how these firms have bloated to the size they have - it's the cost of ill-disciplined management from the top.
> The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
I wonder why these people are made managers in the first place. That too this kind of title seems quite prevalent in the company given they found 35% of all managers are like this. Either the statistic is just plain false or google is really dysfunctional
Honestly as an outsider this is the not the most important role for them to have eliminated. I have interacted with google a couple of times in the last few years and the company I work for are considered a priority account that they want to do more business with.
In every meeting, they put forward one engineer (who is usually quite capable) and 6 or 7 spreadsheet-trackers who all come from McKinsey or straight out of MBA school and seem to have no function other than to consume the oxygen in the room. Every meeting another one shows up and introduces themselves as being the person in charge of the relationship (this has become a running joke between me and the CTO).
At one stage I stopped going to one of the weekly meetings that these people put on my calendar so the guy called me up to ask why. I explained I got no value from the meeting as all the meeting was for was so he could read through a spreadsheet that everyone already had shared so if I was interested (which spoiler I wasn’t) I could just read it for myself and didn’t need a 45min meeting. He was most offended and disappeared soon after to be replaced by some other person who introduced themselves as the head of the relationship.
So in short if they get rid of everyone on the client-facing side who describes themselves as head of some relationship they would cut a lot more dead wood than TLMs.
"seem to have no function other than to consume the oxygen in the room"
I have a nice phrase for these people - oxygen thiefs.
Managing dev teams is a tough job and I respect the ones who find a way to add value.
The good managers I know have been good in spite of all the incentives that surround them. The rest have mostly been going with the flow and responding to the environment they are in, and the result is usually a whole lot of upward management and little real value—just more TPS reports delivered on time.
Note to the publisher: when I was about 2/3 through the article the article disappeared and I was scrolled to the footer. When I scrolled back to the top there was only the title, key takeaways, and about 3000px of Taboola. Bad form.
I'm curious, what did the management part of the TLM role entail?
As someone who used to be an engineering manager, I was always surprised at how inefficient the division of responsibilities seemed to me. I mean, when I was an eng. manager, a substantial portion of my time was just taken up by logistics - like when we did a move to a new office building, a huge time sink was stuff like seating charts. Perhaps a company as big as Google has more folks taking care of stuff like this, but I still think the following breakdown makes sense:
1. A "technical mentorship" role: someone who codes, but is also explicitly responsible for skills growth and technical feedback of ~5 junior engineers. This person would not be responsible for stuff like salary/raise negotiations, promotion decisions (but would obviously feed into that, more on that below), logistics questions, etc.
2. A "directing manager" (obviously that name kind of sucks, but I didn't want to confuse this with other "director" or "manager" terms). This person explicitly does not need any technical skills. They are responsible for all logistics/salary negotiations, etc. They would be responsible for around ~5 technical mentors, so then up to 25 people under that. Promotion decisions, for example, would be made amongst the 5 technical mentors, deciding who on the team is most deserving to move up. But then the actual salary decision would be made by this "directing manager".
I'm sure this could be tweaked, but the overall idea is to separate technical vs. non-technical skill sets more efficiently.
> "We have to be more efficient as we scale up"
... google is a 27 year old company
... google is one of the most valuable and influential companies currently operating
i don't think the phrase "scaling up" makes much sense in this category
I thought the same thing. Some of the commenters said this move might be related to stock price or appeasing shareholders, so I wonder if that, too, was directed at them, as in “we’re big and we plan on getting even bigger”
It's not just for engineers. There are some non-engineering managers who have been demoted into ICs because they don't have enough ppl to manage.
Good riddance. 7 years too late. I worked as a Google Cloud consultant for a major part of my career. We had this really large client, we were bleeding money because one of our ex-employees promised the client a cost reduction strategy that was impossible and I took over his role - literally a hot seat. We walked into Google's office, it was fantastic, they had something like 12 cuisines in the dining area, multiple game rooms with Table tennis and all. Sleeping rooms, you name it. It was more of a 5 star luxury resort experience than anything.
We walk into the meeting room, past the employee desks, over 50% of it was empty. I asked one of the colleagues showing us around where they all were - "they just work when they like!". Wow, what a dream! Google has/had? this rule where you can take some 20% of your time in a given day for yourself. But, mostly people used something like 40% of it in reality. I thought this was the perfect working culture with great work-life balance. I had very high expectations for the employee quality until I met the TLM and his team we were supposed to meet.
What a bunch of clowns. They suggested we use Cloud Spanner - one of the most expensive offerings at the time and our bottleneck (and bleeding) came from legacy MySql. He didn't even know that Spanner was more expensive than their Cloud SQL offerings, not to mention completely different offerings (it's No-SQL). None of them even knew when to use Spanner for and when to stick with SQL for. It was their own product line-up and we had more knowledge than them! I didn't pass any GCP exams even, at the time. That was the funniest part. We just needed help with some re-architecting of the client's application on a legacy PHP-MySQL combo. They didn't even have suggestions on what stack to migrate to! No idea whatsoever and they tried to talk their way out of it. In the middle of the meeting, my boss leaned over to me and told me "Neya, I think you probably know more than these guys, let's leave" and we wasted no time. To Google's credit, they did offer us some credits to use, but it was far too less than what were bleeding.
I went back to office and out of curiosity searched for how much these guys make - It was easily 120k - 250k (back then) depending on their experience. That's when I literally stopped trusting Google with anything at all. I could never be that laxed when I take that much money from anyone. Later, I learned a lot of these people were just there because depending on the country, you had to maintain a quota (ratio) of certain demographics within Google, most of the TLMs and their teams just conveniently fit into that. Why fix something that's not broke, right?
The Google we knew with the original startup culture was long dead and this story is atleast 7 years old now. For over 5 years since then, they did nothing but make money by simply increasing prices for GCP offerings. I remember our costs rising up suddenly after they just pulled the rug on us with Cloud storage price increase at random. No innovation, nothing. The AI mode they launched now after ChatGPT took the market by storm was what should've been 5 years ago. They are following the pattern exactly as described in the book we learned in our Masters' - "How the mighty fall" (really good book) and well deserved. You reap what you sow.
/endrant (thanks for reading!)
Just increase headcount under oneself in order to protect oneself. Isn't it what bureaucracy have been doing all along?
It goes in cycles. I remember the last time G did this (2006?) they had the 7 rule:
No manager with more then 7 reports No IC with more then 7 managers between them and CEO
How is that number picked?
7 people with one manager seems fine. It could go up to 10 maybe, but that's just my own vibes.
7 layers thick of management feels like too much to me. You'll get a company full of professional middle management who's jockeying define the company culture and strategy. Is that the point? Vibes seem off though.
Is there a more scientific approach?
> 7 layers thick of management feels like too much to me
Yeah, so having more than that was banned. They didn't say you need 7 people between employee and CEO, just that there shouldn't be more than 7 people between them.
When you ban something you want to allow reasonable levels so you take a reasonable level, pad a bit, and ban that unreasonable level, so you agree.
But, also note for large companies, like 100k people, you need around that many layers or managers will have too many people to manage each.
They shpule make it 16 reports and 8 between them and ceo. Then they can use IP addresses for staff.
This is one thing that should become a thing. There are way too many managers micromanaging teams causing more problems than solving them.
I never really understood the concept of small teams. Managing a small team really does not provide the scale and benefit that a medium to large team does. Lost bandwidth of manager of said small team or extra salary of the same manager seem like something the company could use in other places.
But often such teams in faang come up as a by product of someone’s empire building and that is unfortunate for others involved in it.
The lead is also doing a lot of the regular dev work. Their work is small and self-contained enough that it doesn't need more headcount but also doesn't make sense to merge into another team.
I could even see there being a 1-person team, but their slow tooling and red tape creates the need for extra headcount.
What's a small team at Google?
can someone with experience doing this shine some light? i have been offered this type of role from engineer to 50/50 (as i feel it) or 80/20 (as they say) IC and managing. in a series C startup. i feel like it’s never good to context switch. i never seen a tech lead or manager who did well both roles at once. am i crazy to think that the tech lead or manager role should be 100%? either go the IC track or the manager track. but i lack evidence to substantiate this idea of mine.
I’m in this position now. The longer I’ve been in it, I’ve come to realize can be summarized as:
You experience some the benefits of being a manager but bear all the responsibilities of managing others. It becomes challenging to make sound judgments when you must consider two different perspectives of a problem. Essentially, you’re taking on the duties of two jobs. I’ve found it incredibly difficult to step back and allow the team to make decisions without my input. My technical bias compels me to intervene when I perceive a decision as clearly incorrect. However, this approach hinders growth and may be perceived as micromanagement. While it’s a challenging position, it’s an excellent opportunity to explore management and determine if it’s a long-term career path you’re interested in.
At early startups where people are focused on building and you have self motivated, mostly senior+ engineers or hands-on founder types, the 80/20 thing can work. The problems happen when you bring in a lot of other roles, less experienced folks, and more and more distractions build up. The 80% will become more like 30%.
Listening to googlers drone on about their byzantine corporate structure and acronyms is always so bizarre.
Reminds me of severance and the polite little drones reciting their eigan lore.
Google is a blight on our society.
> Google is a blight on our society.
Will be worse when they "scale up" to funnel a larger fraction of revenue to shareholders (directly or indirectly by accumulating a larger hoard) by paying less people to provide the same service.
I feel like units need Sergeants, and tech leads are closer to that than managers/officers.
I for one welcome our new AI overlords.
Not that I'm trying to gain favor or hoping my future AI managers will remember my kind words and promote me when they take over my company.
Recouping some of their data center capex money
Fewer managers with fewer direct reports seems impossible. If you eliminate managers, then the remaining ones will naturally absorb the direct reports. So one of these cannot be true. Unless people don't report to anyone.
The stat refers only to managers with less than 3 reports.
> The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
What impact did it have on project Oxygen?
So what does it mean exactly, they merged a bunch of teams?
Managers with fewer than three direct reports were either let go or forced to find new roles (typically as individual contributors, given the overall push to have fewer layers of management).
I met a long time Google employee this week interventions that most of the senior management were ex oracle people.
It’s nearly 20 years since Google had a category defining product - they haven’t built or acquired a single thing that dominates in the same way that android, maps, search, docs, etc. has since about 2006. It figures.
Gemini and transformers in general from Google Brain might say "hold my beer"
Gemini is absolutely not a category defining product. ChatGPT is. That’s why people talk about looking something up on ChatGPT but not on Gemini. I will hold your beer while you go outside, talk to people outside tech and confirm this.
Google Research/Deepmind is a different thing altogether.
Product wise, Perplexity has them beat by a mile - that said PPLX doesn't quite have the same ads buy-in (or all the Chrome-tricks Google plays to keep tracking alive).
If "beating" is just bleeding money then yes. This is the same playbook that Uber had. Offer an exceptionally good service, until you have to make money. Then it becomes shitty.
So nope, it isnt hard to do what Perplexity is doing. The question is, when the music stops will Perplexity be around.
...and has them replaced by AI?
I currently am an "individual contributor" on a very large (15+) "game team". It is hilariously inefficient to have one manager supporting that many people, as the manager just makes decisions based on heuristics and buzz words. They almost always make the wrong decision, and we just silently ignore those decisions. Since they're so busy, they don't notice.
I have advocated many times and been told no for a situation like, "hey I know a major core problem we need to solve, give me one extra engineer in addition to myself and maybe a part time tech artist and we can deliver this to you."
It is repulsive how many large corporations follow such outdated and rigid processes, and follow the logic of "more engineerer betterer"
Managers of 15 shouldn't make lots of decisions. The team should come together and use decision processes to make good decisions. Manager makes sure individuals are growing and are able to contribute at that level.
I agree with you. Based on what others have said about this article, it sounds like Google doesn't agree with us.
If anything, I would go further than the "two pizza" team sizing. Teams should be no larger than 4 people, one of whom is a lead who is extremely well compensated and is held to extremely high standards, else they are shitcanned ASAP.
I wonder what Google will do about TVCs now. TLMs usually also had a squad of TVCs.
What is TVC?
TVCs got nerfed so hard
And all the managers working remotely were replaced with their Gemini versions, and so far nobody has noticed it :).
Small team management is dead. Long live small team management. Yes. You fire them then your senior engineers fill that gap. Its just not formally part of the process. The cost didnt disappear. Either borne by employees working longer hours or lost velocity.
I’ve never worked anywhere where managers added value, in fact the best places I’ve worked are where the product people have very little power over what the technical team do and instead of specifying what they often specify why, giving the team the opportunity to suggest much simpler solutions.