4 ms·

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 managemen

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.
  - itsanaccount 1y ago
    its called the straw boss. as in "and the strawboss said well a-bless my soul, you load 16 tons.."
jakevoytko 1y ago
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.
- greesil 1y ago
  People that selfish shouldn't be managing people.
  - integralid 1y ago
    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.
Dylan16807 1y ago
> 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?
- xenotux 1y ago
  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.
kelnos 1y ago
> 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.
- gambiting 1y ago
  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.
- makeitdouble 1y ago
  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)
- b112 1y ago
  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?
  - const_cast 1y ago
    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.

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.
- itsanaccount 1y ago
  its called the straw boss. as in "and the strawboss said well a-bless my soul, you load 16 tons.."

jakevoytko 1y ago

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.

greesil 1y ago
People that selfish shouldn't be managing people.
- integralid 1y ago
  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.

Dylan16807 1y ago

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

xenotux 1y ago
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.

kelnos 1y ago

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

gambiting 1y ago
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.
makeitdouble 1y ago
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)
b112 1y ago
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?
- const_cast 1y ago
  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.