Nobody warned me that the hardest part of becoming a tech lead would be deleting things from my calendar. I had spent six years building a reputation as the person who shipped fast. Then suddenly I was in meetings all day, reviewing other people's PRs, and wondering why I felt like I was failing. The answer took me embarrassingly long to find: I was still optimizing for output, not for leverage.
As a developer, your success is measured in commits and features. Every line of code you write is yours. You control the quality, the timing, the outcome. It is a clean feedback loop. As a tech lead, your success is measured in what the team ships, and most of those lines of code should not be yours. That is the uncomfortable truth. Your job shifts from being the best coder in the room to being the person who makes everyone else in the room better.
The transition nearly broke my first team. I would review a pull request, see a cleaner way to do it, and rewrite the whole thing before leaving my review comment. My teammate stopped asking for help on hard problems because he figured I would just take over. I was not mentoring. I was gatekeeping with extra steps. It took a project manager calling me out in a retro — politely but directly — to make me see what I was doing.
Delegation is not about assigning tickets. It is about giving someone a problem, letting them struggle with it, and resisting the urge to fix it yourself. That last part is the hardest. I still feel the pull every time I see a junior engineer spinning their wheels on something I could solve in twenty minutes. But twenty minutes of my time now costs the team two days of that person not learning how to solve it themselves.
Communication changes too. As a developer, you explain technical decisions to other developers. As a tech lead, you explain those same decisions to product managers, stakeholders, and sometimes executives who do not care about your architecture. You need to translate risk into business impact. You need to say no in ways that do not sound like no. I learned this the hard way when I pushed back on a deadline by listing every technical dependency that could go wrong. The product lead's eyes glazed over. Later she told me to just say what we could deliver by the date and what would slip. That was the whole answer. I had been over-explaining to protect myself instead of helping her make a decision.
The thing nobody talks about is the loneliness. As a developer, your wins are visible. You deploy something, it works, people use it. As a tech lead, your wins are invisible by default. You remove a blocker, unblock a teammate, catch a design flaw early. Nobody sees the outage that did not happen. You have to learn to find satisfaction in the absence of disasters, which is a weird muscle to build.
If you are about to make this transition, here is what I wish someone had told you: keep coding, but only on the riskiest parts. Protect your calendar ruthlessly. Ask your team what they need from you instead of guessing. And accept that for the first six months, you will feel like you are bad at everything, because you are learning an entirely new job while everyone watches. That feeling does not mean you made the wrong choice. It means you are doing it.