Tech lead is not a promotion but a lateral role change with a new scoreboard. Move your leverage from code to decisions and dodge three career killing traps.
The day I got "tech lead" on my title, I celebrated. Three months later I was quietly the worst-performing person on the team, and my dashboards still said I was the best. Both things were true at once, and understanding why took me longer than I'd like to admit.
Nobody warns you about this when they hand you the title. Tech lead is not a level above senior engineer. It is a different job that happens to require you to have been a good engineer first. Treat it as a promotion — a reward for shipping — and you've picked the most reliable way to stall out in the role without ever understanding why. I've done it. I've watched people I hired do it. This is the post I wish someone had handed me on day one, written from six years of getting the individual-contributor-to-tech-lead transition wrong in various interesting ways.
The lie is compact and almost true, which is what makes it dangerous. It goes: the best engineer on the team should lead it. Everyone nods. It sounds like meritocracy.
But it quietly smuggles in an assumption — that "leading the team" is just "being the best engineer, with authority." That the job is the same job, scaled up. It isn't.
Being a great individual contributor and being a great tech lead correlate, but they are not the same skill. One is about your throughput. The other is about the team's throughput, most of which you now produce by not touching the keyboard. The best engineer becoming lead is fine. The best engineer staying an engineer while wearing a lead title is the failure mode, and it's the default one.
I think of it like promoting your best striker to manager. He was brilliant at scoring. That tells you almost nothing about whether he can pick a squad, manage egos, and design a system where eleven other people score. Sometimes it works. Often you've just lost your best striker and gained a mediocre manager.
Let me be concrete, because "leadership" is a word people hide behind. Here's the honest before-and-after from my own experience going from senior Flutter engineer to leading a team.
What the job becomes:
What the job stops being:
That last bullet is the killer. For your entire career up to this point, "how much did you ship" was the scoreboard. On a recent project I caught myself pulling the gnarliest state-management refactor onto my own plate because it was the fun part and I was fastest at it. I shipped it in two days. It would have taken a mid-level engineer a week — and that week was the entire point. I'd optimized my metric and starved his growth. I felt productive and was, in the role, being lazy.
Here's a heuristic I now run any tempting task through before I pick it up:
Should I, the tech lead, personally do this task? Is it genuinely blocking the whole team right now? yes -> unblock it, then hand ownership back no -> keep going Would someone else grow meaningfully by doing it? yes -> delegate, coach the edges, resist rewriting their work no -> keep going Is it low-stakes plumbing nobody is fighting over? yes -> fine, take it; keeps you sharp without robbing anyone no -> it's probably a decision or direction call -> THAT is your job
Most "fun" tickets fail the first two questions and pass the third only in my ego's imagination.
Here is the part that stings. The day you become a tech lead, you go from being excellent at your job to being a beginner at your new one — while everyone, including you, still expects excellence.
You know how to review a pull request. Do you know how to give hard feedback to someone older than you without them shutting down? You know how to design a data model. Do you know how to say "no" to a founder who outranks you and keep the relationship intact? You know how to debug a race condition. Do you know how to sit in a meeting, feel your fingers itching to fix the code yourself, and not, because the point is for someone else to learn?
I was bad at all of these. Genuinely bad. And the cruel design of the role is that your old competence actively hides your new incompleteness. You feel capable — you're still crushing the code — so you don't notice you're failing at the actual job for months. The dashboard is green while the engine is on fire.
The engineers who survive this do one unglamorous thing: they name it. They accept they've walked off a competence cliff and are, once again, a junior. That humility is not a nice-to-have; it's the whole job at the start. The ones who insist they were promoted because they're already great — they're the ones who never get better, because in their own story there's nothing to get better at.
Leverage is the word I'd tattoo on this if I were the tattoo type. As an individual contributor, your leverage is your code. You get more done by getting faster, learning more, typing better abstractions. Linear-ish returns on your own hours.
As a lead, your leverage moved. It now lives in three places, none of which is your keyboard:
Once I internalized this, my day looked "lazier" and the team went faster. That gap is the signal you're doing it right: your personal output graph goes down and the team's goes up. If both are going up, you're probably still hero-coding and just haven't hit the wall yet.
There's a subtle trap inside the "decisions" bucket, though: a decision only counts as leverage if it's written down and shared. A brilliant architectural call that lives only in your head isn't direction — it's a bottleneck waiting to happen, because every ambiguous case now has to route back through you. Cheap, durable artifacts multiply a single decision across the whole team:
Each of these turns a decision you made once into one the team can apply a hundred times without you in the room. That's the multiplier the role is actually paying you for.
I've fallen into all three. Watch for them in yourself.
You keep taking the hard, load-bearing work because you're fastest and it feels good. Short term, velocity looks great. Long term, you've built a team of people who never touched anything hard, a bus factor of one, and a lead who's too buried in code to lead. The hero coder is the most seductive trap because it's rewarded right up until the moment it isn't — usually the week you go on holiday and everything stops.
The fix: cap your own coding. I try to keep mine to non-critical-path work — plumbing, spikes, the unglamorous stuff — and consciously hand the juicy, growth-shaped problems to the person who'll grow from them. My discomfort watching someone go slower than I would is the price of a team that scales past me. A concrete rule of thumb: if you're consistently on the critical path of your own team's delivery, you've quietly become the hero coder again, whatever your calendar says.
The opposite failure. You go full manager — meetings, unblocking, planning, mentoring — and produce nothing you can point at. Six months later, review season comes and you can't articulate what you did. Worse, you've lost the technical credibility that made the team trust you, because you haven't touched the codebase in so long you can't reason about it anymore.
Glue work is real and vital, but it's invisible by default, and invisible work gets you managed out or ignored. The fix: keep one foot in the code — enough to stay technically sharp and legible — and get deliberate about surfacing the glue. "I unblocked three people and killed a two-week detour this sprint" is a real accomplishment. Say it out loud. Glue that nobody can see is, organizationally, glue that didn't happen.
Every decision routes through you. Every PR needs your eyes. Nothing merges without your blessing. You feel important — you're clearly essential — and you've made yourself the single slowest point in the system. The team's throughput is now capped at your attention, which does not scale, and juniors never learn to decide anything because you always decide for them.
I learned this one on a holiday. I took four days off around Eid, phone mostly in a drawer, and came back to a branch that had gone stale for four days because I was the only approver on a critical review path we'd never bothered to change. Two engineers had been blocked the whole time. They hadn't been lazy — they'd literally been unable to ship, because I'd quietly designed myself into every merge. That was the moment the "single point of failure" stopped being an abstract diagram and became my name in a CODEOWNERS file.
The fix: push decisions down, not up. Set the guardrails — the architecture, the standards, the "here's how we think about this" — then let people make calls inside them and be wrong sometimes. A team that can move without you is the actual deliverable. If everything stops when you're offline, you didn't build a team, you built a dependency on yourself. The test is simple and unforgiving: what happens to delivery the week you're unreachable?
Because the failure modes hide behind a feeling of productivity, I can't trust the feeling. I run a periodic honest audit instead — roughly monthly, and any time I feel unusually "busy and important." I ask myself a short, uncomfortable list:
None of these have flattering answers most months. That's what makes them useful. A leader who always passes their own audit isn't auditing honestly. If you want a lightweight version, pick just the first question and answer it truthfully once a month — the two-week bus-factor test alone will catch most of the drift.
Here's the part the trophy framing makes almost impossible to say out loud: sometimes the right move is to go back to being an individual contributor. And because we've all agreed the title is a promotion, stepping back reads as a demotion, a failure, a fall. So people cling to a role they hate and are bad at, quietly making their team worse, because the alternative feels like defeat.
It isn't. If lead is a lateral role change — a different job, not a higher rung — then going back to IC is also just a lateral change. You're not falling down a ladder. You're switching which job you do.
Some of the strongest engineers I know are strongest precisely as engineers. Put them in the lead seat and you lose a phenomenal builder and gain a stressed, mediocre coordinator who spends meetings wishing they were coding. That's a bad trade for everyone, including them.
Reasons stepping back is the right call, not a failure:
This is exactly why serious engineering ladders have long since split into parallel IC and management tracks — a principal or staff engineer can out-earn and out-influence a line manager. If your org still has only one track and calls lead "up," that's a structural bug in the ladder, not evidence that stepping back is failure.
The healthiest engineering cultures let people move between IC and lead like changing lanes, not climbing or falling. That only works if we stop calling lead a promotion. As long as it's a trophy, giving it back looks like disgrace, and people will suffer in a role they should have left. Make it a job description and the exit ramp becomes what it actually is — a sensible choice, not a confession.