From IC to Tech Lead: The Identity Shift, Impostor Syndrome, and Lessons I Learned

Transitioning from Individual Contributor to Tech Lead is brutal. It’s not about being a senior engineer who can also coordinate things. It’s a fundamental change in who you are. I spent 12+ years writing code. Then, suddenly, I was responsible for the code other people wrote. And for their careers. And for unblocking them. It’s a completely different beast.

I’ve managed teams across multiple time zones. Led projects like zkawa and phronix from zero to production. And I’ve been wrong. A lot. This is what I learned.

The Coding Identity

For years, my worth was tied to my output. I could debug a gnarly race condition. I could architect a system that scaled. I could write clean, performant code. I enjoyed that. It’s tangible. You write code, it works (hopefully), you get a dopamine hit. Simple.

Then you become a Tech Lead. And your code contributions decrease. This is where the panic sets in. “Am I still a valuable engineer if I’m not actively coding?” I wrestled with this for months. I’d sneak in commits, refactor things nobody asked me to, just to feel useful.

It was a mistake.

I was slowing the team down. I wasn’t reviewing code properly because I was too busy writing my own. I wasn’t focusing on architecture. I was clinging to an identity that no longer served me.

The realization hit me hard. My job wasn’t to be the best coder on the team. It was to make the team the best. That meant different things at different times. Sometimes it meant writing a design doc. Sometimes it meant mediating a disagreement. Sometimes it meant just listening.

This is the shift. You trade individual contribution for collective success. It’s hard. But it’s necessary.

Impostor Syndrome: It’s Not Just You

The decrease in coding also fuels impostor syndrome. You start questioning everything. “Can I really lead this team?” “Do I understand the architecture well enough?” “What if I make the wrong decision and the whole project fails?”

I remember taking on zkawa. A brand new recommendation engine. High visibility. High risk. I knew the algorithms. I’d built similar systems before. But the scale was different. The team was different. The business requirements were…fluid.

Every architecture decision felt like a gamble. Every code review felt like I was second-guessing everyone. I’d spend hours researching alternatives, only to end up picking something I already knew.

I didn’t tell anyone. I figured a “good” Tech Lead just knows these things.

Wrong.

I talked to a more senior leader – someone I trusted. He told me something simple: “Everyone feels this way. The best leaders are the ones who admit what they don’t know and ask for help.”

It was a revelation.

I started being honest with the team. “I’m not sure about this approach. Let’s brainstorm some alternatives.” “Can someone walk me through this part of the code base?”

Two things happened. First, the team stepped up. They had great ideas. They were experts in their areas. Second, my stress levels dropped dramatically.

Impostor syndrome doesn’t disappear. It just changes form. Instead of “I can’t do this,” it becomes “Let’s figure this out together.”

Lessons I Learned (The Hard Way)

Here’s what I’ve found crucial. These aren’t “leadership best practices.” They’re things that actually worked for me.

• Communication is paramount. I used to think good code was self-documenting. It’s not. I spent way too long debugging issues that could have been avoided with a simple design doc. Now, I push for clear, concise documentation. Even if it feels like overhead. Especially if it feels like overhead.
• Mentorship is a force multiplier. I started blocking time every week for 1:1s with each engineer. Not just to talk about tasks. But to understand their goals. Their challenges. Their frustrations. This is where you build trust. And where you identify potential problems before they become crises.
• Technical architecture reviews are essential. I don’t mean rubber-stamping everything. I mean asking tough questions. Challenging assumptions. Playing devil’s advocate. It’s uncomfortable. But it’s worth it. I once approved a database schema that was fundamentally flawed. It cost us two sprints to fix. I learned my lesson.
• Saying “No” is a superpower. Engineers are problem solvers. They’ll take on anything. Your job is to prioritize. To protect the team from distractions. To say “No” to things that don’t align with the goals. This is hard. People don’t like hearing “No.” But they respect you for it.
• Don’t get stuck in the weeds. This is the hardest one for me. I still get tempted to dive into the code and fix things myself. But that’s not my job. My job is to empower the team to fix things themselves.

The Counterpoint: Technical Prowess Still Matters

Some people argue that leadership is just soft skills. That technical expertise is more important. I disagree.

You need to understand the technology. You need to be able to make informed decisions. You need to be able to talk to the engineers on a technical level.

But technical expertise alone isn’t enough. You need to be able to communicate. You need to be able to mentor. You need to be able to inspire.

It’s a Venn diagram. The sweet spot is the intersection of technical expertise, leadership skills, and the ability to adapt to the identity shift.

Practical Takeaway

If you’re transitioning to Tech Lead:

• Recognize the shift. Your role is changing. Embrace it.
• Address the impostor syndrome. Talk to people. Ask for help. Be honest about your weaknesses.
• Apply the lessons. Focus on communication. Mentorship. Architecture. Prioritization.

It’s not easy. But it’s rewarding. You get to build amazing things. And you get to help other people grow. That’s a pretty good deal.

And finally, remember this: It’s okay to break things. I broke a production database once. It sucked. But I learned more from that failure than from any success.