Why I Stopped Coding Everything Myself as a Tech Lead
For the first year I was a tech lead, I was still, functionally, the best individual contributor on the team. I just also had more meetings.
I told myself this was fine. Better than fine - efficient, even. I could review a pull request in ten minutes that would’ve taken someone else an hour to fully understand. I could fix the flaky integration test myself in the time it would’ve taken to explain what was flaky about it. When a report on my team hit a wall on a gnarly caching bug at 4pm, I’d take one look, feel the specific dopamine hit of recognizing the shape of the problem, and just… fix it. Then I’d go back to my actual job, feeling productive, having burned forty-five minutes I didn’t have and taught my report nothing except that if they waited long enough, I’d solve it for them.
I want to be honest about why this trap is so easy to fall into, because “delegate more” is advice everyone’s heard and roughly nobody follows. It’s not that new tech leads don’t understand delegation. It’s that, in the short term, doing it yourself is almost always faster, almost always more comfortable, and almost always the thing that gets you positive feedback.
The math that keeps you coding
Here’s the actual math, not the inspirational-poster version of it, because I think skipping past it is why most advice on this topic doesn’t land:
You get promoted to tech lead because you were good at writing code and making technical calls. That’s the skill that got rewarded. Nobody hands you a new skill on day one. You still have the old one, and it still works. So when a decision needs to get made or a bug needs to get fixed, using the skill you already have is the path of least resistance. It’s not laziness. It’s the rational move in the moment, every single time you’re standing at that particular fork.
It’s also more comfortable, and that’s worth admitting straight out. Writing code is legible work: you start, you make progress, you finish, you can see the diff. Helping someone else get unstuck, or reviewing a design doc that isn’t quite right yet, or sitting through a conversation about a decision that has three defensible answers - none of that has the same shape. It’s slower to see the payoff, and some days it doesn’t feel like “real work” at all, even though it obviously is.
And it gets rewarded. Early on, being the person who can jump into anything and fix it is exactly what makes you look good - to your manager, to your team, to yourself. The org sees a tech lead who ships. What the org doesn’t see, for a while, is that everything routes through you, that your team’s output is capped at your personal bandwidth, and that the people who report to you aren’t getting better at the hard problems because you keep taking the hard problems away from them.
That last part is the trap within the trap. It’s not that leads who code too much are hoarding boring work - it’s usually the opposite. The interesting bugs, the thorny design decisions, the ambiguous problems that would actually grow someone’s judgment: those are the ones a hands-on lead finds hardest to hand off, because those are the exact problems that are fun to solve yourself. You end up delegating the tedious stuff by default and quietly keeping the growth opportunities for yourself, without ever deciding to.
What actually forced the change
It wasn’t a realization. It was a scheduling collision.
I picked up a second workstream. Not a promotion, just scope creep dressed up as an opportunity, the way it usually is. And for about three weeks I tried to keep doing everything the old way across twice the surface area. I was reviewing PRs at 11pm. I was the bottleneck on two teams’ critical paths instead of one. And the moment that actually broke the pattern wasn’t a burnout crisis or a dramatic confrontation. It was smaller and dumber than that: I was out for four days, mostly offline, and when I came back, the team had shipped a moderately hard feature without me. Cleanly, with a design decision I would have made differently but that turned out to be fine.
That was the uncomfortable part. Not that they’d struggled without me. That they hadn’t.
It forced a question I’d been avoiding: if the team can produce good outcomes when I’m not in the loop, what exactly was I in the loop for? Some of it was legitimately valuable - context, judgment calls, catching things earlier. But a lot of it was just me missing the right opportunities to remove myself from the equation, at the particular moments where doing it themselves is how they’d get better at it.
What it cost
I’m not going to pretend this was a clean win, because it wasn’t.
I got measurably worse, in the compounding sense, at the parts of engineering that only stay sharp with repetition. I used to be able to hold an entire tricky system in my head because I was in the code every day. Now I hold the shape of it and trust other people with the details. There are review comments I make today that I’d have caught faster, more precisely, two years ago. That’s a real loss, not a hypothetical one.
I also lost the specific, immediate satisfaction of finishing something. Tech lead work, the version of it that’s actually working, is slower to feel productive in. You spend an hour in a design discussion and walk away with nothing you can point to except a decision that might save someone else three days next month. Some weeks that trade doesn’t feel worth it in the moment, even when I know, structurally, that it is.
And there’s a status cost that’s easy to underrate: for a while, less-senior engineers on adjacent teams stopped assuming I was the person who’d personally fix their hard problem, because I mostly wasn’t anymore. That’s the system working as intended. It didn’t feel great.
What it gained
The team’s actual output - not my output, the team’s - went up in a way that took a couple of quarters to become visible and then became obvious. Two engineers who’d been doing competent-but-unremarkable work started making design calls I wouldn’t have predicted them ready for, mostly because I stopped making those calls for them. The bus factor on our systems, which had quietly been “me,” spread out to three or four people who actually understood the tricky parts because they’d been forced to sit with them instead of handing them up.
My own job got more sustainable, which I didn’t expect and probably should have. Doing everything yourself doesn’t scale, and I don’t mean that as a platitude. I mean I was structurally guaranteed to hit a wall, and the version of hitting that wall through a slow scheduling collision was a lot better than the version where it happens through a health scare or a resignation you didn’t see coming.
The honest summary is that I traded a kind of work I was very good at for a kind of work I was mediocre at and slowly got less bad at. I still write code. The exceptions matter, and I’ll get into where hands-on work is still the right call in a later post. But it’s now a deliberate, occasional choice instead of the default answer to every hard problem that lands on the team.
If you’re where I was, still functionally the best IC on your own team and still reaching for the keyboard first, I don’t think the fix is a rule like “never write code again.” It’s noticing, specifically, which problems you’re taking for yourself because they’re genuinely urgent, and which ones you’re taking because they’re the ones you’d enjoy solving. Those are not the same list, and the gap between them is where your team’s growth is actually sitting.
I get into the fuller list of what changes day-to-day, beyond just the coding question, in What Actually Changes When You Become a Tech Lead. And if you’re earlier than I was here, still in your first few months in the role, The First 90 Days as a New Tech Lead gets more tactical about the specific moves worth making before you’ve earned the standing to skip any of them.