You got promoted. Congrats! Now you’re responsible for the technical direction of your team, and suddenly everything feels... different.
Here’s the truth: becoming a tech lead isn’t about being the best engineer anymore. It’s about making everyone else better. And that shift? It’s where most new tech leads stumble.
I’m going to walk through five mistakes I see constantly. Not because tech leads are bad at their jobs, but because these mistakes are almost required when you’re learning. The good news? Once you know what to look for, they’re fixable.
Mistake #1: Keeping All the Interesting Work for Yourself
You know that awful performance problem? The architecture redesign? The integration with the new system? Yeah, you grabbed all of those tickets.
It makes sense. You became a tech lead because you’re good at solving hard problems. And honestly, it’s faster if you just do it yourself. You know you’ll do it right.
But here’s what happens: your team stops growing. That senior engineer who could have tackled the performance issue? They’re stuck with JIRA tickets. The mid-level developer who needs a challenge? Still writing CRUD endpoints.
Three months later, you’re burned out, your team is bored, and you’ve become a bottleneck.
What to do instead:
Give away the work you want to do. Seriously. Take your backlog right now and ask: “Which of these tickets would teach someone something valuable?”
Here’s a simple system:
Every sprint, identify one “stretch” ticket for each team member
Pair it with mentorship: “Here’s the problem, here’s why it matters, here’s where I’d start looking”
Make yourself available for questions, but resist taking it back
Review their approach early (after a day of work, not after a week when they’re invested in the wrong direction)
Yes, it’ll take longer initially. A task that takes you 3 hours might take someone else 2 days. And here’s the uncomfortable part: you’ll watch them struggle. They’ll go down a path you know won’t work. Your fingers will itch to take the keyboard.
Don’t.
Let them hit the wall. Then ask: “What did you learn? What would you try differently?” That’s where the actual growth happens.
When this advice doesn’t work:
If you’re on a tiny team and truly underwater, you can’t delegate what doesn’t exist. In that case, be explicit about it: “I know I’m hoarding the interesting work right now. We’re in survival mode. When we hire someone in Q2, that changes.” At least your team knows it’s temporary, not how you think things should be.
Mistake #2: Treating 1-on-1s Like Status Updates
“How’s the API integration going?” “Good, should be done by Thursday.” “Cool. Anything blocking you?” “Nope.” “Great, see you next week.”
If your 1-on-1s sound like this, you’re doing it wrong.
But here’s what makes this mistake insidious: even when you ask good questions, people still give you surface-level answers. Especially if they don’t trust you yet, or if they think you’re just going through the motions.
What to do instead:
First, understand that meaningful 1-on-1s take time to build. If someone’s been getting status-update meetings for six months, they won’t suddenly open up because you asked a better question.
Start here—pick ONE of these per meeting (don’t interrogate them with all five):
“What’s something you’re thinking about that we haven’t talked about yet?”
“If you were me, what’s one thing you’d change about how our team operates?”
“What’s a skill you want to develop but haven’t had a chance to use at work?”
“What’s the most frustrating part of your week?” (then shut up and count to 10 in your head if they pause)
That last bit is crucial. Most tech leads ask a question, get a pause, panic, and fill the silence. Let the silence sit. People often say the most honest thing after the pause.
But what if they still won’t open up?
Try this: share something real about yourself first. “I’m honestly struggling with prioritization right now. I keep saying yes to things and then we’re all scrambling. I’m working on it, but it’s hard.”
Vulnerability is contagious. When you’re honest about your challenges, people feel safer being honest about theirs.
Also, keep a scratch file for each person. After every 1-on-1, write three bullets:
One thing they said that surprised you
One thing to follow up on next time
One thing you committed to doing (and actually do it)
When people see you remember details from last time and actually follow through, they start believing these meetings matter.
The thing nobody tells you:
Some people still won’t open up. They’re private, or burned by previous managers, or just prefer to keep work surface-level. That’s okay. You can’t force depth. But you can at least create the conditions where it’s possible.
Mistake #3: Saying Yes to Everything
Product wants a new feature. Your boss wants a refactoring. Customer success needs a bug fixed yesterday. Another team needs your help with their service integration.
You say yes to all of it because you want to be helpful. You want to be a team player. You don’t want to disappoint anyone.
Two weeks later, nothing’s done well. Your team is thrashing between priorities. People are working weekends. The “urgent” bug fix introduced two new bugs. And somehow you’re the bad guy because things are late.
What to do instead:
Your job isn’t to do everything—it’s to make sure the right things get done.
Learn this phrase: “Yes, we can do that. Here’s what we’d need to stop or delay.”
Here’s the actual script I use:
“I want to help with this. Let me show you what we’re currently committed to. [Pull up your roadmap or sprint board.] If we take this on, we have three options:
Push the payment system deadline by two weeks
Reduce scope on the mobile refactor—maybe just iOS first
Drop the performance optimization work entirely
Which makes the most sense given business priorities right now?”
This does something powerful: it makes the tradeoff visible. Most people asking for things don’t know what your team is already doing. When you show them, they either realize their request isn’t that urgent, or they help you re-prioritize.
When they push back:
Sometimes you do this perfectly and they still say “I need all of it.” That’s when you go up the chain: “I need help prioritizing. Here’s what we’re being asked to deliver and the timeline. What should we do?”
Make your manager or their manager make the call. That’s literally their job. Don’t torture yourself trying to do the impossible.
Mistake #4: Not Translating Between Levels
You’re in an architecture meeting with senior engineers, talking about event-driven systems and eventual consistency. Everyone nods. Seems good.
Then you’re in a planning meeting with product and designers. They ask how long the project will take. You say “a few sprints” and they hear “two weeks.”
Then you’re in a 1-on-1 with a junior dev who’s confused about the approach. You explain the architecture but not why you chose it.
The mistake? Assuming everyone has the same context you do. They don’t. And when people lack context, they make bad assumptions, get frustrated, or just tune out.
What to do instead:
Same information, different languages. Here’s what that actually looks like:
Let’s say you need to add rate limiting to your API because you’re getting hammered by bots.
To leadership: “We’re adding rate limiting to prevent service outages from bot traffic. This protects revenue and reduces infrastructure costs. Two weeks of work, low risk.”
To product: “We’re adding rate limiting so bots can’t overwhelm the system. Real users won’t notice anything, but we’ll need to show an error message if someone hits the limit. Can you help design what that message should say?”
To your team: “We’re adding rate limiting because we’re seeing 10K requests per second from bot traffic and it’s degrading performance for real users. We’ll use a token bucket algorithm at the API gateway level. Each endpoint gets its own limit based on expected usage patterns.”
See the difference? Leadership cares about business impact and risk. Product cares about user experience. Your team cares about the technical approach and why you chose it.
When people still don’t get it:
Sometimes you explain something perfectly and people still misunderstand. That’s usually a sign you need to draw a picture. Literally. Architecture diagrams, timeline charts, flow diagrams. Don’t overthink it—a sketch on a whiteboard (or in Excalidraw) often works better than a wall of text.
Mistake #5: Waiting Too Long to Have Hard Conversations
Someone on your team is consistently late to meetings. Or their code quality has dropped. Or they’re negative in every discussion, dragging down the team.
You notice it. Other people notice it. But you don’t say anything because:
Maybe it’ll get better on its own
You don’t want to hurt their feelings
You’re not sure if it’s a “big enough” problem
Confrontation is uncomfortable
So you wait. And the problem gets worse. And by the time you finally address it, it’s a much bigger deal than it needed to be. Now you’re having a Performance Improvement Plan conversation when it could’ve been a casual check-in three months ago.
What to do instead:
Have the conversation the second time you notice the pattern. Not the first time—that could be a fluke. But the second time? That’s a pattern.
But here’s the thing: don’t make it formal. Don’t schedule a “serious conversation.” Just... bring it up like a normal human.
After standup, when it’s just you two: “Hey, can I ask you something? I noticed you’ve been joining standup late the last few days. Is everything okay?”
That’s it. You’re not accusing them. You’re checking in.
Nine times out of ten, they’ll say something like “oh man, yeah, my kid’s daycare drop-off time changed” or “I’ve been having trouble with my internet in the mornings” or “honestly I didn’t realize, I’ll set a better alarm.”
Then you just say: “Got it. Let me know if there’s anything I can do to help” or “No worries, just wanted to make sure you’re good.”
The actual conversation is usually 60 seconds.
But what if it’s more serious?
Let’s say the problem is code quality. Someone’s PRs used to be solid, and now they’re sloppy—missing edge cases, no tests, skipping the team’s standards.
Don’t say: “Your code quality has declined and it’s causing problems.”
Instead: “Hey, I wanted to check in. I’ve noticed your last couple PRs needed more revision than usual. That’s not like you. Is something going on? Are you blocked on something?”
You’re naming what you see, but you’re leading with concern, not criticism.
Maybe they’re overwhelmed. Maybe they’re dealing with something at home. Maybe they don’t understand the new architecture and are too embarrassed to ask. You won’t know until you ask with genuine curiosity.
The mindset shift:
These aren’t confrontations. They’re check-ins. You’re not their boss coming down on them. You’re their tech lead making sure they have what they need to do good work.
When you approach it that way, it doesn’t feel harsh. It feels like you care.
When they actually push back:
Sometimes you’ll have this conversation and they’ll get defensive: “I’m not late, I’m just a few minutes behind” or “My code is fine, you’re being too picky.”
That’s when you stay calm and specific: “I hear you. Let me be more clear. You’ve joined standup 10+ minutes late three times this week. That’s a pattern I need you to change. Can you commit to that?”
If they still resist, then yes, it becomes a more formal thing. But even then, you gave them a chance to course-correct early. That’s fair.
The thing that makes this easier:
Build a habit of positive feedback too. Catch people doing things right. “That refactoring you did yesterday was really clean” or “Thanks for helping debug Sarah’s issue—that was a good catch.”
When you regularly acknowledge good work, people don’t interpret every check-in as criticism. They trust you’re trying to help them succeed, not looking for reasons to criticize.
And honestly? Most people appreciate when you bring stuff up early. It’s way worse to find out six months later that you’ve been frustrating your tech lead the whole time and they never said anything.
The Pattern Underneath All of These
Notice what all five mistakes have in common? They’re all about choosing short-term comfort over long-term effectiveness.
It’s comfortable to keep the interesting work, but your team doesn’t grow
It’s comfortable to keep 1-on-1s surface-level, but you miss what’s really happening
It’s comfortable to say yes to everything, but nothing gets done well
It’s comfortable to assume everyone has context, but miscommunication multiplies
It’s comfortable to avoid hard conversations, but problems fester
Being a good tech lead means getting comfortable being uncomfortable.
Here’s what I wish someone had told me: you’re going to mess this up. You’ll hoard work when you’re stressed. You’ll say yes to things you shouldn’t. You’ll avoid a conversation until it becomes a crisis.
That’s not failure. That’s the learning process.
The difference between a mediocre tech lead and a great one isn’t that the great one never makes mistakes. It’s that they notice their mistakes faster—and fix them before those mistakes calcify into how their team operates.
Start with the one that made you wince when you read it. The one where you thought “oh shit, I’m doing that right now.” Fix that one first. Then move to the next.
You don’t have to be perfect. You just have to be 1% better each week. That compounds faster than you think.
P.S. If you want my help with the tech lead transition, I’m opening up a private community for senior engineers.
Video courses. Expert workshops. Q&A calls. 1:1 support.
👉 Join waitlist