Google has eliminated 35% of managers overseeing small teams in past year

Discussion (35 comments)

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.

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!

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?

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.

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.

Next up: super frustrated ex-google PMs complaining "that's not how it's done at Google" at their new jobs.

> 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

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.

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.

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.

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

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.

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

Just increase headcount under oneself in order to protect oneself. Isn't it what bureaucracy have been doing all along?

This is one thing that should become a thing. There are way too many managers micromanaging teams causing more problems than solving them.

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

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.

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.

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.

Recouping some of their data center capex money

I feel like units need Sergeants, and tech leads are closer to that than managers/officers.

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.

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.

What impact did it have on project Oxygen?

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.

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"

So what does it mean exactly, they merged a bunch of teams?

I wonder what Google will do about TVCs now. TLMs usually also had a squad of TVCs.

And all the managers working remotely were replaced with their Gemini versions, and so far nobody has noticed it :).

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.