Google Has Eliminated 35% of Managers Overseeing Small Teams in Past Year, Exec Says (cnbc.com) 30
Google has eliminated more than one-third of its managers overseeing small teams, an executive told employees last week, as the company continues its focus on efficiencies across the organization. From a report: "Right now, we have 35% fewer managers, with fewer direct reports" than at this time a year ago, said Brian Welle, vice president of people analytics and performance, according to audio of an all-hands meeting reviewed by CNBC. "So a lot of fast progress there."
At the meeting, employees asked Welle and other executives about job security, "internal barriers" and Google's culture after several recent rounds of layoffs, buyouts and reorganizations. Welle said the idea is to reduce bureaucracy and run the company more efficiently. "When we look across our entire leadership population, that['s mangers, directors and VPs, we want them to be a smaller percentage of our overall workforce over time," he said.
At the meeting, employees asked Welle and other executives about job security, "internal barriers" and Google's culture after several recent rounds of layoffs, buyouts and reorganizations. Welle said the idea is to reduce bureaucracy and run the company more efficiently. "When we look across our entire leadership population, that['s mangers, directors and VPs, we want them to be a smaller percentage of our overall workforce over time," he said.
on the shoulders of mud-submerged giants (Score:3)
Re: (Score:1)
Smart managers experiment to see if their grand ideas hold water. They could select a few offices for pilot project cutting and see how they do. Only if it's successful should they then widen the scope.
However, in this case Google is probably bleeding money and have to do something to trim the budget. This approach makes it look like a strategic re-org to investors instead of mere shrinking, and newbie investors often fall for gimmicks.
Re: (Score:2)
Knowing middle managers... (Score:5, Insightful)
Re: (Score:3)
Yeah, getting rid of unneeded bureaucratic layers is great. Most of the time there would be little to no perceived difference. But unfortunate if you're just a good team member who got promoted. They might be put to better use rejoining the team they were overseeing.
Re: (Score:3)
The managers were so busy with Perf* that they were unavailable for 8 weeks out of the year.
* Google's Performance review process - including calibration, outputs, 360-degree feedback, OKRs, results obtained, behavior / Googleyness, presence (sometimes called visibility at other companies), etc.
Re: (Score:2)
The problem is when y
Re:Knowing middle managers... (Score:5, Informative)
Knowing middle managers, the shit ones did enough arse-licking and point-scoring to hang on to their jobs, while the good ones were too busy being good managers.
Neither, really. They didn't eliminate jobs so much as make new rules that mostly eliminated the "Tech Lead / Manager" (TLM) role.
There used to be a lot of software engineers (people on the software engineer job ladder, as opposed to the engineering manager job ladder) who had 2-3 people reporting to them and were considered TLMs. These people divided their time between engineering work and management. Google made a new rule that every manager has to have at least 5 direct reports. This rule has flattened the hierarchy by mostly eliminating TLMs, who all had to decide whether to lose the "TL" part and be a pure manager or lose the "M" part and be a pure SWE. Well, "pure" is too strong. Some SWE managers still keep their hands in the code but they generally don't have time for significant projects.
Is this an improvement? Dunno. There are pros and cons. The TLM role has some significant benefits to a company. It enables the existence of small, close-knit teams where the team's manager is also the pre-eminent expert in the area. Being managed by the expert has a lot of advantages for the reports, especially when it comes time for the manager to defend the team's performance ratings or promotions, because the manager deeply understands their work. It has advantages for the company, too, because in a small team led by the project expert it's impossible for low-performing employees to hide their low performance or blame it on others.
On the other hand, TLMs can end up overwhelmed by the administrative overhead. This can cause them to be less effective as managers because they don't navigate the system on behalf of their employees as effectively. Some of them may not be very good at defending their reports' ratings and promotions because they don't have the skills to do that, even though they deeply understand the team's contributions. It can also definitely make them less effective as SWEs, and these people were generally top-performing ICs (individual contributors) before taking a manager role. Some might argue that any time they spend on management rather than engineering is a waste of their talents.
Pure engineering managers can be and often are better managers. Better at helping their reports develop important non-technical skills and knowledge and better at working the system for their reports. And some top-performing SWEs are such excellent managers that even as good as they are at building stuff, their positive impact as managers is larger yet.
From the upper management perspective, there's another advantage: Fewer managers to train and manage. Managing managers is harder in many ways than managing engineers, because the output of managers is harder to measure and evaluate. Also, managers are officers of the company which attaches greater legal and PR risk to their actions. Having fewer of them to manage is beneficial.
(Saving money isn't really a benefit, at least not the way Google does it. SWEs who also manage people don't get paid any more than SWEs who don't, holding all else constant.)
On balance, I don't think either approach is ideal, and the best strategy is probably a dynamic balance between them that mostly favors managers being managers (though with the rule that all managers must have been highly competent SWEs) and SWEs being SWEs, but with plenty of scope for exceptions where a project needs a small team of 3-4 people and there's a clear leader with deep technical ability and good people skills.
Anyway, Google has pushed the pendulum away from TLMs and as a result there are many fewer managers, and each manager tends to have a larger team.
(Disclaimer: I work for Google. I used to be a TLM but opted to switch back to an IC role years ago, before the rule change.)
Re: (Score:2)
Re: (Score:2)
This can cause them to be less effective as managers because they don't navigate the system on behalf of their employees as effectively. Some of them may not be very good at defending their reports' ratings and promotions because they don't have the skills to do that, even though they deeply understand the team's contributions.
Why do managers have to "defend" their reports? If the team is performing, then everyone on the team should get better ratings. The only exception should be if most team members agree someone is not pulling their weight.
Aside from being a ton of unnecessary work and unfairly punishing people for having been hired by less experienced managers, it's not even possible to evaluate each person's work in a vacuum. The guy who's helping everyone else with their problems is the one who gets dinged at eval time beca
Re: (Score:2)
Why do managers have to "defend" their reports? If the team is performing, then everyone on the team should get better ratings.
It's really common in medium-to-large companies for all the managers to get together every year, and discuss who will get a raise/promotion and who will not. The number of raises available is limited, so if the manager wants to get a raise for someone on his team, he/she has to know how to fight for it.
The number of raises/promotions is limited in order to keep payroll as small as possible.
Re: (Score:2)
The number of raises/promotions is limited in order to keep payroll as small as possible.
That's the appealingly-cynical view, but it's not really correct.
Of course keeping payroll down is important if the business is going to remain profitable, but the other piece of the profitability puzzle is productivity, and in this case that's the more important piece. Raises and promotions are limited because if they weren't there would be no financial motivation for good job performance, because why wouldn't you just give raises and promotions to everyone, or at least everyone you like? Creating that
Re: (Score:2)
Of course keeping payroll down is important if the business is going to remain profitable, but the other piece of the profitability puzzle is productivity, and in this case that's the more important piece.
If that were true, then the number of raises available would adjust to match skill level. Anyone who reaches the appropriate skill level will be given a raise. You wouldn't need to contend with other managers over it.
The best way to keep payroll as small as possible is not to give any raises or promotions.
The other half of the puzzle is to look at how many people are quitting. When too many people quit, then you increase the number of raises/promotions available.
Re: (Score:3)
This can cause them to be less effective as managers because they don't navigate the system on behalf of their employees as effectively. Some of them may not be very good at defending their reports' ratings and promotions because they don't have the skills to do that, even though they deeply understand the team's contributions.
Why do managers have to "defend" their reports? If the team is performing, then everyone on the team should get better ratings. The only exception should be if most team members agree someone is not pulling their weight.
Aside from being a ton of unnecessary work and unfairly punishing people for having been hired by less experienced managers, it's not even possible to evaluate each person's work in a vacuum. The guy who's helping everyone else with their problems is the one who gets dinged at eval time because they have nothing to show for themselves, even if every time they give help, they're saving several hours or days of work for someone else.
In Google, and most large companies, peer feedback is the largest part of the evaluation, so helping everyone else is almost certain to generate lots of good feedback... though if you do it so much that you don't get your own work done and that causes problems for your peers, you will get that negative feed back, too.
As to your question about defending their reports... what alternative approach would you suggest? Let the manager just decide without anyone testing those decisions? Not only would that give
Re: (Score:2)
As to your question about defending their reports... what alternative approach would you suggest?
Give raises to teams and not individuals. The smallest group of people that has an objectively measurable output value should all get the same raise, and the amount of that raise should be tied to how much value they provided.
This is how startups operate. Workers are offered a lot of potential reward, but that reward is tied to the success of their team (which in a startup is the whole company). In a large company, you have minimal motivation for doing a great job. As you described, there's this overly conv
Re: (Score:2)
Re: (Score:2)
Then why do high performers leave big companies for startups? Don't they know they'll be carrying the whole company on their shoulders? I mean, what if the founder's brother, who does nothing but has a 10% stake in the company, is unjustly enriched?
In reality, most people don't care as long as their hard work turn into better compensation. They don't have to make more than the guy sitting next to them to be happy. Those that can't are people you want to get rid of ASAP, before they turn your whole company c
Re: (Score:2)
Then why do high performers leave big companies for startups?
Equity that may become worth millions. Joining a startup is a bet on massive, life-changing future rewards. Established companies can't offer that.
FWIW, I'm a Google high-performer leaving Google in two weeks (after 14 years), for a startup :D
Re: (Score:2)
Why do managers have to "defend" their reports?
Because that's the only way to ensure the reports are sufficiently accurate. And this is not limited to management/team reports. It is a necessary step to ensure a value judgment, measure, assessment or proposition is reasonable and quantifiable.
To "defend" is to explain, hopefully with quantifiable evidence. You give a report, you defend your findings. You submit a code for review, you defend and explain your coding decisions. You leave a comment or critique on a report or code review, you need to explai
Re: (Score:2)
I don't think you are wholly disagreeing with me.
"TLMs can end up overwhelmed by the administrative overhead."
Good managers - those who lead and run their people well - should not have to deal with large admin overhead. It's why I stopped managing long ago and never went back.
Bad managers will jump in and do the admin stuff ( because it's often all they can do ), and stay on as managers.
Managers should be able to run their team to make stuff, and be judged on tha
Re: (Score:2)
There used to be a lot of software engineers (people on the software engineer job ladder, as opposed to the engineering manager job ladder) who had 2-3 people reporting to them and were considered TLMs.
I didn't know about this in google... and that sounds truly inefficient. A tech lead (or staff or principal engineer or scientist above them) is not supposed to be a front-line manager.
And a front-line manager is not supposed to be acting as a tech lead (at least not most of the time.)
A somewhat imperfect way of seeing this is that a tech/staff/principal lead/engineer or scientist acts like a corporal or sergeant whereas a front-line manager acts like an LT or captain. Leads are in charge of giving te
Re: (Score:2)
There used to be a lot of software engineers (people on the software engineer job ladder, as opposed to the engineering manager job ladder) who had 2-3 people reporting to them and were considered TLMs.
I didn't know about this in google... and that sounds truly inefficient. A tech lead (or staff or principal engineer or scientist above them) is not supposed to be a front-line manager.
And a front-line manager is not supposed to be acting as a tech lead (at least not most of the time.)
Current management agrees with you. My experience is that mixing the roles can work extremely well in the right situations, and that those situations are fairly common in software companies.
Also one nit: It doesn't make sense to talk about a tech lead or staff or principle engineer above them. Tech lead is a team role, not a level. A tech lead can be any level. Typically they're at least a Senior SWE, though they can be anything up to and including a Fellow, if they're the technical lead for a projec
This usually means (Score:3)
They learned the trick from IBM
Only? (Score:2)
My sandwich is 35% made (Score:1)
I believe I'm correct in saying...
Only 65% to go! before actual-productivity is maximised. Let's pause on the preemptive celebrations.
Meh (Score:2)