Is Tech Lead the Worst Job for Engineers?
Let's Talk About It
You spent years learning to code. You got good at it. Really good. People ask you for help. You fix hard problems. You ship work that matters.
Then someone offers you a tech lead role.
You think: more impact, more money, career growth. Sounds good.
Here’s what they don’t tell you: tech lead can be the best job in engineering OR the worst. Not because it’s hard. Because it might be the wrong kind of hard for you.
The Job Nobody Explains
You’re not a manager, but people expect you to act like one. You’re not just an engineer anymore, but you still have to code. You lead, but you don’t control pay, roles, or headcount.
One day you review code. The next you sit in planning for hours. At 5 PM you try to code, but you’re cooked.
The skills that got you here - deep focus, solving hard problems, building things - you’ll use them differently now.
What Actually Happens When It Works
Your junior dev was stuck for two days on a gnarly architecture problem. You spent 20 minutes whiteboarding it with them. They got it. Now they’re crushing similar problems on their own.
You didn’t write the code. You multiplied what someone else could do.
The project was going to slip. You talked to three teams, found the blocker, cleared it. The team shipped on time. Your name wasn’t in the commit history. The CEO sent them a note saying great work.
You were the reason it happened.
Your teammate wanted to try a new approach. Everyone else said it was risky. You ran interference, got them space to prototype it. It worked. They presented it at the company all-hands.
One tech lead told me: “I helped five people ship features I couldn’t have built alone. That felt better than any code I’ve written.”
Another: “My team got promoted. My manager asked what I did. I said ‘I got out of their way and cleared the path.’ That’s the job.”
That’s what good looks like.
What the Calendar Really Looks Like
Before you get too excited, here’s what a normal week actually is:
Monday:
9-11 AM: Coding (interrupted twice)
11-12 PM: Sprint planning
1-2 PM: 1:1 with new dev
2-3 PM: Design review
3-4 PM: Help fix a deploy
4-5 PM: PR reviews
5-7 PM: Try to finish your feature
Context switching becomes your job. Planned coding shrinks.
If that mix sounds energizing - helping people, clearing blocks, seeing the bigger picture - you’ll like this.
If it makes you want to just code, that’s fine too. Don’t take it.
The Trade You’re Actually Making
What you get:
You see the whole system, not just your piece. You understand how decisions at the top affect code at the bottom. You learn to influence without authority. You make other people better, which scales more than your own output.
You get invited to conversations that matter. You shape direction. When something breaks, you’re the one who can explain what happened and why.
What it costs:
Your technical skills shift. You stay sharp on architecture and systems, but you won’t be the first to try every new tool. You learn to code with interruptions or not at all some days.
You’re accountable for things you didn’t write. When the deploy breaks at 2 AM and you weren’t the one who pushed it, you’re still the one coordinating the fix.
People churn. You mentor someone for months. They leave. New person arrives. You start over.
Your identity shifts. You were the builder. Now you’re the multiplier. That’s hard for some people.
Before You Decide
Ask yourself (be honest):
□ Does unblocking three people matter more than finishing your own feature?
□ Can you be okay with daily context switching?
□ Will you protect your own focus time and say no to meetings when needed?
□ Can you take accountability without having full control?
□ Are you willing to be the shield when things break, even if you didn’t write the code?
If you said no to more than two, wait. Build your impact as IC first. There’s no shame in that - senior ICs can have massive impact.
If you said yes to most of them, you might be ready.
What To Do Before You Say Yes
Talk to 2-3 tech leads at your company for 30 minutes each.
Don’t ask “Should I do it?” Ask what they actually do.
“Can I see your calendar from last week?” “Tell me about a normal Tuesday.” “How much do you code, really?” “What surprised you most?” “What do you wish someone told you before you started?”
Look at the calendar, not just the words.
Ask your manager:
“What does success look like in 6 months?” “How much coding do you expect from me?” “Who will coach me on the leadership parts?” “If it’s not a fit, can I return to IC without penalty?”
If they can’t answer clearly, the role isn’t defined. It’s just a title.
Try Before You Commit
Ask for a 2-week pilot:
Run one sprint planning
Drive one cross-team decision
Own one incident post-mortem
Then decide. Most companies will say yes if you frame it as “I want to do this well.”
What Makes Someone Good At This
The best tech leads aren’t the smartest developers in the room.
One told me: “I’m not the best dev here. My job is to make everyone else better. I’ll fight for them to succeed.”
Another: “I write less code. But the code that ships is better because I’m here.”
That’s the job.
Not:
Write most of the code
Make every technical decision
Be the smartest person in every meeting
But:
Make the team better than the sum of its parts
Protect people when they mess up
Clear blocks so they can do great work
Celebrate their wins more than yours
Know when to step in and when to step back
If that sounds like a grind, this isn’t your role.
If it sounds like the kind of impact you want, it might be.
The Decision
Tech lead is a different kind of hard than IC work. Not better. Not worse. Different.
Both paths are real. IC isn’t “less than.” Staff and Principal engineers have massive impact writing code and driving technical vision.
It’s okay to say no. It’s okay to try it and go back. It’s okay to wait until you’re ready.
Don’t take it to look ambitious. Take it when you actually want to grow people and multiply impact through others.
The job gets better when you stop being the hero and start building the team. That means less coding. Make sure that trade matters to you.
But if it does matter - if you want to make five people great instead of just being great yourself - then you need to learn how to do this well.
Most companies promote great ICs to tech lead and hope they figure it out. That’s why so many people struggle.
P.S. I’m launching Tech Lead Academy to help engineers make this transition.
I believe this is the norm for most senior engineers who lean toward the lead role. Being more like a team multiplier, instead of a one-person contributor.
Thanks for sharing!
I almost hate to say it, but if I was in this position I would probably try to write most of my code on weekends. To some degree I already do this. It's often hard for me to focus on code when Teams messages are going back and forth the whole day.