Engineering Leadership: Interview with Tech Lead

Sarah Chen is a Principal Engineer and Tech Lead at a high-growth SaaS company. She leads a team of 12 engineers building the core platform that powers their product. Over her 15-year career, she’s scaled from individual contributor to technical leadership roles at companies ranging from early-stage startups to public enterprises.

I sat down with Sarah to discuss technical leadership, the transition from IC to lead, architectural decision-making, and how she approaches growing engineers into senior roles.

The Transition to Tech Lead

Ryan: You’ve been a tech lead for about five years now. What was the transition like from senior engineer to tech lead?

Sarah: It was harder than I expected, honestly. As a senior engineer, I was measured on my individual output - code shipped, bugs fixed, features delivered. That translated directly to impact.

When I became tech lead, I had to completely reframe how I thought about my role. My impact was no longer about what I personally built, but about what my team could build. That mental shift took time.

The hardest part was learning to delegate effectively. Early on, when someone asked a technical question, I’d just solve it myself. That was fastest in the short term but completely unsustainable. I had to learn to coach people through problems instead of solving them.

What advice would you give someone considering a tech lead role?

Understand that it’s fundamentally a different job. You’re not going to write as much code. You’ll spend more time in meetings. You’ll need to context-switch constantly. Your day will be fragmented.

If those things sound terrible, tech lead might not be the right path. That’s okay - senior IC is a perfectly valid career path. Some companies now have IC tracks that go all the way up, which is fantastic.

But if you’re energized by helping others grow, by system-level thinking, by enabling a team to accomplish more than you could alone - then tech lead is incredibly rewarding.

Technical Leadership Philosophy

How do you define technical leadership?

Technical leadership is about enabling better technical decisions across the organization. That happens through:

Architecture and direction: Setting technical strategy that aligns with business goals. Making key architectural decisions. Defining standards and patterns.

Unblocking: Removing obstacles that prevent engineers from being effective. Sometimes that’s technical, sometimes organizational, sometimes just asking the right questions.

Growing people: Helping engineers develop their skills and advance their careers. This is the most important part, in my opinion.

Building culture: Creating an environment where engineers do their best work. Setting norms for how we work together.

One thing I’ve learned: You can’t do all of this yourself. Technical leadership is a team sport. I lean on senior engineers to co-own these responsibilities.

How do you balance technical depth with leadership responsibilities?

This is probably the biggest challenge. You need enough technical depth to make good decisions and maintain credibility, but you can’t be in the weeds on everything.

My approach: I stay deep in specific critical areas - usually one or two - where my expertise is most valuable. For everything else, I trust my team and focus on asking good questions rather than having all the answers.

I also dedicate time each week to “depth work” - reading code, prototyping, or diving deep on a technical problem. Usually early mornings before meetings start. That keeps my skills sharp and maintains connection to the codebase.

The mistake I see is tech leads trying to maintain the same depth across everything they did as an IC. That’s impossible and leads to burnout.

Architectural Decision-Making

How do you approach major architectural decisions?

I use a framework I call “decide together, commit fully”:

Phase 1: Problem definition

• What problem are we actually solving?
• What are the constraints?
• What does success look like?
• What happens if we don’t solve this?

Phase 2: Generate options

• Brainstorm multiple approaches
• Don’t evaluate yet, just generate
• Encourage wild ideas
• Diverse perspectives

Phase 3: Evaluate options

• Technical feasibility
• Complexity and maintainability
• Performance characteristics
• Cost (time, money, complexity)
• Risk profile

Phase 4: Decide

• Synthesize input
• Make the call (usually I make final decision, but I’m influenced by the team)
• Document the decision and rationale
• Be clear about what’s decided vs. what’s still flexible

Phase 5: Commit

• Once decided, everyone commits
• Even if you advocated for a different approach
• Disagree and commit

This process takes time, but it results in better decisions and stronger buy-in.

What do you do when the team disagrees about a technical decision?

First, I try to understand the root of the disagreement. Often it’s because people are optimizing for different things - performance vs. simplicity, or speed vs. flexibility.

Making those trade-offs explicit helps. “We’re choosing approach A because we’re prioritizing speed to market over perfect architecture. We can refactor later if needed.”

Sometimes there’s genuine technical disagreement. I’ll usually defer to the person who’s going to implement it, as long as it’s not clearly wrong. They’ll understand constraints I don’t, and they’re more invested if it’s their approach.

If I need to overrule the team, I explain my reasoning clearly. “I understand the concern about X, but I’m deciding Y because of Z strategic considerations.” I don’t pretend it’s a team decision when it’s my call.

How do you avoid over-architecting?

Over-architecting is such a common trap, especially for senior engineers who’ve seen lots of problems.

My rule: Solve the problem you have today, not the problem you might have in three years. Build for 10x scale, not 100x. Add complexity only when the pain of not having it is clear.

I ask: “What’s the simplest thing that could work?” Start there. If it doesn’t work, we’ll learn why and build something better. But often the simple solution is fine.

Code is a liability, not an asset. Every abstraction is technical debt. The less we build, the less we maintain. Simplicity is a feature.

Growing Engineers

How do you approach growing engineers into senior roles?

This is my favorite part of the job. Watching someone grow from mid-level to senior is incredibly rewarding.

My approach depends on the person, but generally:

For engineers growing toward senior:

• Give them increasingly ambiguous problems
• Let them make decisions and own outcomes
• Provide feedback on both technical work and communication
• Create opportunities to lead small projects
• Encourage them to mentor junior engineers

For senior engineers growing toward staff+:

• Push them to think system-level, not just component-level
• Involve them in architectural decisions
• Have them lead design reviews
• Encourage cross-team collaboration
• Develop their ability to influence without authority

The key: Stretch assignments that are just beyond their current capability. Not so far they’ll fail, but far enough that they grow. And support them through it.

What do you look for in senior engineer promotion cases?

Technical skill is table stakes. What distinguishes senior engineers:

Autonomy: Can take ambiguous problems and drive to solutions without constant guidance.

Scope: Their work affects the whole team or multiple teams, not just their immediate area.

Communication: Explain complex technical concepts clearly. Write clear design docs. Give effective code reviews.

Judgment: Make good trade-offs between competing concerns. Know when to be pragmatic vs. when to invest in quality.

Impact: Ship things that matter. Focus on business impact, not just technical elegance.

Collaboration: Work effectively with others. Unblock teammates. Raise the team’s level.

If someone checks most of these boxes, they’re probably ready. They don’t need to be perfect in all areas.

How do you handle performance issues?

This is always hard. My approach:

First: Make expectations crystal clear. Sometimes performance issues stem from misalignment on expectations.

Second: Provide specific, actionable feedback. Not “you need to communicate better” but “in the last three meetings, you didn’t share blockers until asked directly. I need you to proactively raise issues.”

Third: Create a plan with measurable milestones. “By the end of the month, I want to see X, Y, and Z.” Document it.

Fourth: Check in frequently. Weekly 1-on-1s at minimum during a performance improvement plan.

Finally: If there’s no improvement, move quickly to transition the person out. Keeping someone who’s not succeeding is unfair to them, the team, and the company.

The kindest thing you can do is be honest early. Don’t let someone think they’re doing fine when they’re not.

Team Dynamics and Culture

How do you build strong team culture?

Culture is built through consistent actions, not words. What you reward, what you tolerate, how you react to problems - those define culture.

Things I focus on:

Psychological safety: Make it safe to admit mistakes, ask “dumb” questions, or propose wild ideas. When someone admits an error, thank them for transparency rather than criticizing.

High standards: We care about quality. We review code carefully. We test thoroughly. We write documentation. Excellence is expected.

Collaboration over heroics: We win as a team. I actively discourage hero behavior - staying up all night to fix something solo. That’s not sustainable and creates bad precedents.

Work-life balance: I model healthy boundaries. I don’t send messages late at night. I take vacation. I encourage the team to do the same.

Fun: We’re building something important, but we should enjoy it. We celebrate wins. We have team events. We don’t take ourselves too seriously.

What’s your approach to remote team leadership?

Remote work changes team dynamics significantly. What I’ve learned:

Overcommunicate: In an office, you pick up information through osmosis. Remote requires explicit communication. I probably over-communicate now, and that’s fine.

Structured touchpoints: Daily standup, weekly team meeting, bi-weekly 1-on-1s, monthly retrospectives. These create connection points.

Written documentation: Everything important gets written down. No hallway decisions that half the team misses.

Intentional social time: We do virtual coffee chats, remote game sessions, and in-person offsites quarterly. Building relationships matters.

Video on for meetings: Seeing faces creates connection. I ask people to keep video on when possible, though I’m flexible if someone needs it off occasionally.

Async-first for non-urgent matters: Not everything needs a meeting. Slack or email works for many discussions. This respects time zones and focus time.

Technical Challenges

What’s the hardest technical challenge you’ve faced as a tech lead?

We had to re-architect our data layer to support multi-tenancy at scale. The existing system worked fine for thousands of customers, but we needed to support millions.

The technical challenge was significant - sharding strategy, data migration, maintaining consistency, zero-downtime transition. But the organizational challenge was harder.

This project touched every team. It required coordinating 40+ engineers across 6 teams. We had to migrate customers over months while maintaining the existing system. We needed executive buy-in for a project with no user-facing features.

What made it successful:

Clear vision: I wrote a detailed technical design that everyone could understand and align around.

Stakeholder management: Regular updates to leadership. Transparent about risks and trade-offs.

Incremental migration: We didn’t big-bang it. Migrated one customer segment at a time, learned, adjusted.

Empowered leads: Each team had an empowered tech lead who could make decisions for their area. I coordinated but didn’t micromanage.

Celebration: We celebrated milestones. 10% migrated, 50% migrated, etc. Kept morale up during a long project.

It took 9 months, but we pulled it off. And the team learned a ton about large-scale system design and cross-team coordination.

How do you manage technical debt?

Technical debt is inevitable. The question is whether it’s conscious, bounded, and paid down strategically.

I maintain a technical debt inventory - a living document tracking:

• What the debt is
• Why it exists
• Impact (performance, developer productivity, risk)
• Effort to address
• Priority

Every quarter, we allocate 20% of engineering time to debt paydown. We pick the highest ROI items from the inventory and knock them out.

This prevents debt from becoming overwhelming while maintaining feature velocity. Leadership understands that 80% feature work, 20% tech debt is sustainable long-term.

The key is making technical debt visible and having an explicit strategy for addressing it.

Work-Life Balance and Burnout

How do you maintain work-life balance as a tech lead?

It’s hard. The role is demanding. But unsustainable pace leads to burnout, which helps no one.

My boundaries:

Fixed work hours: 9-6, period. Exceptions only for genuine emergencies (production down, major incident).

No email/Slack after hours: I silence notifications. If something’s truly urgent, people can call.

Vacation is sacred: I take my full vacation and completely disconnect. I tell the team who’s covering and trust them.

Delegation: I don’t need to be involved in everything. I trust my team to handle things.

Exercise and hobbies: I run most mornings and play guitar on weekends. These keep me sane.

Regular 1-on-1s with my manager: I surface when I’m overwhelmed and ask for help adjusting priorities.

What signs of burnout do you watch for in your team?

Burnout is insidious. Signs I watch for:

• Decreased productivity or quality
• Withdrawal from team activities
• Cynicism or negativity
• Working excessive hours
• Physical symptoms (fatigue, illness)
• Lack of interest in growth opportunities

When I see these, I have a direct conversation: “I’ve noticed X, Y, Z. How are you doing? What can I do to help?”

Often it’s workload. Sometimes it’s personal life stress. Occasionally it’s a mismatch between role and interests.

The solution varies, but acknowledging the problem is the first step.

Advice for Aspiring Tech Leads

What advice would you give someone aspiring to tech lead?

Start leading before you have the title: You don’t need a title to demonstrate leadership. Lead small projects. Mentor junior engineers. Drive technical discussions. Build the skills before the promotion.

Develop business acumen: Understand how the business works. How do we make money? What are strategic priorities? Technical decisions must align with business goals.

Improve your communication: This is as important as technical skills. Practice explaining complex concepts simply. Write clear design docs. Give effective presentations.

Build relationships: Technical leadership requires influencing people across the organization. Build genuine relationships with other leads, product managers, and stakeholders.

Embrace feedback: Ask for feedback regularly. From your team, from peers, from your manager. Adjust based on what you hear.

Be patient with yourself: You will make mistakes. You will have bad days. Leadership is learned through experience. Be kind to yourself while you grow.

What books or resources do you recommend?

Books that influenced my approach:

• The Manager’s Path by Camille Fournier - Career development for technical leaders
• An Elegant Puzzle by Will Larson - System thinking about engineering organizations
• Team Topologies by Matthew Skelton - Team structure and interactions
• The Phoenix Project by Gene Kim - DevOps and flow
• Radical Candor by Kim Scott - Giving feedback effectively

Also valuable:

• Blog posts by engineering leaders (Will Larson, Charity Majors, Lara Hogan)
• Podcasts (Software Engineering Daily, The Changelog)
• Conferences (attending and speaking)
• Peer groups and communities

Final Thoughts

What do you find most rewarding about technical leadership?

Seeing people grow. When someone I’ve mentored gets promoted, or ships a major project, or gives a great presentation - that’s incredibly fulfilling.

Also, system-level impact. I can’t single-handedly build a massive system anymore, but I can design it, guide its implementation, and ensure it succeeds. Seeing a well-architected system come together through team effort is deeply satisfying.

Any closing thoughts?

Technical leadership is challenging but incredibly rewarding. If you’re considering this path, know that it requires skills beyond just technical excellence. But if you’re energized by helping others succeed and thinking at the system level, it’s an amazing career.

And remember: leadership isn’t about having all the answers. It’s about asking good questions, empowering your team, and creating conditions for success. You don’t need to be perfect. You need to care about your team and continuously improve.

---

Thank you to Sarah Chen for sharing her insights on engineering leadership. Her perspective reflects years of experience scaling teams and systems.