←back to thread

574 points frays | 1 comments | | HN request time: 0s | source
Show context
AnotherGoodName ◴[] No.45045883[source]
This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers.

It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.

This is being sold as an efficiency win for the sake of the stock price but it’s really just moved a few people around with the TLMs now 100% focused on programming.

replies(15): >>45045891 #>>45046165 #>>45046216 #>>45046446 #>>45046469 #>>45046545 #>>45046627 #>>45046811 #>>45047198 #>>45047268 #>>45048052 #>>45048255 #>>45048293 #>>45048558 #>>45049014 #
B-Con ◴[] No.45046811[source]
GOOG has made a systemic push to eliminate the role starting ~3 years ago. At that time my M was a staff level IC TLM with 4 reports who was forcibly converted to EM.

In those last 3 years I've only seen TLMs used to assist an overloaded EM.

The pattern I've seen is something like:

    Principal EM
    |- Staff EM (7 reports, project A)
    |- Staff EM (8 reports, project B)
    |- Staff IC (projects A, B, C)
    |- Senior IC (projects A, B)
    |- Senior IC (project C)
    |- Mid level IC (project C)
    |- Mid level IC (project C)
Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time.

So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc.

Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM.

Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.)

(Edit for formatting.)

replies(5): >>45047050 #>>45047345 #>>45048225 #>>45049022 #>>45049520 #
mytailorisrich ◴[] No.45049520[source]
Everytime I see such charts and explanations it helps me understand how Musk could fire 80% of Twitter with no visible effect on product.
replies(5): >>45049972 #>>45050203 #>>45050497 #>>45050880 #>>45053045 #
andriesm ◴[] No.45050203[source]
I've always been perplexed when I see 100s-1000+ people work on software product development and very little happen with the product for YEARS while there are tons of obvious (to me) improvements possible. Only tiny bug fixes released on a pretty slow release cycle. Then I also just think of the twitter/X example.

Occasionally one reads stories of how people get paid pretty hefty salaries to mostly just work very casually. Contrast with the usual software engineering types I know that work insanely hard solving difficult problems day-in and day-out.

When I was younger I remember a lot of project managers (almost exclusively ladies in my environment back then) that mostly just ran around interrupting the programmers and relaying feedback and status and a lot of chitchatting and busy work. Often there can be tons of support roles, wellness officers and who knows what that can probably be slashed. What shocks me is when a lot of these really low value-add positions are given high seniority with crazy paychecks and very little real skill required and fairly low responsibility or accountability for anything vaguely tangible. I suspect in tech companies generating huge cashflows that almost seem decoupled from headcount in comparison to non-tech businesses, this stuff just get covered up. A big machine that is very profitable due to massive competitive advantage/network effects, can hide a ton of HR waste.

replies(3): >>45050375 #>>45050695 #>>45051466 #
1. jajko ◴[] No.45050695[source]
> Contrast with the usual software engineering types I know that work insanely hard solving difficult problems day-in and day-out.

Well you just know some... not effective or smart folks then, unless they literally enjoy living such life. There is time for some hard work, but if that's one's default modus operandi long term, rest of their lives suck pretty badly, no realistic way to avoid that.

That's failure to manage one of most critical aspects of life. Especially bad fail if employed at some heartless mega corporation, or just usual often amoral FAANGs of these days (unless the goal is to earn enough money in few years and move to saner place in life, but few achieve that even if they plan for it, ie mortgages and kids happen).

Some of us live to work, and the rest work to get some good actual life.