From Senior Engineer to Tech Lead: The Skills Nobody Teaches You

You were the best engineer on the team. You shipped the hardest features, debugged the nastiest issues, and wrote the code everyone else learned from. Then someone offered you the tech lead role, and you said yes — because it felt like the obvious next step.

Six months later, you are drowning. Your calendar is full of meetings. You have not written meaningful code in weeks. You are mediating a conflict between two engineers who disagree on an API design. A product manager is pressuring you to commit to a deadline you know is unrealistic. And you are wondering if you made a terrible mistake.

You did not. You are just experiencing the gap — the vast space between being a great individual contributor and being a great technical leader. Nobody teaches this. Here is what you need to know.

1. The Identity Shift: Your Output Is Now the Team's Output

As a senior engineer, your impact was measured by your code, your designs, your pull requests. As a tech lead, your impact is measured by what the team ships. This sounds simple. It is existentially difficult.

You will watch a junior engineer spend three days on something you could have done in four hours. Your instinct will be to take the keyboard. Do not. Your job is to make that junior engineer someone who can do it in four hours, not to do it yourself. Every hour you spend coding is an hour you are not spending on the force multiplier activities — unblocking people, improving processes, making architectural decisions that save the team weeks of wasted effort.

This does not mean you stop coding entirely. Most tech leads maintain 30-50% hands-on time, focused on the highest-leverage technical work: architecture decisions, prototyping risky approaches, reviewing critical PRs, and maintaining the most complex parts of the system.

2. Running 1:1s That Actually Matter

Most tech leads treat 1:1s as status updates. This is a waste of everyone's time — that is what standups and project boards are for. A great 1:1 is a coaching session focused on the person, not the project.

The Framework

First 5 minutes: Let them drive. Ask "What's on your mind?" and listen. Do not jump to solutions.
Middle 15 minutes: Go deeper on one topic. If they raise a technical problem, ask what approaches they have considered. If they raise a people problem, help them think through perspectives. Your job is to ask better questions, not give answers.
Last 5 minutes: Agree on one concrete action item. Not five. One.

Questions That Unlock Real Conversations

"What is the most frustrating part of your work right now?"
"Is there anything you think the team should stop doing?"
"What would you do differently if you were in my position?"
"What skill do you most want to develop in the next six months?"
"Do you feel like you are learning and growing? Why or why not?"

Keep a running document for each person. Review it before every 1:1. Track themes over time. If someone mentions feeling unchallenged three weeks in a row and you do nothing about it, that is on you. Explore more leadership frameworks in our engineering leadership curriculum.

3. Making Technical Decisions with Incomplete Information

Senior engineers make decisions with full context — they have read the code, understand the constraints, and can reason about trade-offs. Tech leads must make decisions with 60-70% of the information they want, because waiting for 100% means the team is blocked for days.

The Decision Framework

Decision Type	Information Threshold	Reversibility	Process
One-way door	Gather 80%+	Hard to reverse (database schema, API contracts)	Write RFC, get team consensus, take time
Two-way door	Act at 60%	Easy to reverse (library choice, feature flags)	Decide quickly, iterate based on feedback
Team-contested	Facilitate first, decide if stuck	Varies	Hear all sides, then make the call

The most important skill is recognizing which type of decision you are facing. New tech leads over-deliberate on two-way doors (spending a week debating which state management library to use) and under-deliberate on one-way doors (rushing a database schema without enough analysis).

4. Saying No to Stakeholders Without Burning Bridges

Product managers will ask for things that are technically infeasible, politically motivated, or simply lower priority than what your team should be working on. "No" is the most important word in your vocabulary, but how you say it determines whether you are seen as a trusted partner or an obstructionist.

The "Yes, If" Pattern

Never say a flat "no." Instead, say "yes, if" and make the trade-off explicit:

"Yes, we can build that feature by Q3 if we defer the performance improvements. Here is the risk: page load times will likely exceed 4 seconds for 15% of users. Do you want to make that trade?"
"Yes, we can hit that deadline if we cut scope to the core flow only — no settings page, no bulk operations. We can add those in a fast-follow."
"Yes, but the engineering cost is about 6 weeks. If we take this alternate approach, we can get 80% of the value in 2 weeks."

This shifts the conversation from confrontation to collaboration. You are not blocking progress — you are helping the stakeholder understand the real cost and make an informed trade-off.

5. Building Psychological Safety

Google's Project Aristotle found that psychological safety — the belief that you will not be punished for making mistakes — is the single strongest predictor of high-performing teams. As a tech lead, you set the tone.

Concrete Actions

Publicly own your mistakes: When you make a bad technical decision, say so in the retro. "I pushed for microservices here and it was premature. Here is what I learned." This gives everyone permission to be fallible.
Celebrate learning from incidents: Treat production incidents as learning opportunities, not blame exercises. The question is always "how do we prevent this class of failure?" not "who wrote this code?"
Invite disagreement: In design reviews, explicitly ask: "What could go wrong with this approach?" Reward people who point out risks, even if it means more work.
Protect people from politics: Shield your team from organizational chaos. They should not be worrying about reorgs or budget fights — that is your job to absorb and translate into actionable context.

6. Managing Former Peers

This is the most awkward transition in the role. Yesterday you were equals. Today you have positional authority. Here is how to navigate it:

Address it directly: Have an honest conversation. "I know this dynamic is different now. I am still the same person. I need your honest feedback more than ever."
Do not play favorites: If your best friend on the team wrote bad code, give them the same review feedback you would give anyone else.
Earn authority through competence, not position: The best tech leads are followed because people trust their judgment, not because of their title. Make consistently good decisions and people will follow willingly.

7. Writing RFCs That Actually Get Read

If your RFCs are 20-page documents that nobody reads, the problem is not your team — it is your document. Great RFCs follow a pattern:

# RFC Template That Works

## Title: [Verb] + [System/Feature]
# e.g., "Migrate User Authentication to OAuth 2.0 + PKCE"

## Status: Draft | In Review | Accepted | Rejected

## Context (2-3 paragraphs max)
# What problem are we solving? What is the current state? Why now?

## Decision
# What are we going to do? Be specific. Include diagrams if helpful.

## Alternatives Considered (table format)
# | Option | Pros | Cons | Estimated Effort |

## Consequences
# What are the trade-offs? What risks are we accepting?
# What will we need to do in the future because of this decision?

## Action Items
# Who does what, by when?

Keep the main document under 2 pages. Put detailed research in appendices. The goal is to facilitate a decision, not to demonstrate thoroughness.

8. Scope vs. Impact: The Career Calibration

The difference between a tech lead and a staff engineer is not seniority — it is scope. A tech lead optimizes a single team. A staff engineer optimizes across teams. Understanding this spectrum helps you navigate your career:

Level	Scope	Primary Activity
Senior Engineer	Feature / module	Build the right thing, well
Tech Lead	Team	Ensure the team builds the right things, well
Staff Engineer	Multiple teams / org	Ensure teams are solving the right problems
Principal Engineer	Company	Set technical direction at the org level

The leap from senior to tech lead is about expanding from "my code" to "my team." The leap from tech lead to staff is about expanding from "my team" to "the organization." Both require deliberate skill development.

9. The Uncomfortable Truth

Being a tech lead is often thankless. You will unblock someone and they will not realize it was you. You will prevent a bad architectural decision and nobody will know what was avoided. You will spend an hour in a difficult conversation that saves the team a month of wasted work, and it will not show up in any metric.

The reward is watching your team grow. Seeing someone you mentored nail a system design that would have overwhelmed them six months ago. Shipping a project that no individual could have built alone. Building something that lasts.

If that resonates with you, you are in the right role. Keep going. Explore more frameworks and leadership patterns in our engineering leadership learning path and sharpen your technical edge with software architecture.