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.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
IMHO, the conditions where a TLM role is appropriate are:
1.) You need to be in the company growth phase where you are still trying to capture share of a competitive market, i.e. it matters that you can execute quickly and correctly.
2.) There needs to be significant ambiguity in the technical projects you take on. TLMs should be determining software architecture, not fitting their teams' work into an existing architecture.
3.) No more than 3 levels of management between engineer and person who has ultimate responsibility for business goals, and no more than 6 reports per manager. The mathematically inclined will note that this caps org size at 6^3 = 216, which perhaps not coincidentally, is not much larger than Dunbar's number.
4.) TLMs need to be carefully chosen for teamwork. They need to think of themselves as servant-leaders that clarify engineering goals for the teammates who work with themselves, not as ladder-climbers who tell others what to do.
Without these, there is a.) not enough scope for the feedback advantages of the TLM structure to matter and b.) too much interference from managers outside the team for the TLM to keep up with their managerial duties. But if these conditions are met, IMHO teams of TLMs are the only way to effectively develop software quickly.
Perhaps not coincidentally, these conditions usually coincide with the growth phase of most startups where much of the value is actually created.
I mean there is the obvious part of the answer in that managers are the ones that are given the power to define that growth ladder, but I'm not sure this fully explains things. If people are transferring from technical positions to managerial positions then should they also not be aware that there is a lot of advantages to allowing people to keep climbing the ladder through technical positions? That institutional knowledge can be incredibly valuable. It's often what leads to those people being such wizards. They've been with the code for so long that they know where things will fail and what are the best parts to jump in to make modifications (and where not to!). But every time you transfer one of these people to a non-technical role that knowledge "rots". More in that code just keeps evolving while their knowledge of it remains mostly frozen.
Which what you say sounds like maybe the worse end of that. Taking that person with institutionalized knowledge and hyper focusing their capabilities on one aspect. That doesn't sound like an efficient use of that person. Though the knowledge transfer part sounds important for a company's long term success, but also not helpful if it's narrowly applied.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
do they report to the same level? every place I've seen a "technical track" and "management track" it seems the higher level technical people report to someone on the same or even lower level in management. I.E. a manager can have technical reports that are equal level or higher. that obviously doesn't happen in the management track.
not that these are first level managers but if a principal engineer not reporting to a VP, the it doesnt seem like the tracks are equal.
I'd love to say that the answer is "because I'm a good manager", but I think that the real answer is "because there was money=headcount available, the layers of management above me successfully presented our value and inflated our needs enough to convince a VP to give it to us, and my own manager physically did not have enough hours in the day to have 1:1s with all the new incoming headcount without introducing some layers of management under us". If it weren't me, it would've been some other manager. For that matter, I wasn't a manager when I joined the team, but I was interested in managing and of sufficient level that I could pass department policies, so I ended up more than doubling my team size within 6 months of becoming a manager. The team was pretty busy for the first year or two after that - we'd gotten all that headcount by arguing that we were critical to some big strategic initiative, after all - but there were long periods after where we were oversized by a factor of about 2, so I just let everyone work 20 hour weeks and phone it in until the next big project came.
The more time I spend in the corporate world, the more I become convinced that success is a matter of meeting the minimum qualifications, bullshitting, saying yes to opportunities created by people who are themselves bullshitting, and doing the minimum amount of work needed to avoid being called on your bullshit. Businesses don't hire because they actually have work to do. They hire because they have money and money=headcount and headcount is the only way for a manager to get promoted or pad their resume.
If I'm a jr engineer reporting to a director does that give me more authority then a staff engineer reporting to a manger?
Management is a different job, it would be leveled differently.
Maybe a high level IC needs to work closely with a team for a bit so they just report to the manager of the team.
You can, but it's a dead end ultimately. I've been a distinguished engineer which is about as far as one can go (some companies have Fellows, but it's just a few people so basically impossible). If you have any desire to grow beyond that, management track is the only possibility.
Also, moving to management from a DE level is harder because you're basically around a Sr.Director level (give or take, depending on company) but have no management experience.
If you care about career growth (and I'm not saying you have to, geeking out on the IC ladder is way more fun), I suggest as soon as you are at the equivalent level of a manager on the numeric ladder, switch to management.
If you are in a bad position then change, but if you like the company and role, don’t take it for granted and think carefully.
This advice is consistent with the broad statistic if more than half of the sample is currently in “bad position”.
Does anyone stay in the same position/team for more than two or three years even at the same company?