Comment Re:Knowing middle managers... (Score 5, Informative) 18
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.)
