From Senior to Tech Lead: What Changes Besides Your Salary

When I Realized Everything Had Changed

Monday, 9:47 AM. I open a pull request with the refactoring I'd been planning for a week. Clean architecture, clean code, green tests. In 15 minutes — meeting with product. Then sync with backend. Then 1-on-1 with a junior. Then planning. By 6:00 PM I realized that I'd written exactly 12 lines of code all day.

But I had:

• Resolved a priority conflict between product and business
• Explained to a junior why his caching approach would break the system in a month
• Aligned integration architecture with the backend team
• Ran planning for 2 weeks for a team of 6 people

Old me (Senior): "I didn't do anything today, just meetings." New me (Tech Lead): "I unblocked the team for 2 weeks of work today."

This is the first thing that changes: the productivity metric. I used to measure my day in closed tickets. Now — in unblocked people.

What Really Changes (Spoiler: Almost Everything)

1. Focus Shifts: From Tasks to People

Senior Developer:

• "How do I solve this task faster?"
• "Which pattern fits here?"
• "How do I optimize this query?"

Tech Lead:

• "Who on the team can grow from this task?"
• "Why has the mid-level been stuck on this task for three days?"
• "How do I distribute tasks so no one burns out before release?"

Real case from practice:

A mid-level got stuck on a query optimization task. Third day trying to squeeze performance through indexes. Me as Senior: "Let me see" → fix in 20 minutes → everyone happy.

Me as Tech Lead: I sit next to them, look together. Turns out the problem isn't indexes, but they don't know about EXPLAIN ANALYZE. I spend an hour explaining. The mid-level finds the solution themselves. A month later, they're already consulting juniors on query optimization.

The difference:

• Senior solved the problem → +1 feature
• Tech Lead taught the mid-level → +∞ features in the future

2. Communication Matters More Than Code

I used to sit in headphones for 6 hours straight and write code. It was meditation. Now the longest focus block is 90 minutes. And that's a luxury.

New reality:

How my day changed:

3. Responsibility: From "My Code" to "Our Product"

The case that changed everything:

Friday release. Junior pushed a feature to production. Saturday morning — service down. N+1 queries that I missed in code review.

Old logic (Senior): "I didn't write it, not my problem."

New reality (Tech Lead): call from CTO Saturday 9:00 AM. "Why did it crash? You're Tech Lead, you're responsible for stability."

I'm accountable for:

• Code I didn't write
• Architectural decisions of the whole team
• The junior not knowing about EXPLAIN
• Missing the problem in code review
• Lack of automatic N+1 checks

What I changed after that:

1. Added N+1 checks to CI (gem bullet for Rails)
2. Ran a performance workshop for the team
3. Updated code review checklist
4. Implemented a rule: critical PRs reviewed by minimum 2 people

4. Time: Fragmented vs Focused

The most painful metamorphosis.

Senior can block 4 hours on calendar and dive into deep work. Tech Lead can't. You constantly have someone stuck:

• "My CI failed, don't understand why"
• "Product asks for estimate on urgent feature"
• "Conflict in repository, how to merge?"
• "Infra team asking about load on new service"

My top-3 interruptions per day (real statistics):

1. Technical questions: 8-12 times (Slack, walk-ups)
2. Unblocking tasks: 5-7 times (CI, code review, architecture)
3. Coordination: 3-5 times (product, adjacent teams, management)

Total: 16-24 interruptions per day. Average focus block length: 40-60 minutes.

How I adapted:

• Time blocking: 90-minute blocks, clearly in calendar marked "Focus time"
• Async-first communication: teach team to write in Slack with context, not "quick question?"
• Office hours: 2 windows per day of 30 minutes — "come with any questions"
• Deep work evenings: 2-3 times a week stay an hour after team leaves, when it's quiet

Skills That Suddenly Became Critical

I thought good code was 80% of Tech Lead work. I was wrong. Here's what actually determines success:

1. Ability to Explain "Why"

Bad Tech Lead: "We're doing microservices because it's trendy."

Good Tech Lead: "We're doing microservices because the team grew to 15 people, the monolith became a deployment bottleneck, and business requires independent module releases. But we pay for this with infrastructure complexity and distributed transactions. Here are the trade-offs..."

Case:

Product wants real-time chat. Junior suggests WebSockets. I explain:

"WebSockets are about persistent connections. We have 100k active users. That's 100k open connections. Server will crash. Let's first calculate: how many messages per second? Is 2-3 second latency critical? Maybe Server-Sent Events or long polling are cheaper?"

Team understands choice logic, not just technology.

2. Delegation (The Hardest Part)

My failure #1:

Critical feature, 3 days until release. Mid-level is slow. I think: "Faster if I do it myself." Take the task. Do it overnight. Release successful.

What went wrong:

• Mid-level demotivated ("I'm not good enough")
• Team doesn't grow (I solve all hard problems)
• I burn out (working for two)
• Business depends on one person (if I leave — everything stops)

Right approach (which I learned through pain):

1. Assess risk: if feature is critical but there are 3 days — risk is acceptable
2. Sit with the mid-level: "Let's figure this out together. Where are you stuck?"
3. Pair programming: first hour together, then — with support
4. Let it fail, but have a safety net: review PR extra carefully

Result:

• Mid-level completes feature in 2.5 days (slower than me, but!)
• They grew
• Next time will be faster
• I freed up time for other tasks

3. Emotional Intelligence

What this means in practice:

Scenario 1: Junior struggling with a bug for three days. I see: they're irritated, tired, close to burnout.

Bad approach: "Figure it out yourself, it's a simple bug."

Right approach: "I see you're stuck. Let's take a break: grab coffee, discuss the problem with a fresh head. Sometimes a bug isn't about knowledge, it's about fatigue."

Scenario 2: Mid-level late to meeting for third time this week.

Bad approach: call them out publicly.

Right approach: 1-on-1 after meeting. "Noticed you're late more often than usual. Everything okay? Something getting in the way?"

Turns out their daycare broke down, they drive kid to grandma's in the morning. Solution: shift meeting half an hour later for whole team.

Conclusion: people aren't resources. They have lives, problems, emotions. Accounting for this isn't weakness, it's pragmatism. Happy team writes better code.

4. Ability to Say "No"

Worst skill for Senior, best for Tech Lead.

Product comes: "We urgently need integration with new API, client demands."

Senior (old me): "Okay, we'll do it."

Tech Lead (me now): "Let's look at the roadmap. We currently have auth refactoring, DB migration, and two critical bugs. This feature adds 2 weeks. What from current do we drop? Or push the deadline?"

Result: product goes to business, business decides priorities. Often turns out integration isn't that critical.

My Failures (So You Don't Repeat Them)

Failure #1: Micromanagement

What happened:

First month as Tech Lead I reviewed every line of code. Demanded rewrites if not to my standards. Dictated how to name variables.

Result:

• Team stopped showing initiative ("will have to redo anyway")
• I drowned in reviews (3 hours per day)
• Mid-levels grew slowly (didn't make decisions themselves)

What I changed:

• Review for architecture and logic, not style (for style — linters and prettier)
• 2-comment rule: if more — call for pair programming, don't write essay of comments
• "I'd do it differently, but your way works too" — say this phrase often

Failure #2: Didn't Delegate Code Review

I thought: "Only I know the architecture, only I can review quality."

Result:

• Bottleneck: PRs hung 2-3 days in my queue
• Team didn't grow (mid-levels didn't learn to review)
• I burned out (30-40 PRs per week)

Solution:

• Mid-levels review junior code (I backstop)
• I review only critical parts (auth, payments, core logic)
• Weekly code review workshop: discuss interesting PRs as whole team

Failure #3: Forgot About Code

First 2 months I dove so deep into management I barely wrote code. Only reviews, meetings, planning.

Result:

• Lost skill (after 3 months noticed I code slower)
• Distanced from team (they're in code, I'm in Confluence)
• Lost joy (I coded because I love code, not meetings)

Solution:

• Minimum 20% time on hands-on coding
• Take complex technical tasks (not routine, but what's interesting and develops team)
• Wednesday is my "focus day": no meetings, only code and architecture

How to Know If You're Ready for the Transition

Not every Senior should become Tech Lead. These are different career tracks.

You're ready if:

• You're interested in teaching people (not just sharing knowledge, but seeing them grow)
• You can explain "why", not just "how"
• It frustrates you when team works inefficiently, and you want to fix it
• You're ready to spend less time on code (and this doesn't scare you)
• You can listen (not just talk)
• You're not afraid of responsibility for decisions others make based on your advice
• You're ready for fragmented days (goodbye, 4-hour focus blocks)

You're NOT ready (and that's okay) if:

• Code is your meditation, and you want to code 80% of time
• Meetings cause rejection (not fatigue, but actual rejection)
• You're not interested in understanding people and their problems
• You want salary growth but not responsibility
• Deep technical expertise matters more to you than breadth

Readiness Checklist

Go through these questions honestly.

Technical skills:

• You can design system architecture end-to-end
• You know trade-offs of main technologies in your stack
• You can conduct quality code review (not just find bugs, but teach)
• You understand production: monitoring, deployment, incidents

Soft skills:

• You've conducted at least 5 technical interviews (and understand how to assess people)
• You've mentored a junior or mid-level (and saw results)
• You can resolve conflicts (not avoid, but resolve)
• You can explain complex things simply (test: explain API to your grandma)

Motivation:

• You want to be Tech Lead not for money, but for team growth
• You're interested in influencing product, not just code
• You're ready to learn from scratch (because it's a different job)

If 10+ checks — you're ready. If fewer — give yourself time.

Practical Advice for First 90 Days

Days 1-30: Observe and Listen

Don't:

• Rewrite processes from scratch
• Criticize old decisions
• Try to prove you're "the boss"

Do:

• 1-on-1s with everyone on team (learn: what frustrates them, what they enjoy, where they get stuck)
• Code walkthrough: ask each person to show code and explain architecture
• Quiet code review: review everything, but without radical demands yet

Goal: understand context, earn trust, see team pain points.

Days 31-60: First Changes

Choose 1-2 pains that can be solved quickly:

• CI takes forever → parallelize
• Code reviews hang for 3 days → implement reviewer rotation
• No architecture docs → run workshop, draw C4 diagrams

Principle: quick wins. Team should see results of your leadership, not just meetings.

Days 61-90: Rhythm and Processes

Establish regularity:

• Weekly 1-on-1s with each person (30 minutes, not about tasks, about growth and problems)
• Bi-weekly tech sync (discuss architecture, tech debt, experiments)
• Monthly retro (what frustrates, what to improve)

Document decisions:

• ADR (Architecture Decision Records) for all important decisions
• Onboarding guide for newcomers
• Runbook for production incidents

What Changes in Salary (Honestly)

Everyone talks about soft skills, but let's talk money.

Average salary growth for Senior → Tech Lead transition:

Important:

• Just title "Tech Lead" without responsibility change = 0-10% growth
• Real leadership of 5+ people team = 20-40% growth
• Switching companies for Tech Lead position = 30-50% growth

But:

You pay for salary growth with time and stress:

• More hours (meetings + code = 50-60h/week first six months)
• Less focus time on code (if that's your joy — will be sad)
• More responsibility (weekend calls when prod crashes)

ROI of transition:

• Financial: pays off in a year (if salary growth > 20%)
• Career: opens path to CTO, VP Engineering, Principal Engineer
• Emotional: depends on whether you love people and processes

Main Takeaway

Tech Lead isn't just Senior with higher salary.

It's a different job:

• Less code, more people
• Less decisions, more explanations
• Less "I'll do it", more "we'll do it"

It's a transition from "I'm a great developer" to "I have a great team".

And if you're interested in growing people, not just code — this is your path.

If not — Staff Engineer, Principal, Architect are waiting. And these are no less cool tracks.

Key conclusions:

1. Your code is 20-30% of work. Rest: reviews, mentoring, architecture, sync.
2. Productivity metric changes: not "how much I did", but "how much I unblocked".
3. Responsibility grows non-linearly: you're responsible not just for your code, but for whole team's code.
4. Delegation is the hardest skill: you'll learn to give tasks to others, even if you'd do it faster.
5. Emotional intelligence matters more than technical skills: ability to listen, motivate, and resolve conflicts.
6. First 90 days are about trust, not revolution.
7. Not every Senior should be Tech Lead: it's normal to choose a different track.

What to Do Right Now

If you're thinking about transition:

1. Ask yourself honestly: "Am I interested in growing people or do I just want more money?"
2. Try in practice: take a junior as mentee for 3 months. If you enjoy it — your path.
3. Talk to your manager: "I want to try leadership. Can I take some Tech Lead responsibilities?"
4. Learn now:
   • Do code reviews with teaching comments (not just "fix", but "why")
   • Participate in architecture decisions
   • Suggest process improvements

If you're already Tech Lead:

1. Find a mentor (someone who's walked this path)
2. Delegate at least one task today (even if you'd do it faster)
3. Block focus time (at least 2 blocks of 90 minutes per week)
4. Schedule 1-on-1s with everyone on team (if not doing yet)

If you decided Tech Lead isn't for you:

1. That's okay. Staff/Principal Engineer career is growth without management.
2. Talk to your manager about alternative tracks.
3. Invest in depth, not breadth: architecture, performance, security.

---

Related articles:

• The Math of Hiring Juniors: When It Pays Off and When Money Burns
• The Onboarding Mistake That Costs You 42% of Your Team