From IC to Team Lead: What Changes When You Stop Writing All the Code

Reflections on growing from an individual contributor to team leadership, and the mindset shifts that made it work.

The Shift Nobody Prepares You For

When I joined the Invaluable engagement as a full-stack engineer, my job was straightforward: pick up tickets, write code, ship features. Three years later, I was leading the team. The transition sounds clean on paper, but the reality was anything but.

The hardest part wasn't learning new skills. It was unlearning habits that had made me effective as an individual contributor.

Writing Code vs. Enabling Code

As an IC, my value was measured in output: features shipped, bugs squashed, pull requests merged. When I moved into a tech lead role, I kept trying to be the fastest coder on the team while also doing lead things. That doesn't scale.

The turning point came when I realized that unblocking three engineers for a day was worth more than any single feature I could write myself. My job shifted from producing work to enabling work.

This meant:

  • Spending time breaking down ambiguous requirements into actionable tasks before anyone opened an editor
  • Reviewing architecture decisions early instead of fixing them in code review
  • Having the hard conversations about scope and timelines with stakeholders so the team could focus

The Estimation Trap

One thing I wish someone had told me earlier: estimation is a leadership skill, not a planning exercise. When you're an IC, you estimate your own work. When you're a lead, you're estimating for a team, and you're accountable for the plan.

I learned to decompose work into smaller units not because it made the estimates more accurate (it did), but because it made the unknowns visible. When a task is "build the search page," you don't know what you don't know. When it's broken into API integration, state management, UI rendering, and edge case handling, the risks surface early.

Communication Becomes the Job

The higher you go, the more your job is communication. At Invaluable, I spent a lot of time in conversations with client stakeholders, product managers, and cross-functional teams. Not because I wanted meetings. Alignment is what prevents rework.

The best engineering plans fail when the people funding them have different expectations. I learned to treat stakeholder communication as an engineering deliverable, not overhead.

What I'd Tell My Past Self

If I could go back to when I was a senior IC eyeing leadership, I'd say three things:

  1. Your technical depth is your credibility, not your daily output. You don't need to write the most code. You need to make the right technical calls and explain them clearly.
  2. Get comfortable with incomplete information. Leadership means making decisions before you have all the answers, then adjusting.
  3. Invest in your team's growth. The engineers you mentor today become the leads who make your job possible tomorrow.

It's Not a Promotion, It's a Role Change

The biggest misconception about moving from IC to lead is that it's a promotion. It's not. It's a lateral shift into a different kind of work that happens to come with more responsibility. Some of the best engineers I know have no interest in leading teams, and that's a perfectly valid path.

But if you do make the switch, know that the skills that got you here (deep focus, fast execution, technical excellence) won't go away. They'll just become the foundation for something different: enabling a team to deliver more than any single person could.