The Hidden Cost of Tech Leads: When Adding Leadership Slows You Down

The Trap Everyone Falls Into

Your team is growing. You have four or five strong engineers. One of them is exceptional—the person everyone learns from, the person who architects, the person who unblocks people. You want to recognize that person. You want to retain them. You want to leverage their talent more.

So you say: "I'm going to make them tech lead."

On paper, this makes sense. Tech leads are a thing. Real companies have them. They're not quite managers, but they're more than ICs. They mentor. They shape technical decisions. They help with hiring.

What actually happens, almost every time: they become a bottleneck.

They're no longer writing code 80% and thinking about architecture 20%. They're writing code 40% and attending meetings 60%. They're not even managing—you didn't give them budget authority or hiring authority. But they're definitely not shipping anymore.

And because they're the best engineer, you just lost 40% of your best engineer's productivity for a job that doesn't actually need a person, not at your size.

I've done this. I've made this mistake at companies where I ran engineering. And I've watched it happen at hundreds of companies I've consulted with. The pattern is identical.

The engineer who was shipping features, unblocking people, and thinking systemically becomes the person everyone waits for in reviews. They're in three meetings a day. They're still responsible for shipping something, but they can't because they're in meetings. Then they're frustrated. Then they leave.

You replaced one high-performer with zero high-performers and a meeting.

The Real Cost (And Why It's Hidden)

Here's what makes this so insidious: tech lead velocity loss doesn't show up as a crash. It shows up as a slowdown that looks like other problems.

Before: Your tech lead ships a feature every two weeks. After: Your tech lead ships a feature every five weeks.

You assume they're less motivated. You assume the work is harder. You don't realize they're in 10 meetings a week they weren't in before.

Meanwhile, their influence (which is the thing you were trying to leverage) is actually worse. Before, they influenced through code and presence. After, they influence through meetings. Meetings are slower.

One founder told me: "We promoted our best engineer to tech lead. Now we're shipping slower overall. Three engineers used to follow her lead; now they're waiting for her in code review because she's the single point of review." He hadn't realized he'd accidentally created a bottleneck.

The cost is real:

Velocity loss on that person: 40-50% reduction in feature shipping
Coordination cost: The whole team is waiting on her for reviews, decisions, unblocking
Opportunity cost: You now need another engineer to do the work the tech lead isn't doing anymore
Risk cost: If that person leaves, you've lost your architect and your best IC

And the benefit? Mentorship? She was already mentoring. Architectural guidance? She was already doing that. Process? Most tech leads don't actually own process—they're just in meetings about it.

When Tech Leads Actually Make Sense

They do make sense. Just not early.

Tech leads make sense when:

You have 15+ engineers, multiple teams, and genuine coordination problems. At that size, you actually need someone thinking about cross-team technical consistency. You need someone who can say "Team A and Team B should standardize here" without being the person who codes it.

You have a complex technical domain that junior engineers can't navigate alone. You have a distributed system, or a machine learning pipeline, or something that's genuinely hard. The tech lead owns that domain and brings people up to speed on it. They're valuable because their knowledge is scarce.

You have a clear job description that isn't "be a manager." The role has scope. It has authority. It has a real function. Not "mentor people and think about architecture." That's fluffy. But "own the API specification and migration," that's concrete.

You have a senior engineer who wants the role and is clear about what they're trading. This is important. If you say "I want to make you tech lead" and they say "I thought you wanted me to ship more features," you're going to have a conflict.

Real Example: Right vs. Wrong Tech Lead

I worked with a company that had 20 engineers and promoted two tech leads—one for the product side, one for infrastructure.

The infrastructure tech lead was perfect. They owned a complex Kubernetes migration. Three different product teams needed to understand it. The tech lead's job was to own the timeline, teach each team what they needed to know, and make decisions about deprecation. It was meaty. Real scope. Real value.

That tech lead shipped less code, but the business shipped faster because the infrastructure work was coordinated and clear.

The product tech lead was a mistake. The company didn't actually have cross-team coordination problems. Each product team was independent. Making someone a "tech lead" just meant they went to more meetings and shipped fewer features. After six months, they asked to go back to IC work.

The difference? One had a real job. One didn't.

The Counterpoint: Sometimes You Do It Anyway

Some people want to move toward leadership. They're not interested in being an IC forever. And if you force them to stay as an IC, they'll leave.

In those cases, you might promote them to tech lead even if it's not organizationally optimal, just to keep them. That's fine—it's a retention move, not a scaling move. Own the tradeoff though. You're trading efficiency for retention. That's sometimes the right call.

But don't pretend the trade-off doesn't exist. You're getting less features shipped so this person doesn't leave.

Also, if you can't afford to lose that engineer, you're underdiversified. You have a bus number of one. That's a bigger problem than the tech lead role.

Where I Come In

If you're thinking about tech leads, I'll help you figure out if it's actually solving a real problem or if it's going to create bottlenecks. We'll map what the role would actually do, who's a good fit, and whether your size and structure actually justifies it.

And if the answer is "not yet," I'll help you offer something else—maybe a senior title, maybe more autonomy on their area, maybe just a conversation about where they want their career to go.

Let's think through this together.

Your Action Checklist

Before promoting anyone to tech lead, write down the job description. What will they actually do? Is it real work or is it "influence through meetings"?
Count how many meetings that person would be in. If it's more than 8 hours a week, you're probably reducing their IC output more than you're gaining.
Ask the engineer: Do you want to do this? Or do you want to stay shipping code? Their answer matters.
If you do create a tech lead role, measure: Did our velocity improve or decline? Did this person's output change? Are we shipping faster overall?
At 6 months, re-evaluate. Is this working? If not, it's okay to say "this wasn't the right move" and offer them an IC role back.
If you need someone to think about architecture across teams, that might be an architect role, not a tech lead role. Architect is less about management, more about thinking.

The Real CTA

Your best engineer is your best engineer because they ship. Adding process and meetings around them doesn't multiply their impact—it reduces it.