Thuan: Alex, this is our last coffee break in the series. I want to talk about something personal. I was promoted to tech lead two years ago. And honestly? The first six months were terrible. Nobody told me what the job actually is.
Alex: I had the exact same experience. As a senior developer, I was the best coder on the team. I could debug anything, design elegant solutions, and write clean code. Then I became a tech lead and suddenly… none of that mattered as much.
Thuan: What do you mean?
Alex: As a senior developer, your job is to write great code. As a tech lead, your job is to make the entire team write great code — without writing most of it yourself. That’s a completely different skill set. And nobody trains you for it.
The Identity Crisis: I’m Not Coding Anymore
Thuan: That’s the hardest part. I used to spend 80% of my day coding. As a tech lead, it’s maybe 20%. The rest is meetings, reviews, planning, and answering questions. I felt guilty. Like I wasn’t producing anything.
Alex: Every new tech lead goes through this. The identity crisis. “Am I still an engineer? Am I just a manager? What am I?”
Here’s the mindset shift: your output is no longer your code. Your output is your team’s output. If you write beautiful code for 8 hours but your three team members are stuck, blocked, or building the wrong thing — you had a terrible day. If you wrote zero code but unblocked three people, clarified a confusing requirement, and reviewed a critical pull request — you had an incredible day.
Thuan: I intellectually understand that. But emotionally, it still feels wrong some days.
Alex: It does. And that’s OK. The trick is to find fulfillment in different things. Instead of the satisfaction of solving a hard technical problem yourself, find satisfaction in watching your junior developer solve it — because you coached them, set up the right context, and trusted them to figure it out.
The Three Modes of a Tech Lead
Thuan: So what does the job actually look like? Day to day?
Alex: I think of it as three modes. You constantly switch between them.
Mode 1: Technical leader. You make architectural decisions. You review designs and code. You set technical standards. You decide which technologies to use and which to avoid. You’re the person who says, “We’re not adding another framework to this project” or “This needs to be a microservice, not a module.”
Mode 2: People facilitator. You unblock people. You translate between the business team and the engineering team. You shield your team from unnecessary meetings and politics. You help junior developers grow. You have difficult conversations when someone’s work quality is slipping.
Mode 3: Process guardian. You make sure the team’s workflow actually works. Sprint planning, code review standards, deployment processes, documentation. You notice when the process is slowing people down and you fix it.
Thuan: Which mode takes the most time?
Alex: Mode 2. People facilitation. And it’s the one most tech leads are least prepared for. We became engineers because we like solving technical problems. But most of a tech lead’s impact comes from solving people problems.
The Communication Shift: 70% of Your Job
Thuan: This is where it gets hard for non-native English speakers like me. Suddenly, my job is communication — and I have to do it in a second language.
Alex: Let’s talk about the types of communication you need to master.
Upward communication. Talking to your manager and stakeholders. They don’t care about the technical details. They care about: “Is the project on track? What are the risks? When will it be done?” Your job is to translate technical complexity into business language.
Thuan: Give me an example.
Alex: Bad: “We discovered that the database query for the user dashboard page has an N+1 problem that’s causing response times to exceed 3 seconds under concurrent load because the ORM doesn’t eager-load the associated records.”
Good: “The dashboard is slow. We found the cause. The fix is straightforward — about 2 days of work — and will bring load times from 3 seconds down to under 200 milliseconds.”
Thuan: The second version is so much clearer.
Alex: Because it answers the stakeholder’s real questions: Is it a big problem? Do we know the cause? How long to fix? What’s the improvement? The technical details are irrelevant to them.
Downward communication. Talking to your team. Here, you need to explain decisions. Not just “we’re doing X” but “we’re doing X because of Y.” Engineers need context to be motivated and to make good decisions on their own.
Lateral communication. Talking to other tech leads, product managers, designers. This is negotiation. “Can we simplify this feature?” “We need two more weeks.” “This technical debt is slowing us down — here’s my proposal.”
Making Decisions Without All the Information
Thuan: One thing that stresses me out: making decisions. As a developer, I could investigate until I found the perfect answer. As a tech lead, I often have to decide with incomplete information.
Alex: This is the biggest mental shift. As a developer, you optimize for correctness. As a tech lead, you optimize for speed of progress.
Here’s my framework: the 70% rule. If you have 70% of the information you need, make the decision. Waiting for 100% means waiting too long. The cost of delay is usually higher than the cost of a slightly imperfect decision.
Thuan: But what if I make the wrong call?
Alex: You will. Regularly. And that’s OK. The important thing is to make reversible decisions quickly and irreversible decisions carefully. Choosing a database? That’s hard to reverse — take your time. Choosing between two UI approaches? Easy to change — decide fast and move on.
Thuan: How do you know if a decision is reversible?
Alex: Ask yourself: “If this turns out to be wrong, how long would it take to undo?” If the answer is days, it’s reversible. If the answer is months, think harder. Jeff Bezos calls these “one-way door” and “two-way door” decisions. Most decisions are two-way doors masquerading as one-way doors.
Technical Depth vs. Breadth: The T-Shape
Thuan: Do I need to stay deep technically? Or shift to breadth?
Alex: Both, but the balance changes. As a senior developer, you might be a deep specialist — the world’s best at React, or PostgreSQL optimization, or distributed systems. As a tech lead, you need to become T-shaped.
The vertical bar of the T is your deep expertise — keep it. Don’t abandon your specialization. But add the horizontal bar — broad knowledge across many areas. You need to understand databases, deployments, security, frontend, backend, and infrastructure well enough to make architectural decisions and evaluate your team’s work.
Thuan: How deep is “deep enough” in areas outside my specialty?
Alex: Deep enough to ask good questions and recognize bad answers. You don’t need to write Kubernetes manifests yourself. But you need to know enough to ask: “Have we considered what happens when this pod runs out of memory?” You’re not the expert in everything — you’re the person who makes sure the experts are making sound decisions.
Dealing With Conflict
Thuan: Here’s something nobody talks about. Conflict. Two developers disagree on an approach. A product manager pushes an unrealistic deadline. A stakeholder wants a feature that would create technical debt. How do you handle these?
Alex: Technical disagreements between developers. First, let them argue it out. Most technical disagreements resolve themselves. If they don’t, your job is to facilitate, not dictate. Ask questions: “What are the trade-offs of each approach? What’s the impact on the timeline? What’s easier to change later?” Help them reach a decision together. Only overrule if they’re deadlocked and the project is suffering.
Thuan: What if they come to me wanting a ruling?
Alex: Resist the urge to just pick one. Ask them to present their cases — briefly. Often, the act of articulating the argument helps them see the other side. If you must decide, explain your reasoning: “I’m going with approach A because it’s simpler and we can iterate. If it doesn’t work, we’ll switch to approach B.”
Unrealistic deadlines. Don’t just say “no.” Negotiate. “We can deliver feature X by that date if we simplify sub-feature Y. Or we can deliver everything but we need two more weeks. Which is more important to you?” This gives stakeholders a choice instead of a conflict.
Thuan: And technical debt?
Alex: Frame it in business terms. “If we take this shortcut now, it’ll save us 2 weeks. But in 3 months, it’ll slow down every new feature by 30%. If we fix it properly now, it takes 2 extra weeks but we maintain our development speed.” Stakeholders understand time and money. They don’t understand “the architecture is suboptimal.”
The Most Important Skill Nobody Mentions
Thuan: If you could name one skill that matters most for a tech lead, what would it be?
Alex: Delegation. And I don’t mean “assigning tasks.” I mean genuinely trusting your team to make decisions and tolerating imperfect outcomes.
Thuan: That’s hard. I know that if I do the task myself, it’ll take 2 hours and be done well. If I delegate it, it takes 6 hours and might need revisions.
Alex: But you’ve missed the bigger picture. If you do it yourself in 2 hours, you’ve produced one unit of output. If you delegate it and spend 30 minutes coaching, your team member produces one unit of output AND learns a new skill. Over time, they get faster and better. You’ve invested 30 minutes now to gain hundreds of hours of capability later.
Thuan: It’s like training someone to fish instead of fishing for them.
Alex: Exactly. And here’s the painful truth: if you do everything yourself, you become the bottleneck. Your team can only move as fast as you. A tech lead who delegates effectively multiplies the team’s output. A tech lead who hoards the work divides it.
Career Growth as a Tech Lead
Thuan: Where does a tech lead go from here? What’s the career path?
Alex: Two paths, broadly.
The management track: Tech lead → Engineering manager → Director → VP of Engineering → CTO. Each level is less about technology and more about people, strategy, and organization.
The technical track: Tech lead → Staff engineer → Principal engineer → Distinguished engineer. Each level is about broader technical impact — influencing architecture across teams, across products, across the company. You stay technical but at a higher level of abstraction.
Thuan: Which one is better?
Alex: Neither. It depends on what energizes you. If you love building teams, mentoring people, and shaping organization culture — the management track. If you love solving hard technical problems across large systems and influencing technical strategy — the individual contributor track.
The important thing: you don’t have to decide now. Many people switch between tracks throughout their career. I’ve gone from tech lead to manager and back to IC twice. Each switch taught me something valuable.
Advice I Wish Someone Gave Me
Thuan: Let’s end with the advice you wish you’d gotten.
Alex: Five things.
One: Your team’s success is your success. Stop measuring yourself by the code you write. Measure yourself by the code your team ships, the problems they solve, and the growth they experience.
Two: Write things down. Decisions, reasons, architecture diagrams, meeting notes. Your brain is not a database. In six months, nobody will remember why you chose PostgreSQL over MongoDB unless it’s written somewhere.
Three: Have one-on-ones every week. Not status updates — real conversations. “What’s frustrating you? What do you want to learn? What can I do better?” These fifteen-minute conversations build trust that pays dividends for years.
Four: Say no. To unnecessary meetings, to scope creep, to “just one more feature.” Protecting your team’s focus is one of the most valuable things you can do. Every yes to something new is a no to something existing.
Five: Take care of yourself. Tech leads burn out. The combination of technical responsibility, people management, and stakeholder pressure is heavy. Set boundaries. Take vacations. Don’t answer Slack on weekends unless the building is literally on fire.
Thuan: That last one is hard for me. I feel responsible for everything.
Alex: You are responsible. But responsible doesn’t mean always available. A tired, burned-out tech lead makes bad decisions, snaps at people, and misses important details. Taking care of yourself IS taking care of your team.
Key Takeaways You Can Explain to Anyone
Thuan: Final summary. What changes when you become a tech lead?
Alex:
-
Your output changes. From writing great code to enabling your team to write great code. Your impact is measured by team productivity, not personal productivity.
-
Communication becomes 70% of your job. Translate business needs to technical plans. Translate technical complexity to business language. Facilitate, negotiate, and document.
-
Make decisions with 70% information. Speed matters more than perfection for most decisions. Distinguish between reversible and irreversible decisions.
-
Delegate genuinely. Trust your team. Tolerate imperfect outcomes. Coach, don’t control. You’re investing in long-term capability, not optimizing for today’s output.
-
Your biggest challenges are human, not technical. Conflict resolution, motivation, growth conversations, work-life balance — these matter more than any technology choice.
Thuan: Alex, this whole series has been incredible. I’ve learned so much — not just about technology, but about how to explain it clearly.
Alex: That’s the real skill, Thuan. In this industry, the people who can explain complex things simply are the ones who lead. Because leadership is influence, and influence comes from clarity.
Thuan: Coffee’s on me. For the rest of the year.
Alex: Deal.
This is Part 12 of the Tech Coffee Break series — casual conversations about real tech concepts, designed for listening and learning.
The full series:
- Microservices — So… Why Did Everyone Split Their Apps?
- APIs — REST, GraphQL, gRPC — Which One Do I Pick?
- System Design — How Does Netflix Handle 200 Million Users?
- Docker & K8s — Containers Are Just… Fancy Zip Files?
- AI Basics — AI Is Just Math and Guessing, Right?
- AI in Production — Cool Demo, But Will It Work Monday Morning?
- Databases — SQL or NoSQL? It Depends
- CI/CD — My Code Works On My Machine! Now What?
- Security — A Hacker Walks Into Your API…
- Interviews — The System Design Interview — Let’s Practice
- Architecture — Event-Driven, CQRS, Saga — Buzz or Useful?
- Career — From Senior Dev to Tech Lead (this post)