Google has eliminated 35% of managers overseeing small teams in past year

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.

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.

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.

This has largely been my experience in TLM roles. You’re a staff/principal level engineer so people still expect outputs from you. However, you now have the job of managing your teams’ impact and outcomes as well.

Impact and outcomes are far more important than outputs, so it makes sense to for you to spend a lot of time on that. But, when performing review time comes around, you’re still bounded by hard metrics around outputs.

But were all the other managers in the team in a TLM role?

The problem I foresee here is, there would be escalation meetings and all the non-technical managers would sit back and point fingers at the TLMs until they leave.

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.

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.

I mostly found TLM a disservice to people who reported to TLMs. They didn't have to earn a promotion as both an engineer and a manager at the same time, so many optimized for their own engineering promotion and any managing they did was out of the goodness of their hearts.

TLM is fine. TPM is the awkward one. I don't understand what hierarchy (if any) there is to TPMs, they kinda float around and ask people to do stuff. Some projects get passed around to different TPMs like hot potato. The skilled TPMs stick around and make things happen, but even then idk how that works because they lead people without having any actual reports.

People that selfish shouldn't be managing people.

its called the straw boss.

as in "and the strawboss said well a-bless my soul, you load 16 tons.."

That is the point of a TPM. They're supposed to be the neutral third party that makes sure you're doing the work, and can explain to upper management why the work is not getting done. As such, they don't have any decision-making power on what the work is or how long it's going to take. Generally the manager and IC negotiate back and forth on what needs doing and on what schedule, they set their own deadlines based on the realities of the project, and then the TPM holds them to what they committed to.

Much of the reason the TPM job exists is simply so your manager can be an advocate rather than a nag. The nag job is offloaded to the TPM, but the TPM has no decision-making power, so you don't get perverse incentives where the manager burns all their relationship capital making you do your work, or sandbags the deadlines so they don't have to.

In many orgs TPMs are also in charge of goodies like fun events or device/swag distribution, as a way to offset the negative emotions that come from them basically being nags.

A few thoughts:

(1) As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.

(2) A manager who actually understands the tech is often better at unblocking the team.

(3) Since senior IC openings tend to grow very thin as you become older, TLM path might be a viable career path for at least some.

Can this role work if we don't expect IC output from the TLM beyond what they themselves take on for their own satisfaction and growth?

When you become a good enough IC, “ As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.” is no longer reasonable. Then your managers role is to maximize your ability to make an impact by putting you in the right place/project.

As a manager of people who know far more about the things they do than I do, my goal is to assist and ensure in the right place (for them and the org). It’d be foolish for me to hire peons who know less than me.

> If you don't suck at management, your team inevitably grows

Inevitably because why?

> those who suck at management

If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?

> those managing dead-end projects on dead-end teams

If "dead-end" just means "not growing" then that sounds fine. When a company does thousands of things only a small fraction of them need to be growing.

> those who desperately cling on to the engineering past and actively refuse to take on more people

"Desperately cling" is a wild way to refer to someone sticking with a job they like. And if they're a TLM it's not the past, it's the present. Wanting to keep your present job is very normal.

And is the end goal to have zero TLMs in this expanded team? If you're going to pick new TLMs to go under the one you push into higher management, what's bad about leaving them in place and putting someone else above them?

Control issues prevent experienced IC from just roaming the halls looking for trouble.

Not sure why you'd take the leap from the idea of technical people managing technical people to "hiring peons who know less than me", that wasn't my intention. Also "as an engineer" was rhetorical -- I'm a manager myself and it's been over 15 years since I've been an engineer. So I do see the point you're trying to make. I still feel the immediate management layer above mid-level ICs should have some level of hands-on knowledge of the system they're developing. At the next level up, I think engineering fundamentals and past technical experience would suffice.

Look, I'm trying to describe reality; you seem to be expecting me to defend it. But briefly:

> Inevitably because why?

Because proven, effective managers are always in short supply, so when you hire new people, or if any of the existing managers leaves, it's the default pick.

Plus, most people want to make more money over time. And on the management track, this means angling for that director / VP role down the line, even if it wasn't your childhood dream.

> If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?

They can, but in big and / or growing companies, performance problems are addressed less vigorously than they probably should. This cuts both ways: neglecting problems is wrong, but cutthroat performance management makes people cranky too.

> There's no expectation that you do two jobs at once.

I laughed out loud when I read this. I've never seen anyone at any company in a hybrid tech/manager role that wasn't expected to do two jobs at once. Or at least they felt like they were, which is still the same problem.

80% coding & 80% management for that role sounds about right.

As a devil's advocate (I don't work in Google or in a similar role) but if the requirements for engineering promotion are similar for technical managers and engineers, while the first have to manage people then this is just how the system is set up. In this case I think blaming the system more than people is justified, and Google decided to dismantle the role for some reason.

I've been a TLM at two big companies and in my experience there was no expectation to do two jobs at once - I did majority of management with very very little hands on coding. More like frequent pair programming with more junior staff, code reviews etc. My last manager told me explicitly when I started - there is zero expectation on you to do any hands on work, you need to make sure your team performs and keeps going in the right direction first and foremost.

80 / 80 is sure close to reality.

As alternative explanation, even if there's no pressure to do so, the thing is these people came to do dev, and probably enjoyed their job enough to get recognized for their work.

So when asked to split between dev and management, outside of a few exceptions they'll want to do 80% of tech by choice. But the management part doesn't go away of course, so it will still be at least 50% (and 80% if they want money, because that's the part they're actually evaluated on)

GP made the point that early in your career, your boss should absolutely know more than you do about your technical work, but at some point (fairly early), that inverts and your leader unavoidably knows less than you do about your technical work, because you’re the expert on the team at it and they can’t know more than all 5-8 of their reports like you can when leading 3-5 junior/new devs.

In post 1, you want your lead to preferably know more, someone says that’s not realistic, and in post 2, you profess to not understand their point while changing the goal post to now be “some level of hands-on knowledge”, which sounds like you do understand their point.

Most work 40 to 50 hrs per week. Some places even a more extreme 60.

For this to be accurate, you're saying 160% aka 1.6 or 64 to 80 hrs per week, with 96hrs as the extreme?

I mean, 64 - 80 hours a week can be the expectation, and then it's just that almost nobody is living up to the expectation.

Anecdotally, a hybrid technical manager I had in the past worked 60 hours a week pretty much minimum. Which sucks.

Management requires a birds-eye view of the project in all its breadth, and quickly responding to issues, as well as reporting up (proactive stakeholder management). The job of the manager is to keep the CXOs happy (inform/manage expectations) whilst protecting their own team so they can focus on getting their work done with minimal disruption (isolate).

Coding requires the opposite, zooming deeply into the code and retaining focus. The job of the IC coder is to deliver (design and implement) beautiful and pragmatic architectures that do what is expected.

I recommend anyone to reject to fill roles where these two are combined into one. Note that this is not a comment about workload, but about irreconcileable differences. (The perfect candidates for each even match different personality profiles...)

I've been in engineering, TLM, and management roles in multiple companies. In terms of output, TLMs are not held to the same standard as full-time engineers at the same level, period. Their engineering contributions are dissected only if their performance as a manager is in serious doubt.

In any role, there are some folks who push themselves too hard, and there is no one to tell them "stop", but that's their choice.

This is true for EMs at my company. They are pretty heavily technical, with full manager responsibilities. I honestly always assumed that's what EMs were.

What you're asking for is more of a TL.

At the risk of oversimplifying, the role of a manager is to find you that TL.