The tech lead trap
The most common failure mode I see in new tech leads: they keep doing what made them successful as senior engineers. They take the hardest tickets. They review every PR. They make every architectural decision. And then they wonder why the team isn’t growing.
The job changed. You didn’t.
You got promoted because you were the strongest IC on the team. Now the job is fundamentally different, but nobody told you that explicitly. The title says “lead” but your instincts say “write code.” So you do both, badly.
The trap is that it works — for a while. You’re fast, you know the codebase, and it’s easier to just do the thing than to teach someone else to do it. But you’re building a single point of failure shaped exactly like yourself.
What the job actually is
Tech leadership is three things:
1. Multiply, don’t add.
Your job isn’t to produce more code. It’s to make the team produce better code. That means pairing with the mid-level engineer on the hard problem instead of solving it yourself. It means writing the design doc that unblocks three people instead of the PR that unblocks one.
The math is simple. If you’re 2x more productive than the average team member, and you have five people on your team, making each of them 20% better produces more output than anything you could do alone.
2. Own the ambiguity.
Senior engineers get well-defined problems. Tech leads get vague ones. “We need to make the system faster” or “this architecture won’t scale for the next product.” Your job is to turn ambiguity into clarity — to ask the right questions, scope the work, and define what done looks like.
This is uncomfortable if you’re used to the dopamine of closing tickets. Ambiguity doesn’t resolve in a single PR. But it’s the highest-leverage work on the team.
3. Create the technical culture.
How does the team make decisions? What gets documented and what doesn’t? When do you reach for a new tool versus extending an existing one? These are all cultural questions that get answered whether you’re intentional about them or not.
The best tech leads I’ve worked with are explicit about this. They write down their principles. They explain the why behind technical decisions, not just the what. They create space for disagreement before a decision and alignment after.
The letting-go checklist
If you’re a new tech lead, here’s what to start delegating:
- The ticket you’re most excited about. Give it to someone who will grow from it.
- The PR review queue. Share it. Your review isn’t the only one that matters.
- The meeting where you explain the architecture. Let someone else present. They’ll learn more from preparing than from listening.
- The production incident. Be there, but let someone else drive. Debrief after.
When to stay hands-on
I’m not saying tech leads should stop coding. You should absolutely stay in the codebase — but strategically. Write the proof-of-concept that de-risks a big decision. Fix the bug that nobody else can reproduce. Build the tooling that makes the whole team faster.
The difference is intent. You’re not coding because it’s your job. You’re coding because it’s the highest-leverage thing you can do right now. And honestly, most days, it isn’t.
The test
Here’s how you know if you’re doing it right: can you take a week off without everything stalling? If the answer is no, you’re not leading. You’re bottlenecking.