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.
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)
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.)
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.
It's reasonable, when a company is looking into buying a new SaaS product, that the legal team review the contract.
It's reasonable for legal to ask for variations in the contract, if there's something in it they can't approve.
It's reasonable for the product to be reviewed for compliance with our privacy laws, before we order employees to start using it.
It's reasonable that the information security team get to be consulted before a new product is adopted, we don't want insecure products sneaking in.
It's reasonable that we want single-sign-on from our vendors, that's good for security. And we want SOC2 compliance if possible, as we're trying to be SOC2 compliant ourselves.
It's reasonable that a vendor have a record in our finance database, so we can pay them and know who we've paid what.
It's reasonable that, before approving a vendor, we get a statement from them that they do not use slave labour in their supply chain.
It's reasonable that every expense be attributed to a project or department within the business.
It's reasonable that the project or department's budget have an owner, who has to approve major expenditures.
It's reasonable that the work above is split across quite a few teams, and that each team have a queue of work where non-emergency requests can take a week or two.
But take those reasonable policies together, and it takes 3-6 months to adopt a new SaaS product - so it's a heck of a lot easier to stick with an under-performing, over-priced vendor than it is to get a new vendor approved.