> 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).

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...

Can someone explain the various acronyms?

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...

Everytime I see such charts and explanations it helps me understand how Musk could fire 80% of Twitter with no visible effect on product.

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.

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?

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.

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.

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.

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.

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.

This reads like "get rid of the old experienced people so I can get promoted".

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.

I just structure my time Monday-Wed-Fri meetings, Tue-Thu no meetings coding. Yes, sometimes non-urgent things have to wait a day.

>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.

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.

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.

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

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.

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.

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.

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.

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

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.

I never worked with a TLM who actually wrote code regularly.

Why was it bad?

Pretty much. Except Greg here is actually Gemini and they hope he can work 24/7 perfectly under the executives' convoluted, contradictory prompts.

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

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.

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.

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.

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

Frankly autopilot is probably in the top quartile of company leadership. CEO flailing only seems to make things worse.

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.

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.

That's an interesting perspective and not one I've heard before, but it resonates with me. Thanks

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.

Matches also my experience if they were overseeing only one small team.

Interesting! How many people were you? There weren't any other informal power structures emerging?

Having worked with said PMs both at Google and after, it is extremely annoying

Lol I went through a few FAANG Pm interviews for the lols.

Ah trust me - its actually insane how every firm manages to pull this off - the secret sauce that made the company what it was evaporates and the management optimise for process.

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).

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.

> 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 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.