What I Wish I Knew Before Becoming a Tech Lead

Becoming a tech lead feels like a promotion. It is — and it also means your entire job description has quietly changed in ways nobody tells you about.

Nobody Told Me What I Was Signing Up For

When I was offered my first tech lead role, I thought I understood what it meant. I'd be a senior developer with more say in technical decisions. I'd review more code, design more systems, and have more influence over the direction of the work.

That was partially right. The part I didn't see coming: my output was no longer my code. My output was the team's effectiveness. That sounds like a minor reframe. It isn't. It changes almost everything about how you spend your time and how you measure whether you're doing a good job.

Your Productivity Metrics Are Wrong Now

As an individual contributor, you can feel yourself being productive. You write code, it ships, you can see what you built. The feedback loop is reasonably short.

As a tech lead, the feedback loop on your actual work is much longer and much harder to observe. The architecture decision you made three months ago is either paying dividends or quietly creating problems. The developer you invested time coaching is either growing or not. The standards you established are either being absorbed by the team or slowly eroding.

I kept trying to measure myself the way I used to — by what I shipped. For months, I felt consistently behind, like I wasn't doing enough, because my code output had dropped significantly. I was doing the job wrong in exactly the opposite direction from what I expected: I was still optimizing for individual contribution instead of team contribution.

The right question is not "what did I build this week?" but "what did the team do better this week than last week?"

You Are Not the Smartest Person in the Room Anymore (And That's Fine)

The instinct when you become a tech lead is to be the answer source. Someone asks a technical question, you answer it. A decision needs to be made, you make it.

The problem is that this scales badly. If every decision runs through you, you become the bottleneck. If you answer every question, the team never develops their own judgment. Your intelligence is the ceiling on the team's capability.

The counterintuitive move: be the question asker, not the answer giver. "What do you think?" before "here's what I think." "What have you tried?" before "try this." "What are the options you're seeing?" before "here are the options."

This feels slower. It is slower, in the moment. Over time, the team develops the judgment to handle things without you, and the total throughput is higher than if you'd kept everything centralized.

Technical Decisions Have Political Dimensions

As a developer, you could largely separate technical questions from organizational ones. The right solution to a problem was (mostly) the right solution, regardless of who you were talking to.

As a tech lead, this separation breaks down. The technically superior solution might not be feasible given the team's current skill set. The correct architecture might require buy-in from a stakeholder who's skeptical of complexity. The migration that needs to happen might be blocked by a product timeline that isn't moving.

I had to learn to hold technical correctness and organizational feasibility simultaneously — and to accept that sometimes the second one wins. The goal is the best decision that can actually be implemented and maintained by the people and constraints you're working with. Not the best decision in the abstract.

Good tech leads work with reality. Great tech leads also slowly change the reality they're working with.

Feedback Goes Both Ways

I was used to receiving feedback about my work. As a tech lead, I now had to give feedback about others' work regularly, and also solicit feedback about my own effectiveness as a lead — which is a different and much more uncomfortable thing.

The instinct is to wait for feedback to come to you. It rarely comes in the forms you need it. The people on your team are unlikely to proactively tell you that your decision-making process is opaque, or that your code reviews take too long, or that they feel like their input isn't valued.

You have to ask. Directly and specifically: "Is there anything about how I'm running this that's making your job harder?" "Did the way I communicated this change land clearly?" "What would make our technical reviews more useful to you?"

The answers are sometimes uncomfortable. They're always more useful than not asking.

Protecting the Team Is Part of the Job

One thing I genuinely didn't anticipate: a significant portion of tech lead work is about shielding the team from noise. Scope creep from product, unclear requirements, organizational churn, an urgent-but-not-actually-urgent request from a stakeholder — left unmanaged, these become the team's problem. Managed well, they stay outside the team's attention.

This requires saying no more often than feels comfortable. It requires having conversations with people above you or outside your team about whether something is really necessary right now. It requires being comfortable with the team not having full visibility into every organizational messiness — because full visibility isn't always useful, and sometimes it's just distracting.

You become a buffer. It's not glamorous. It matters enormously.

The best thing I did as a new tech lead was stop trying to be the best developer on the team and start trying to make the team not need me.