The email came on a Thursday. "Congratulations -- effective next Monday, you'll be leading the backend engineering team." I read it twice, closed my laptop, and stared at the wall for about twenty minutes. I'd wanted this for two years. And now that it was here, the only thing I felt was a weird, heavy dread sitting in my stomach.
I'm writing this three years later. I'm still a tech lead. I almost wasn't. There was a period around month six where I had a resignation letter drafted on my phone. But I'll get to that.
The title of this article says "roadmap," and I need to be honest with you upfront -- there isn't one. Not a clean one. Not the kind you can print out and pin to your wall with neat checkboxes. What I can give you is what actually happened to me, what I wish I'd known, and the stuff that nobody talks about in those LinkedIn posts about "leadership journeys."
Monday Morning, Week One
I showed up to our standup on Monday and realized, for the first time, that I was supposed to run it. Nobody told me how. My manager -- who'd just been promoted to Director -- gave me a vague "you've got this" and disappeared into meetings for most of the week. I was the best coder on the team. That's why they promoted me. And that was immediately, painfully irrelevant.
The first question someone asked me in that standup was about a deadline that Product wanted moved up. I had no idea what the right answer was. As an individual contributor, I'd just say "that seems aggressive" and go back to my code. As the lead, everyone was looking at me to make the call. I said "let me check with Product and get back to you," which bought me about four hours. I spent those four hours panicking quietly at my desk.
This is the part that nobody prepares you for. The promotion happens, and overnight the nature of your problems changes completely. Yesterday your problems had stack traces. Today your problems have feelings.
What Being a Good Developer Has to Do with Being a Good Lead (Less Than You Think)
I'm going to say something that might annoy you: your technical skills are maybe 30% of what makes a good tech lead. Maybe. I know that's uncomfortable because your technical skills are probably why you're reading this. They're probably what got you noticed. They're probably the thing you feel most confident about.
But here's what happened to me. In my first month, I solved a gnarly caching issue that the team had been struggling with for weeks. I dove into the code, figured it out in a day and a half, pushed the fix. I felt great. My old instincts kicked in, and for a day I felt like I was good at my job again.
Then my manager pulled me aside. "That was Priya's task," he said. "She was working on it. She would have figured it out by next week. You just told her, without saying a word, that you don't trust her."
He was right. Priya didn't say anything about it directly, but she was quieter in meetings after that. It took me weeks to rebuild that trust. And the worst part? The caching fix wasn't even urgent. I just did it because it felt good to code.
That instinct -- to jump in and fix things yourself because you know you can -- is the single biggest trap for new tech leads. It's hard to unlearn. Some days I still haven't unlearned it.
The People Part (Which Is Most of the Job)
Nobody tells you how much of tech leadership is actually just... talking to people. About their career goals, about conflicts with each other, about why they seem distracted lately. I went from spending 80% of my time coding to spending maybe 20% coding and the rest in conversations, meetings, planning sessions, and writing documents.
The first time someone on my team came to me upset about a peer review they'd received, I froze. I didn't know what to say. I tried to solve it like a technical problem -- "let's look at the feedback objectively and see which points are valid." That did not go well. What they wanted was to be heard first. I learned that later, after making the same mistake about five more times.
There was a junior developer on my team -- let's call him Ravi -- who was brilliant but terrible at communicating progress. He'd go silent for three days, and I'd have no idea if things were on track or falling apart. My instinct was to micromanage him. Put him on daily check-ins. Require status updates twice a day. But another lead I trusted told me to try a different approach: just have a direct conversation about it. Not accusatory. Just curious.
So I did. I sat down with Ravi and said, "Hey, I've noticed you go quiet when you're deep in something, and I totally understand that -- I'm the same way. But as the lead, I get nervous when I don't hear from you because I need to give updates to people above me. Can we figure out a way that works for both of us?"
He suggested a quick Slack message at end of day. That was it. Problem solved. No micromanagement needed. I just had to... ask.
Month Six: The Draft That Stayed on My Phone
Around month five, everything felt like it was falling apart. We missed a sprint goal. Then another one. Product was frustrated with us. My manager was getting pressure from the VP. A senior engineer on my team put in his notice -- for reasons that had nothing to do with me, but it felt personal. I wasn't sleeping well. I was checking Slack at midnight, then again at 5 AM.
One night I opened Notes on my phone and typed out a resignation letter. Not to send. Just to see how it felt. It felt... relieving. Which scared me. I missed coding. I missed the clarity of it -- the problem is defined, you solve it, the tests pass, you move on. In leadership, the problems never fully resolve. They just evolve into different problems.
I talked to a friend who'd been a tech lead for four years. He laughed when I told him about the resignation letter. "I had mine in a Google Doc for six months," he said. "Everyone does. It's the leadership version of keeping your resume updated."
What kept me from sending it was a conversation with my manager. He didn't give me a pep talk. He just said, very plainly, "The first year is survival. You're not supposed to be good at this yet. You're supposed to be learning what 'good' even means in this role." That reframe helped more than any leadership book I'd read.
Things I Actually Had to Learn (That No One Teaches)
How to say no to product managers. Not "no, that's impossible" but "here are the trade-offs, and here's what I'd recommend." When you frame it as options instead of refusal, the conversation goes completely differently. This took me months to get comfortable with.
How to give difficult feedback. My first attempt at a tough performance conversation was terrible. I sandwiched it so much that the person walked away thinking they were doing great. I learned to be more direct: "Here's what I'm seeing, here's the impact, here's what I need from you going forward." It's uncomfortable. It never stops being uncomfortable. But people actually respect you more for it.
How to run a meeting that doesn't waste everyone's time. I used to let meetings run long, let conversations spiral, let the loudest person dominate. Now I have an agenda, a time limit, and I actively pull quieter people into the discussion. "Ananya, you've worked on this part -- what do you think?" Simple, but it changes the dynamic.
How to manage up. Your relationship with your own manager matters more than you realize. I learned to give proactive updates, flag risks early, and bring solutions alongside problems. My manager told me once, "Don't surprise me in meetings. If there's bad news, tell me before the meeting so we can figure it out together." Best advice I got.
How to protect your team's time. Some of the most important work a tech lead does is invisible -- absorbing organizational chaos so your team can focus. Taking meetings that would otherwise distract your engineers. Filtering requests so the important stuff gets through and the noise doesn't. I didn't understand this for the first three months. I thought my job was to pass everything along.
The Technical Side Doesn't Disappear (But It Changes)
I still code. Less than before, but I make sure I do at least some every week. Not because I need to -- I could delegate everything -- but because staying close to the code helps me make better decisions and keeps me credible with the team.
But my technical contribution shifted. Instead of building features, I focus on architecture decisions, code review as a mentoring tool, and tackling the truly ambiguous problems where someone senior needs to make a judgment call. I write design documents. I review system designs. I think about technical debt and when to pay it down and when to let it ride.
The hardest adjustment was accepting that I'd never be the best coder on my team again. Two of my engineers are faster and more creative than I am now, because they code eight hours a day and I code maybe six hours a week. That was an ego hit. I won't pretend it wasn't. I had to find my identity in something other than being the person who writes the best code.
What I Tell People Who Ask Me About Making This Move
I get asked a lot. Usually by senior engineers who are three or four years into their career and feel like tech lead is the "next step." And I always start with the same question: do you actually want to lead people, or do you just want the title and the raise?
Because if you just want more money and recognition, there are principal engineer and staff engineer tracks at many companies that let you stay technical and still advance. That's not a lesser path. For some people -- maybe most people -- it's the better path.
But if you want to lead -- if the idea of building a team, making strategic decisions, and multiplying other people's output genuinely excites you -- then here's what I'd suggest, based on having done this the hard way:
Start leading before you have the title. Mentor a junior developer. Volunteer to drive a project plan. Offer to lead a sprint retrospective. Take ownership of a cross-team initiative. You'll learn quickly whether you enjoy it or are just romanticizing it.
Read "The Manager's Path" by Camille Fournier. It's the one book I recommend because it's written by someone who actually did the work, not a management consultant theorizing from the outside. It won't answer everything, but it'll prepare you better than anything else I've found.
Find a mentor who's a tech lead or engineering manager, and be honest with them about what you're struggling with. The best thing I did in year one was have a monthly coffee with a lead from another team who'd been doing it for five years. He normalized so much of what I was going through.
Accept that you will be bad at this for a while. I was. Everyone is. The people who survive the transition are the ones who are okay with being uncomfortable long enough to get better. If you need to be good at everything immediately, this job will break you.
Three Years In
I like my job now. Most days. Some days I still miss being an IC -- the flow state of coding for four uninterrupted hours, the satisfaction of a clean PR, the simplicity of having my own tasks and just doing them. Those days don't come as often anymore, but they come.
What I've gained is different. I watched Priya -- the same engineer whose caching fix I stole in month one -- get promoted to senior engineer last quarter. I helped build a team that ships reliable software and actually enjoys working together. When something goes wrong now, I don't panic the way I used to. I've seen enough go wrong that I know we'll figure it out.
But there's a question I keep coming back to, and I haven't answered it yet. It sits at the back of my mind during 1-on-1s and sprint planning and late-night architecture discussions. I wanted to share it because I think it matters for anyone considering this path.
The question is this: is the work of leading people as valuable as the work of building things? I believe it is. Most of the time. But there are moments -- watching one of my engineers solve something elegant, something I could have built myself -- where I wonder if I gave up the part of this career that I loved most in order to do the part the company needed most. And I wonder if those can ever be the same thing.
I don't have an answer. I'm not sure I ever will.
Comments