← All Posts

What Nobody Tells You About Becoming a Tech Lead

leadershipcareerteam-management

I became a technical lead because I was the best coder on the team. That’s the wrong reason, and it took me about six months to figure that out.

The skills that got me promoted — deep .NET knowledge, fast debugging, writing clean architecture — those became maybe 30% of my job. The other 70% was stuff nobody prepared me for: mediating disagreements about database schema choices, explaining to a client why we needed two more weeks, figuring out why a talented developer was suddenly disengaged.

The First Mistake I Made

I kept coding. Not a little bit — I was still trying to be the top contributor on the team while also attending meetings, doing architecture reviews, and unblocking people. The result was predictable: I was doing everything poorly. PRs piled up waiting for my review. Design decisions got delayed because I was heads-down in code. My team started going around me for answers because I was always “busy.”

A senior developer on my team pulled me aside after a particularly rough sprint and said something like, “We don’t need another developer. We need someone who makes the rest of us faster.” That landed hard.

What Actually Changed

I set a hard limit: no more than 30% of my time writing code. At first it felt wrong — like I was being lazy or losing my edge. But the team’s velocity went up noticeably within a month. Not because I was doing anything magical, but because decisions weren’t bottlenecked on me anymore.

Here’s what I spend most of my time on now:

Design reviews before code is written. This saves more time than anything else. A 30-minute conversation about approach before someone writes 2,000 lines of code prevents the “we need to rewrite this” conversation two weeks later.

One-on-ones that aren’t status updates. I have weekly 30-minute conversations with each team member. We talk about what’s frustrating them, what they want to learn, what’s blocking them. It took a few weeks for people to trust that these weren’t performance evaluations, but once they did, the information I got was invaluable.

Writing things down. Architecture Decision Records (ADRs) for every significant technical choice. Not because I love documentation — I don’t — but because “why did we choose MongoDB for this service?” comes up six months later and nobody remembers the discussion. Now there’s a doc.

The Parts Nobody Talks About

You’ll be wrong a lot. As an IC, being wrong means your code has a bug. As a lead, being wrong means the whole team goes in the wrong direction. The stakes are higher, and you don’t have the luxury of certainty. I’ve made architectural calls that turned out to be wrong, and the right response is owning it, adjusting course, and not pretending you knew all along.

Politics is part of the job. I hate this but it’s true. You need to advocate for your team’s work, negotiate realistic timelines, and sometimes push back on stakeholder requests that don’t make technical sense. You can be diplomatic about it, but you can’t avoid it.

Letting go of control is hard. When a developer on my team makes a choice I wouldn’t have made — and it’s not objectively wrong, just different — I have to let it go. My job is to set boundaries and principles, not to dictate every implementation detail. This was (and still is) the hardest part for me.

Advice I’d Give Myself Three Years Ago

  1. Your identity isn’t “the best coder” anymore. Get comfortable with that.
  2. An hour unblocking a teammate is worth more than an hour of your own coding.
  3. Ask for feedback on your leadership, not just your code. It’ll be uncomfortable and it’ll be the most useful feedback you’ve ever gotten.
  4. Build relationships before you need them. When a hard decision comes, you’ll need trust.
  5. Read “The Manager’s Path” by Camille Fournier. It’s the single most useful resource for this transition.

The role isn’t for everyone, and that’s fine. Some of the best engineers I know have no interest in leadership and they’re right to stay on the IC track. But if you do make the switch, know that it’s a different job — not just “senior developer plus meetings.”