Becoming a tech lead was the goal from pretty early in my career. I had a clear picture of what the role was. More responsibility, more influence over the work, more of the interesting problems landing on my desk because someone had to figure them out and that someone, finally, would be me. It read like the natural next step. The thing you graduate to once you're good enough.
What that picture didn't include was the part of the job that's about leading people. Not management. I knew management was a separate track. I mean the quieter stuff. Sitting with someone else's frustration and not fixing it for them. Holding a position you're 60% sure of in a room of people who want a confident answer. Realizing the thing blocking the team isn't a technical problem, and that nothing in your background really prepared you for the actual one.
This is the post I wish someone had written for me when I was still aiming for the role. Not the ladder advice. The hard parts.
What changed in the day
The honest version of the shift isn't what you read in leadership posts. Yes, there are more meetings. Everyone says that. The meeting count is the easy part to see and the easy part to adapt to. The ones I took longer to notice were quieter.
The first one is your relationship to shipping. As an engineer, the day has a clean ledger. You opened a PR, you closed an issue, you merged a branch. Even on a slow day there's a diff that proves you were here. As a tech lead, half of your most important work doesn't show up that way. You sat in a meeting and changed the direction of a project. You unblocked someone in a thirty-minute conversation. You wrote a short doc that prevented two weeks of wasted work next month. None of that has a green checkmark next to it. The first few months I felt vaguely guilty at the end of every day, because I couldn't point to a thing I'd built. The fix wasn't to build more. It was to stop measuring my day in commits.
The second is the time horizon. Engineering work runs in days. A bug, a feature, a refactor: a thing you can hold in your head start to finish. The lead work runs in weeks and quarters. A hire decision today shapes the team six months out. A standard you set now shows up in code reviews a year from now. The horizon stretches and the feedback loops stretch with it. You stop knowing whether a call you made was a good one for a long time, and sometimes you never really know.
The third is that the day stops having a clean end. When you closed the laptop as an engineer, you were done. The remaining work was on a list, sitting still. As a lead, the open threads keep moving while you sleep. Someone hit something hard at 11pm. A project is drifting and you can feel it without anyone saying so. There's always a thing you could think about more. The skill is learning to put it down anyway.
The fourth is a new kind of fatigue. Coding is mentally taxing in a contained way. You're tired, you go for a walk, you come back. The fatigue from a day of decisions and context switches is different. It doesn't lift the same way. It's lower-grade and longer-tailed. Nobody warned me about it, and I spent the better part of a year thinking I was just under-sleeping.
What advice I stopped giving
There's a list of things I used to say to junior engineers with full conviction. Most of them I'd picked up from people I respected, and some I'd defended in arguments. Sitting in the lead chair quietly took a few of them apart.
I stopped telling people to always push back on bad requirements. The advice isn't wrong, exactly. It's too neat. The version I gave didn't account for what bad requirements actually look like in the wild: usually a partial picture from someone who's already negotiated three other constraints you can't see. The right move is rarely "push back." It's "ask what changes if X." Most of the time the requirement isn't bad. You just don't know what it's load-bearing for yet.
I stopped saying ship fast as a default. Speed matters. The trouble is that ship-fast gets treated as a virtue independent of context, which is how teams end up shipping things that take a year to undo. Some decisions deserve to be slow. Anything that's expensive to reverse (a data model, a hire, a public commitment, a foundational dependency) deserves the time. Speed on the reversible stuff, slowness on the rest. I should have been more careful about which one I was preaching.
I stopped telling people to always speak up in meetings. The advice was pitched at people who under-contribute, which is a real failure mode. But there's an opposite one I didn't account for: the person who fills every silence and pushes the team into worse decisions because nobody slowed them down. Sometimes the best thing you can do in a room is wait. Let the question sit. See what someone else says.
I stopped saying the right tech wins. It doesn't. Alignment wins. The team that picked the okay-but-aligned tool will out-ship the team that picked the better-but-contested one almost every time. The energy you spend defending a technical choice is energy you don't spend using it. I'd watched this happen to other teams and thought we were the exception. We weren't.
The pattern under all of those: the advice I used to give was advice for the version of the job I'd imagined. Sitting in the chair changed which trade-offs I could see.
The rituals that survived
Most of what I did to stay organized as an engineer didn't survive the role change. Tickets I lived in stopped being where my work happened. The PR queue stopped being a useful daily anchor. The deep-work blocks I'd guarded for years got eaten by a calendar I no longer fully controlled. I had to rebuild a lot of it.
What survived is small. Two habits, one rule.
The first habit is a written end-of-day. Five lines, plain text, takes three minutes. What I decided today. What I'm still unsure about. Who's blocked on me. Who I'm blocked on. One thing I want to start with tomorrow. I tried more elaborate systems and they all collapsed within a month. The five-line version has stuck because it's small enough that I actually do it on bad days, which are the days you most need it.
The second habit is reading code I didn't write, on purpose, every week. Not to review it. Just to read it. As a lead it's easy to drift away from the codebase, and a few weeks of that is enough that your suggestions in design reviews start feeling slightly off to the people doing the work. An hour a week of just reading what the team is shipping keeps the drift smaller. It doesn't make me an expert in everything. It makes me less wrong.
The rule is: don't bring up pattern-y problems without sitting with them for 24 hours first. Not the urgent ones. Those go straight up. I mean the "something feels off about how we're approaching X" ones. If I raise that in the moment, half the time I'm reacting to one bad meeting, not a real problem. If it still feels true the next day, it's worth bringing up, and I bring it up better. The 24-hour rule has saved me from a lot of needless team-level drama, almost all of it self-inflicted.
What I assumed would stick and didn't: the deep-work blocks. I tried to defend them and lost. Most days now my best heads-down hour is the one between waking up and the team coming online, not a block I scheduled. Recreating engineer rhythms in a lead's calendar was a year of frustration before I gave up.
Also gone: my old habit of replying to messages in batches. As an engineer it was a productivity move. As a lead, leaving four people waiting six hours each is its own kind of cost.
What I'd tell my earlier self
A short list of things I'd say to the version of me who was aiming for this role.
The job is mostly about people, even the technical parts. The technical parts that are still purely technical mostly aren't yours to do anymore. Make peace with that earlier than I did.
You don't need to have the answer. You need to make sure the team gets to one. Those are different jobs and they require different muscles. The first one is the one you spent a decade training. The second one is mostly new.
Confidence will be asked of you in moments when you don't have it. Faking it doesn't work, because people can tell. Saying "I'm not sure, here's how we'll find out" works almost every time, and the people you respect most are the ones who already do this.
Most of the advice you give right now is for the role you have, not the one you're aiming at. That's not a problem. Just know that some of it will quietly stop being true.
The role isn't a promotion in the way you imagine. It's a different job. You'll be a beginner again at parts of it, and the bits where you're a beginner will turn out to be the most important bits.
The hard parts are the job. Not a side effect of it. Not something to optimize away. If you want the role, the part you're nervous about is most of what you'd be doing.
Top comments (0)