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

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

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

> 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?

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)

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.