The language or stack is irrelevant.
A good lead knows the right questions to ask, understands they don't have all the answers and plays to their own and the teams strength.
Honestly the last thing I care about, especially here, is if they know the stack.
What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?
What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?
I'm not saying this is right in all circumstances. I wouldn't do this with, for example, realtime embedded.
For what I operate in, fairly bland web applications and stacks.
It works fine, exceptions excepted.
I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with.
Consider if someone has written lots of PHP and jQuery
Now tell them to write a NodeJS server, React Frontend using NextJS.
It's not just "Oh I need to pick up ExpressJS" anymore. It's a whole beast.
Yeah the fundamentals stay the same. REST is still REST, SQL is still SQL, but actually writing lines of code is still a key activity of the job which people familiar with the technology will be better at.
Personally I run into this any time I try and write C#. There's a massive undercurrent of stuff that I feel I don't understand about C# and I bounce off that ecosystem every time I try
And you’re going to hit a brick wall at 100 mph thinking SQL is still SQL once you try to treat a columnar database like Redshift or Snowflake like you would a traditional database.
That would be an expensive lesson to learn on the job. That’s just one example of trying to pattern match based on what you know when you hit a new to you technology.
It’s like the old school operations people who study one course of ACloudGuru, get a certificate, call themselves “consultants” and duplicate an on prem infrastructure and internal process and their poor clients wonder why they are spending twice as much and not moving faster.
I will say that even moving from Postgres to MySql has a speed bump or two, so I completely agree.
Tech knowledge just isn't as interchangeable as hiring managers sometimes seem to think.
The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.
For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.
Sorry that contradicts the black-and-white world view you're holding.
I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.
You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.
Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.
The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts.
Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”.
[1] My four experiences with dealing with mobile implementations
1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements
2. Railroad car repairmen in a rail yard
3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints.
4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.