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.
as in "and the strawboss said well a-bless my soul, you load 16 tons.."
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?
> 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.
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 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)
For this to be accurate, you're saying 160% aka 1.6 or 64 to 80 hrs per week, with 96hrs as the extreme?
Anecdotally, a hybrid technical manager I had in the past worked 60 hours a week pretty much minimum. Which sucks.
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...)
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.
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.
(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?
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.
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.
At the risk of oversimplifying, the role of a manager is to find you that TL.
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.
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.