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.
corytheboyd · 22m ago
TLM role has always sounded like a trap to me, I would never say yes to it personally. I’m sure it’s sold as an expected 50% code, 50% management but everyone I’ve talked to who has been near it says the expectation is more like 80% code 80% management.
xenotux · 14s ago
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.
AIPedant · 7m ago
It sounds to me like Google is moving to a more typical "technical lead" model where leads have substantial authority and some mentorship responsibilities, but they're essentially an IC and someone else up the chain actually handles proper management. Informally, tech leads can gently chew out less senior devs, but if someone actually needs to be disciplined then the lead needs to talk to the manager.
TLM is an odd role. I understand big tech companies have their own culture but it does seem like a poor management strategy regardless of efficiency.
lanthissa · 54m ago
we had this in my company it was pretty hit miss. Almost always the 'TLM' was someone who was in the role for a really long time and it warranted a second person, so it ended up being a 1-2 junior reporting in absorbing the knowledge that the tlm had.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
nostrademons · 10m ago
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.
godelski · 5m ago
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.
greesil · 17m ago
This reads like "get rid of the old experienced people so I can get promoted".
mpyne · 45s ago
The U.S. military actually uses precisely that system for officer promotions. And in practice most of the U.S. military branches do essentially the same thing for their enlisted force too, deliberately allowing high attrition for the sake of frequent promotions.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
lanthissa · 9m ago
only if you're cynical, google found a much better solution though, make them IC's again and redistribute the junior talent to places they can grow and offer buyouts for anyone who feels like they're not into it anymore.
Spivak · 9m ago
If your position has no upward mobility juniors will change jobs, likely change companies, once they have the experience and all the effort you spent training them will be wasted.
floren · 1h ago
Do you have any opinion on the success/value of the TLM role?
tibbar · 1h ago
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.
No comments yet
allknowingfrog · 6m ago
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.
pesfandiar · 1h ago
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.
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.
nvarsj · 40m ago
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.
mandevil · 22m ago
As someone who has worked in companies from <30 to >100k, I would say that what an EM does is more about communication. Think of a company with m employees as a m by m matrix, with a 1 where there regular communication and a 0 where there is no communication and a 0.5 for those hallway meetings which our CEO's assure us are why RTO is so important.
In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."
nostrademons · 1h ago
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.
oceanparkway · 39m ago
Brutal
chris_va · 1h ago
(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.
mi_lk · 1h ago
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
Spooky23 · 1h ago
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.
AnotherGoodName · 46m ago
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.
vkou · 1h ago
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.
spankalee · 1h ago
I never worked with a TLM who actually wrote code regularly.
HardCodedBias · 18m ago
TLM role was both the best and worst role in tech.
Best in that the TLM generally has complete control over the product execution (and can commonly bulldoze the PM). It's amazing if you have a solid vision of what you want and you want to get it done.
Worst in that the workload can be intense as the team grows.
giantg2 · 1h ago
We did something like this but called it a different name. It was absolute garbage. Its really no surprise to see those roles move back to a more traditional alignment.
p1esk · 58m ago
Why was it bad?
giantg2 · 5m ago
It was terrible because the "managers" had very little training which made them mostly useless and a legal liability to the company in regards to employment law cases. In many instances they weren't even on the same direct team but an adjacent team, so rhey hahd very little interaction. This completely invalidated the premise that a technical/coding manager would be a better mentor since there was never any time for it. Of course the company paid them the same rate as the senior devs that weren't managers. I'd say at least 50% of the first year cadre left the company or reverted to a regular senior dev after one year or less. Most divisions of the company don't use this model now. The only real reason they did it was because Google did it.
virtue3 · 52m ago
Managing skills and techlead and IC skills are pretty different disciplines.
Being 50/50 makes it hard to advance/develop in either one of them significantly.
The biggest issue is that management requires a lot of "wasted time" paying attention to whats going on around you and IC skills require a lot of "heads down time". It's a big fight between those two modes.
I've done it at a startup but it required doing most of my IC work after hours. Which isn't that sustainable.
prinny_ · 47m ago
It’s the only point in one’s career where you’re expected to do both programming and managing and it’s hard to do both at the same time and at a good level.
hustwindmaple · 31s ago
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.
bsenftner · 17m ago
Next up: super frustrated ex-google PMs complaining "that's not how it's done at Google" at their new jobs.
mikestew · 1h ago
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?
tibbar · 1h ago
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.
andreimackenzie · 1h ago
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.
deltaburnt · 27m ago
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?
toast0 · 55m ago
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.
LambdaComplex · 46m ago
> 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
fuzzy_biscuit · 27m ago
Would that mean you have to undersee one or more people? cue rimshot
QuadmasterXLII · 44m ago
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.
jldugger · 1h ago
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.
bayindirh · 1h ago
By plucking employees from larger teams until said teams have 0-2 people.
JCM9 · 46m ago
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.
mkoubaa · 39m ago
It's only inefficient if the manager only had management responsibilities, which I doubt is the case in most of these situations.
jeffbee · 1h ago
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.
TheBigSalad · 1h ago
How is it not efficient?
michaelt · 1h ago
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.
n1b0m · 1h ago
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.
Etheryte · 1h ago
If managers oversee 0-2 people in a company, that means it's roughly just one person managing one person managing one etc.
andy_ppp · 4m ago
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.
nailer · 34s ago
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.
whatever1 · 1h ago
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.
Aurornis · 10m ago
> Go to 10 and it’s impossible to keep track of things. The day has only so many hours. Managing takes time.
I've actually had better experiences with higher employee:manager ratios for this reason.
When the manager can't possibly be involved in everything they're forced to let go, delegate, and skip the management busywork.
My worst experiences have been at companies with one manager per 2-3 employees and skip-level managers who were expected to be involved as well. It was a never-ending stream of meetings, weekly hour-long 1:1s with multiple people, goal setting, personal development exercises, and a growing list of scheduled distractions.
The managers felt like they needed to make work to justify their managerial roles, so our time got filled with meetings and activities that didn't contribute to anything other than making the manager feel good about doing things they heard about in podcasts and books.
para_parolu · 49m ago
Every time I see manager with 5 people I know it will be daily 30m standups, friday “summary” meeting, weekly 1:1 and other nok work related activities. If team of 5 people need a babysitter fulltime it means there are no adults on that group.
raincom · 28m ago
Just increase headcount under oneself in order to protect oneself. Isn't it what bureaucracy have been doing all along?
trhway · 24m ago
And all the managers working remotely were replaced with their Gemini versions, and so far nobody has noticed it :).
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.
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.
TLM is an odd role. I understand big tech companies have their own culture but it does seem like a poor management strategy regardless of efficiency.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
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.
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.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
No comments yet
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.
[1] https://paulgraham.com/makersschedule.html
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.
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.
In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."
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.
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.
There’s always a downside to anything, and the merits/demerits are all about the politics of the org.
Simple as that. It’s fine during times of growth but that’s not happening right now.
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.
Best in that the TLM generally has complete control over the product execution (and can commonly bulldoze the PM). It's amazing if you have a solid vision of what you want and you want to get it done.
Worst in that the workload can be intense as the team grows.
Being 50/50 makes it hard to advance/develop in either one of them significantly.
The biggest issue is that management requires a lot of "wasted time" paying attention to whats going on around you and IC skills require a lot of "heads down time". It's a big fight between those two modes.
I've done it at a startup but it required doing most of my IC work after hours. Which isn't that sustainable.
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?
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.
I would have so many questions if I got an offer for a position where I had to oversee less than 0 people
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.
Also 35% is way too low if it’s really less than three. Should be more like eliminating 95% of those scenarios.
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.
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.
For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
I've actually had better experiences with higher employee:manager ratios for this reason.
When the manager can't possibly be involved in everything they're forced to let go, delegate, and skip the management busywork.
My worst experiences have been at companies with one manager per 2-3 employees and skip-level managers who were expected to be involved as well. It was a never-ending stream of meetings, weekly hour-long 1:1s with multiple people, goal setting, personal development exercises, and a growing list of scheduled distractions.
The managers felt like they needed to make work to justify their managerial roles, so our time got filled with meetings and activities that didn't contribute to anything other than making the manager feel good about doing things they heard about in podcasts and books.