8 ms·

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

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.

floren 1y ago
Do you have any opinion on the success/value of the TLM role?
- tibbar 1y 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.
  - deleted 1y ago
    [deleted]
  - kelnos 1y ago
    I was thinking this too. Tech lead/developer and manager are two completely different jobs. I can see TLM as a useful transitional thing, while the person is being trained or mentored at being a manager (and hopefully not just thrown into the deep end). But 6 months, max 12, I think. Otherwise it just becomes a role where someone has two jobs and ends up overworked.
- chris_va 1y 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.
  - gdbsjjdn 1y ago
    10 is a lot for a first time manager, but too few reports is also bad for a new manager. 4-5 direct reports is probably the sweet spot where you actually get some experience and the team is big enough that interpersonal stuff averages out.
- vkou 1y 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.
- pesfandiar 1y 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. [1] https://paulgraham.com/makersschedule.html https://paulgraham.com/makersschedule.html
- spankalee 1y ago
  I never worked with a TLM who actually wrote code regularly.
- mi_lk 1y 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
  - BoorishBears 1y ago
    The is funny to read because it captures my feelings on this exactly: when you're a company of passionate people driven by a mission from the top down (very important this alignment is genuinely top down), the drawbacks of the TLM-like position are totally workable: the org gives some grace and flexibility to everyone involved knowing that the TLM is sacrificing some effectiveness as an IC, those under them are losing some room for direct impact. It all works out as long you're able to "grow the pie" and make up for the smaller slices by executing. Once you're late stage though, that's done. TLMs are probably being held to 100% of IC standards and manager standards, people under them are jockeying for "impact" and don't want to compete with their manager, etc. I totally see why it wouldn't work at today's Google. Honestly maybe it's a positive sign they recognized that.
- Spooky23 1y 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.
- nostrademons 1y 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.
- baud147258 1y ago
  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.
- AnotherGoodName 1y 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.
- deleted 1y ago
  [deleted]
- nvarsj 1y 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 1y 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 1y ago
      That's a large part of it. Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project." Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out). But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.
- allknowingfrog 1y 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.
giantg2 1y 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 1y ago
  Why was it bad?
  - prinny_ 1y 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.
  - virtue3 1y 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.
  - giantg2 1y 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.
lanthissa 1y 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.
- greesil 1y ago
  This reads like "get rid of the old experienced people so I can get promoted".
  - Spivak 1y 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.
    - gedy 1y ago
      If your position has no authority seniors will change jobs, likely change companies, and all the effort you spent on them will be wasted.
      - Spivak 1y ago
        I don't know why you think this is an either or situation. Not being a junior doesn't stop you from having a manger.
corytheboyd 1y 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 1y 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.
  - devcamcar 1y ago
    Usually it means you have to manage people but you have no real input on their career trajectory, and in the worst case, if they need to be fired you do not have the power to do so.
    - gdbsjjdn 1y ago
      This was my experience in a TLM role - you have to manage down to your ICs but you have little lateral or upward power. You're basically just conveying whatever your manager decides to do with your team, but with all the additional responsibilities of a staff engineer.
      - xenotux 1y ago
        In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.
HardCodedBias 1y 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.
AIPedant 1y 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.
- surajrmal 1y ago
  By make-up I think most TLs at Google had no reports even before this change. The idea of ICs in leadership has always been a common occurrence at Google. If anything I don't really see it as commonly outside of Google.
- xenotux 1y ago
  The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers. Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people. But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
  - JustExAWS 1y ago
    > But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given. There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done. A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles. At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in. I’m a staff engineer. Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.
sershe 1y ago
Not at Google but I'm in such a role right now and I really dislike it. Can't really get much focused coding in because you constantly have to jump in to review something or help fix something or handle a live site juniors cannot handle, or update some TPS report on what everyone is doing, or some PowerPoint or whatever. I dislike all of these to start with, but getting my own (expected) features in is an exercise in frustration. And when I ignore people and try to have uninterrupted time it feels like I'm neglecting all this other stuff. I wonder who thrives in such a mixed role...
- vl 1y ago
  I just structure my time Monday-Wed-Fri meetings, Tue-Thu no meetings coding. Yes, sometimes non-urgent things have to wait a day.
B-Con 1y ago
GOOG has made a systemic push to eliminate the role starting ~3 years ago. At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM. In those last 3 years I've only seen TLMs used to assist an overloaded EM. The pattern I've seen is something like: Principal EM |- Staff EM (7 reports, project A) |- Staff EM (8 reports, project B) |- Staff IC (projects A, B, C) |- Senior IC (projects A, B) |- Senior IC (project C) |- Mid level IC (project C) |- Mid level IC (project C) Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time. So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc. Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM. Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.) (Edit for formatting.)
- twsted 1y ago
  Can someone explain the various acronyms?
  - Jagerbizzle 1y ago
    EM = Engineering Manager IC = Individual Contributor
  - Muromec 1y ago
    IC -- individual contributor, EM -- enginering manager, TLM -- technical lead manager
- dhx 1y ago
  Do you have a mapping to roles/levels[1], for example: Principal EM - USD$1.3m/yr per https://www.levels.fyi/companies/google/salaries/software-engineering-manager/levels/l8 https://www.levels.fyi/companies/google/salaries/software-en... Staff EM - USD$664k/yr per https://www.levels.fyi/companies/google/salaries/software-engineering-manager/levels/l7 https://www.levels.fyi/companies/google/salaries/software-en... Staff IC - USD$557k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l6 https://www.levels.fyi/companies/google/salaries/software-en... Senior IC - USD$410k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l5 https://www.levels.fyi/companies/google/salaries/software-en... Mid IC - USD$290k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l4 https://www.levels.fyi/companies/google/salaries/software-en... levels.fyi doesn't appear to use the term "Technical Lead". There is "Technical Program Manager" and "Technical Account Manager" that sound like they'd be similar (someone technical transitioning into a full-time non-technical role). And then roles such as "Product Manager" and "Program Manager" seemingly for those who are currently 100% non-technical in their work. Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day? [1] https://www.levels.fyi/companies/google/salaries/software-engineer?country=254 https://www.levels.fyi/companies/google/salaries/software-en...
lallysingh 1y ago
I remember TLMs being considered a bad idea in 2010. Looks like the pendulum took a full swing in the mean time.
bushbaba 1y ago
A TLM reduction isn’t any middle management reduction. It’s an IC role still.
lovich 1y ago
> This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers. Ohhhh this explains so much. My career is pretty much entirely at b tier companies who try to implement what faangs/mag7 type companies do but always fuck it up because they don’t understand the fundamentals or are unwilling to part with any of amount of power or money even if they got more after all was said and done. Anyways post covid all of a sudden every company was expecting me as part of the Software Engineering Manager roles I was getting, to have 7-10 direct reports, do 30 hours of project management per week, _and_ simultaneously be better versed in every single project my direct reports were working on or at least be the initial architect for the project. I just ignored it and kept my people productive since that was an impossible ask of me, and for 5ish years that was good enough for companies but I guess if the faangs are wiping that role clean I better switch career niche again
0xbadcafebee 1y ago
> It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles. The hybrid role idea has always been ridiculous. It's two different jobs, like being a mechanic and an accountant. Do you need a mechanic? Cool, hire a mechanic. Do you only need a mechanic part-time? Cool, hire a part-time mechanic. But I don't want my mechanic stopping and starting the work on my engine 3 times a day because somebody has tax questions. The whole point behind the division of labor is to specialize, and get really good at your specialization. Picking up multiple very different jobs and trying to do both is the opposite of efficiency. People knew this 250 years ago.
pfooti 1y ago
I was a TL and then a TLM in my org, and am now an EM. I'm actually pretty happy about it, personally. I am organizing an eng summit tomorrow between my team and a sibling team (which is onsite and visiting from elsewhere) in my org, and I noticed that about 18 months ago, I would have been the person to give 4 out of the 5 main talks at the summit (as the expert / TL on that system). Now it's five different eng. This tells me I've been able to nurture / elevate the other engineers on the team, get them all into technical leadership roles, and then have them reach out and be ready to talk about their work to other teams. Overall: this is a good thing. By taking up less room on the technical side, I've replaced one of me with four strong engineers. Previously, I was split between TL work and EM work and as a result, did a half job of each, leaving too much un-done. The other thing I'll note is that engineers are basically the only role with this distinction. Product Managers, Program Managers, Sales, Marketing, all those roles seem to combine management with seniority. Only on the engineering side do we have both a TL and Manager hierarchy (while typically the TLs for a team report to the same manager that the line manager for the team does, they exert authority differently). This works out okay on the eng side when there is a strong alliance between the TLs and the EMs, but that doesn't always happen.
litmus-pit-git 1y ago
A recruiter in India was talking to me about some roles for some time and then disappeared. After a few weeks, when I was ready for interviews, I reached back. I was informed that those roles didn't exist anymore. I enquired further asking wahether those roles were filled, and the reply was something on the lines that no, they didn't exist anymore. Bit of a bummer because Google was one of the very few companies here that actually interviewed you pretty fairly even after a considerable employment gap. Those were L7 roles (not sure whether those are around TLM).
kelnos 1y ago
I think this is a good thing. Every time I've seen people in dual tech/management roles at any company, they've always been incredibly stressed about their job, and always have way too much to do. I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. Even if your TLM is pushing a bad technology choice, you might not want to push back too hard because they're also responsible for your performance review and comp changes and whatnot.
- johnnyanmac 1y ago
  >always been incredibly stressed about their job, and always have way too much to do. So, no different from any other dedicate IC or manager at these companies? >I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. How is this different from any other manager or higher up making decisions? If your boss or boss's boss really wants something and you're not in a good market, it's never a good time to poke your head out.
  - integralid 1y ago
    >How is this different from any other manager or higher up making decisions? Non-technical managers usually don't have strong opinions about which framework or database to use. Among engineers these decisions are usually made in a meritocratic way (weighted by who is the loudest sadly), but if your manager says "let's use X" it has a different weight than if your peer does.
- Scea91 1y ago
  I was in such a role and am now being pushed out of it (promoted to PE). What I really love about it is the leverage. In a technical domain with a good core team it is almost like running your small company.
seanmcdirmid 1y ago
Some TLMs have been moved into people manager roles, it is not a move that brings the most joy vs just getting to be a TL without M again.

floren 1y ago

Do you have any opinion on the success/value of the TLM role?

tibbar 1y 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.
- deleted 1y ago
  [deleted]
- kelnos 1y ago
  I was thinking this too. Tech lead/developer and manager are two completely different jobs. I can see TLM as a useful transitional thing, while the person is being trained or mentored at being a manager (and hopefully not just thrown into the deep end). But 6 months, max 12, I think. Otherwise it just becomes a role where someone has two jobs and ends up overworked.
chris_va 1y 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.
- gdbsjjdn 1y ago
  10 is a lot for a first time manager, but too few reports is also bad for a new manager. 4-5 direct reports is probably the sweet spot where you actually get some experience and the team is big enough that interpersonal stuff averages out.
vkou 1y 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.
pesfandiar 1y 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. [1] https://paulgraham.com/makersschedule.html https://paulgraham.com/makersschedule.html
spankalee 1y ago
I never worked with a TLM who actually wrote code regularly.
mi_lk 1y 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
- BoorishBears 1y ago
  The is funny to read because it captures my feelings on this exactly: when you're a company of passionate people driven by a mission from the top down (very important this alignment is genuinely top down), the drawbacks of the TLM-like position are totally workable: the org gives some grace and flexibility to everyone involved knowing that the TLM is sacrificing some effectiveness as an IC, those under them are losing some room for direct impact. It all works out as long you're able to "grow the pie" and make up for the smaller slices by executing. Once you're late stage though, that's done. TLMs are probably being held to 100% of IC standards and manager standards, people under them are jockeying for "impact" and don't want to compete with their manager, etc. I totally see why it wouldn't work at today's Google. Honestly maybe it's a positive sign they recognized that.
Spooky23 1y 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.
nostrademons 1y 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.
baud147258 1y ago
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.
AnotherGoodName 1y 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.
deleted 1y ago
[deleted]
nvarsj 1y 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 1y 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 1y ago
    That's a large part of it. Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project." Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out). But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.
allknowingfrog 1y 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.

giantg2 1y 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 1y ago
Why was it bad?
- prinny_ 1y 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.
- virtue3 1y 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.
- giantg2 1y 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.

lanthissa 1y 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.

greesil 1y ago
This reads like "get rid of the old experienced people so I can get promoted".
- Spivak 1y 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.
  - gedy 1y ago
    If your position has no authority seniors will change jobs, likely change companies, and all the effort you spent on them will be wasted.
    - Spivak 1y ago
      I don't know why you think this is an either or situation. Not being a junior doesn't stop you from having a manger.

corytheboyd 1y 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 1y 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.
- devcamcar 1y ago
  Usually it means you have to manage people but you have no real input on their career trajectory, and in the worst case, if they need to be fired you do not have the power to do so.
  - gdbsjjdn 1y ago
    This was my experience in a TLM role - you have to manage down to your ICs but you have little lateral or upward power. You're basically just conveying whatever your manager decides to do with your team, but with all the additional responsibilities of a staff engineer.
    - xenotux 1y ago
      In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.

HardCodedBias 1y 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.

AIPedant 1y 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.

surajrmal 1y ago
By make-up I think most TLs at Google had no reports even before this change. The idea of ICs in leadership has always been a common occurrence at Google. If anything I don't really see it as commonly outside of Google.
xenotux 1y ago
The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers. Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people. But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
- JustExAWS 1y ago
  > But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given. There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done. A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles. At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in. I’m a staff engineer. Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.

sershe 1y ago

Not at Google but I'm in such a role right now and I really dislike it. Can't really get much focused coding in because you constantly have to jump in to review something or help fix something or handle a live site juniors cannot handle, or update some TPS report on what everyone is doing, or some PowerPoint or whatever. I dislike all of these to start with, but getting my own (expected) features in is an exercise in frustration. And when I ignore people and try to have uninterrupted time it feels like I'm neglecting all this other stuff. I wonder who thrives in such a mixed role...

vl 1y ago
I just structure my time Monday-Wed-Fri meetings, Tue-Thu no meetings coding. Yes, sometimes non-urgent things have to wait a day.

B-Con 1y ago

GOOG has made a systemic push to eliminate the role starting ~3 years ago. At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM. In those last 3 years I've only seen TLMs used to assist an overloaded EM. The pattern I've seen is something like: Principal EM |- Staff EM (7 reports, project A) |- Staff EM (8 reports, project B) |- Staff IC (projects A, B, C) |- Senior IC (projects A, B) |- Senior IC (project C) |- Mid level IC (project C) |- Mid level IC (project C) Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time. So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc. Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM. Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.) (Edit for formatting.)

twsted 1y ago
Can someone explain the various acronyms?
- Jagerbizzle 1y ago
  EM = Engineering Manager IC = Individual Contributor
- Muromec 1y ago
  IC -- individual contributor, EM -- enginering manager, TLM -- technical lead manager
dhx 1y ago
Do you have a mapping to roles/levels[1], for example: Principal EM - USD$1.3m/yr per https://www.levels.fyi/companies/google/salaries/software-engineering-manager/levels/l8 https://www.levels.fyi/companies/google/salaries/software-en... Staff EM - USD$664k/yr per https://www.levels.fyi/companies/google/salaries/software-engineering-manager/levels/l7 https://www.levels.fyi/companies/google/salaries/software-en... Staff IC - USD$557k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l6 https://www.levels.fyi/companies/google/salaries/software-en... Senior IC - USD$410k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l5 https://www.levels.fyi/companies/google/salaries/software-en... Mid IC - USD$290k/yr per https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l4 https://www.levels.fyi/companies/google/salaries/software-en... levels.fyi doesn't appear to use the term "Technical Lead". There is "Technical Program Manager" and "Technical Account Manager" that sound like they'd be similar (someone technical transitioning into a full-time non-technical role). And then roles such as "Product Manager" and "Program Manager" seemingly for those who are currently 100% non-technical in their work. Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day? [1] https://www.levels.fyi/companies/google/salaries/software-engineer?country=254 https://www.levels.fyi/companies/google/salaries/software-en...

lallysingh 1y ago

I remember TLMs being considered a bad idea in 2010. Looks like the pendulum took a full swing in the mean time.

bushbaba 1y ago

A TLM reduction isn’t any middle management reduction. It’s an IC role still.

lovich 1y ago

> This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers. Ohhhh this explains so much. My career is pretty much entirely at b tier companies who try to implement what faangs/mag7 type companies do but always fuck it up because they don’t understand the fundamentals or are unwilling to part with any of amount of power or money even if they got more after all was said and done. Anyways post covid all of a sudden every company was expecting me as part of the Software Engineering Manager roles I was getting, to have 7-10 direct reports, do 30 hours of project management per week, _and_ simultaneously be better versed in every single project my direct reports were working on or at least be the initial architect for the project. I just ignored it and kept my people productive since that was an impossible ask of me, and for 5ish years that was good enough for companies but I guess if the faangs are wiping that role clean I better switch career niche again

0xbadcafebee 1y ago

> It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles. The hybrid role idea has always been ridiculous. It's two different jobs, like being a mechanic and an accountant. Do you need a mechanic? Cool, hire a mechanic. Do you only need a mechanic part-time? Cool, hire a part-time mechanic. But I don't want my mechanic stopping and starting the work on my engine 3 times a day because somebody has tax questions. The whole point behind the division of labor is to specialize, and get really good at your specialization. Picking up multiple very different jobs and trying to do both is the opposite of efficiency. People knew this 250 years ago.

pfooti 1y ago

I was a TL and then a TLM in my org, and am now an EM. I'm actually pretty happy about it, personally. I am organizing an eng summit tomorrow between my team and a sibling team (which is onsite and visiting from elsewhere) in my org, and I noticed that about 18 months ago, I would have been the person to give 4 out of the 5 main talks at the summit (as the expert / TL on that system). Now it's five different eng. This tells me I've been able to nurture / elevate the other engineers on the team, get them all into technical leadership roles, and then have them reach out and be ready to talk about their work to other teams. Overall: this is a good thing. By taking up less room on the technical side, I've replaced one of me with four strong engineers. Previously, I was split between TL work and EM work and as a result, did a half job of each, leaving too much un-done. The other thing I'll note is that engineers are basically the only role with this distinction. Product Managers, Program Managers, Sales, Marketing, all those roles seem to combine management with seniority. Only on the engineering side do we have both a TL and Manager hierarchy (while typically the TLs for a team report to the same manager that the line manager for the team does, they exert authority differently). This works out okay on the eng side when there is a strong alliance between the TLs and the EMs, but that doesn't always happen.

litmus-pit-git 1y ago

A recruiter in India was talking to me about some roles for some time and then disappeared. After a few weeks, when I was ready for interviews, I reached back. I was informed that those roles didn't exist anymore. I enquired further asking wahether those roles were filled, and the reply was something on the lines that no, they didn't exist anymore. Bit of a bummer because Google was one of the very few companies here that actually interviewed you pretty fairly even after a considerable employment gap. Those were L7 roles (not sure whether those are around TLM).

kelnos 1y ago

I think this is a good thing. Every time I've seen people in dual tech/management roles at any company, they've always been incredibly stressed about their job, and always have way too much to do. I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. Even if your TLM is pushing a bad technology choice, you might not want to push back too hard because they're also responsible for your performance review and comp changes and whatnot.

johnnyanmac 1y ago
>always been incredibly stressed about their job, and always have way too much to do. So, no different from any other dedicate IC or manager at these companies? >I've also never really liked the idea of engineering managers who are technical enough to approve/veto tech decisions that team members make, since there's a power imbalance there. How is this different from any other manager or higher up making decisions? If your boss or boss's boss really wants something and you're not in a good market, it's never a good time to poke your head out.
- integralid 1y ago
  >How is this different from any other manager or higher up making decisions? Non-technical managers usually don't have strong opinions about which framework or database to use. Among engineers these decisions are usually made in a meritocratic way (weighted by who is the loudest sadly), but if your manager says "let's use X" it has a different weight than if your peer does.
Scea91 1y ago
I was in such a role and am now being pushed out of it (promoted to PE). What I really love about it is the leverage. In a technical domain with a good core team it is almost like running your small company.

seanmcdirmid 1y ago

Some TLMs have been moved into people manager roles, it is not a move that brings the most joy vs just getting to be a TL without M again.