I wouldn't actually say that, but I would say that the TLM role works at a very specific stage in a company's lifecycle, and many companies that use it (including Google itself from around 2010 onwards) have long since past that point.

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.

▲

greesil 5 days ago | parent [-]

If you don't mind me asking, why did your team get bigger? Did your scope increase?

▲

nostrademons 5 days ago | parent [-]

I assume you're referring to my other comment, since I didn't mention my team size in this one.

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.

	▲	greesil 5 days ago \| parent [-]
		I passed on a similar opportunity, kept the team small. This was back in the pandemic when headcount flowed freely. What you describe sounds about right. My experience is that having a capable team goes a long way creating those expansion opportunities.