Hacker News Reader

Comment by floren | Hacker News Reader

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

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.

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.

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

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.

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.

Brutal

As a current IC, +1. I don’t know if it’s the case globally at Google, but I certainly know it’s also this way in my org.

+1, L5 IC in google. Your words resonate a lot with what I feel about current org, and it’s great to have this validation besides corporate gaslighting

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.

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

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.

Thanks for this message, this is actually helpful :). I have been a TLM/EM for the last 4 years, and I still struggle at times to define what my role is about...and in downtime moments (which are rare, most of the time, you are overloaded), what the fuck should I spend my time on.

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.

(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.

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.

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

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.

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.

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.

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.

I never worked with a TLM who actually wrote code regularly.

Reply on news.ycombinator.com