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.

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?

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.

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.

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.

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

It's only inefficient if the manager only had management responsibilities, which I doubt is the case in most of these situations.

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.

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.

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.

How is it not efficient?