Why Range Beats Depth for a Tech Lead

There's a comfortable myth in engineering that leadership is just senior individual contribution with meetings attached — that the person who knows the codebase deepest should lead it. Sometimes that's right. Often it produces a brilliant specialist who can't see past their own stack.

Judgment travels; syntax doesn't

I've led delivery in .NET and Azure, React and Node, Flutter and Firebase, AWS and Terraform. I am not the best engineer in every one of those. I don't need to be. What carries across all of them is judgment: how to size a piece of work, where the load-bearing risk hides, when an estimate is fiction, what "done" actually means. That judgment is built by shipping in many places, not by going deepest in one.

The specialist trap

A team led by a single-stack specialist tends to solve every problem in that stack's shape. The deep .NET lead reaches for a .NET answer; the React purist rebuilds the world in React. Range is the antidote — you pick the tool because it fits the problem, not because it fits your CV.

What it means in practice

When I join a team, I don't need a month to be useful, because I've seen the failure modes before in a different language. The retry storm, the migration that underestimates data debt, the "we'll add tests later," the architecture that can't survive its second customer — they rhyme across stacks. Recognising the rhyme early is most of the job.

Depth still matters — just not only depth

This isn't an argument against expertise. It's an argument against confusing expertise with leadership. The strongest setup is a leader with range steering specialists with depth. I've been both. These days I'm far more useful as the former.