My first 90 days as a tech lead (and the habit I had to break)

Three weeks into leading my first team, I stayed late to "help" by rewriting a junior's feature myself. It was faster my way. I pushed it, felt productive, went home. The next morning he asked, carefully, why I'd redone his work. I didn't have a good answer. I'd solved a two-hour problem and created a much bigger one: I'd just taught my best-motivated engineer that his work would get overwritten if I didn't like it. He never fully trusted a review from me again.

That was the day I understood the job had changed and I hadn't. Being the best engineer in the room got me the role. Keeping that identity was about to make me bad at it.

The keyboard is the trap

For years, my value was measurable in commits. Ticket in, code out. It felt good, and I was fast. So when I became lead, my hands kept reaching for the keyboard, because that's where I knew I was useful.

But here's the math that broke me out of it: if I write the hard code myself, the team ships one hard thing, mine, and four people learned nothing. If I coach four people through their hard things, the team ships four, and next quarter they don't need me for the fifth. Me at the keyboard is a bottleneck wearing a cape.

Letting go of the keyboard doesn't mean never coding. It means coding stops being where I create value. I still write code, but now it's the glue nobody else has time for, the spike to de-risk a decision, the boring plumbing, never the interesting core someone else could grow into.

Where the time actually goes

The hardest adjustment was watching my calendar invert. I went in expecting to code less. I did not expect this much less.

% of week

Nobody told me that unblocking other people would become a third of my job. A five-minute answer from me can save someone a day, and that trade, my five minutes for their day, is the single highest-leverage thing I do now. The instinct that says "I'm not doing real work unless I'm typing" is exactly the instinct that makes you a bad lead. Real work is now measured in what the team ships, not what I commit.

Building trust before spending it

The first 90 days, I spent almost nothing. No big reorg, no rewrite of "how we do things," no sweeping opinions about the codebase I'd barely read. New leads love to arrive and improve everything immediately. It reads as insecurity, and it torches trust you haven't earned yet.

Instead I asked and I listened. What's slow? What's scary to deploy? What's the thing everyone works around and nobody's fixed? I fixed a couple of small, real annoyances, the flaky test everyone re-ran, the deploy step everyone dreaded, and let that be my introduction. Small proof that I was here to make their day better, not to make the codebase mine.

The identity swap

The quiet grief nobody warns you about: you were great at a thing, and now you do less of it. My commit count dropped and for a while it genuinely felt like I was getting worse at my job. I had to consciously move my sense of worth from "what did I build today" to "what did the team build, and did I make it easier."

That reframe is the whole transition. As an IC, a good day is a hard problem solved. As a lead, a good day is a problem you never touched because someone you coached solved it without needing you. The first feels better in the moment. The second is the one that compounds.

What I'd tell myself on day one

Your job is no longer to be the best engineer in the room. It's to make the room better, which sometimes means letting a thing ship slightly worse than you'd have built it, so the person who built it grows. Sit on your hands. Ask before you fix. And measure the week by what happened at four other keyboards, not just yours.