The Tech Lead Transition
- Shawn West
- Jul 30
- 3 min read
Updated: Aug 6
Engineering Leadership · Part 1
The hardest part of becoming a tech lead is that the thing that got you promoted — being the person who ships the most code — is no longer the job, and clinging to it quietly sinks the team. Your output is now measured through other people, which feels like doing less while being more responsible. This walks through the transition honestly: what actually changes, the time trap that catches every new lead, and how to stay technical without becoming the bottleneck.
You used to be valued for what you built. Now you're valued for what your team builds. Different job. Same title.
Step 1: Your Output Changes (10 min)
Before: lines of code, PRs shipped.
After: features your team ships, engineers who grew, decisions that compounded.
The first month feels like you're doing nothing. You're learning to value indirect impact. Hard.
Step 2: The Time Trap (10 min)
You'll be tempted to:
Write all the hard code yourself
Review every PR personally
Make every decision
Stops scaling at 3 reports. Bottleneck.
Your job: enable others. Not do the work for them.
Step 3: Delegation Isn't Dumping (15 min)
Bad delegation: "Here's a thing. Done by Friday."
Good delegation:
Clear scope
Why it matters
Success criteria
Where to ask questions
Check-in cadence
The first time you delegate something well, it feels slower than doing it yourself. After 6 months: 5 people doing things in parallel. Compounds.
Step 4: You're the Glue (10 min)
A tech lead spends time on:
Cross-team coordination
Unblocking engineers
Reviewing designs
Setting priorities
1:1s
Status updates
Hiring / onboarding
These don't show up in PR counts. They're the work.
The team would notice instantly if you stopped.
Step 5: Stay Technical (10 min)
You don't write most of the code anymore. You still need to:
Read every PR (skim)
Pair on hard problems
Code review at least weekly
Build something small once a quarter
Without it, you lose touch. Suggestions become detached. Trust erodes.
Some leads code 20% of time. Some 50%. Pick what works.
Step 6: Make Decisions (10 min)
Engineers want decisions. "Should we use Postgres or Mongo?" "Refactor or rewrite?"
You won't always have full info. Decide anyway:
Gather input (1 hour, not 1 week)
State the decision
Explain reasoning briefly
Move on
Indecision is worse than wrong decisions. People can recover from wrong.
Step 7: Hold the Vision (10 min)
A team without a vision drifts.
What are we building this quarter? Why? What's not on the list?
Repeat the vision in standups, 1:1s, planning. People forget. Repeat.
Connect each piece of work to the vision. "Why are we doing this?" — should always be answerable.
Step 8: Protect Focus (10 min)
Interrupts come at the team. Some land on you to filter:
"Can your team help with X?"
"Drop everything for this hot fix"
"Quick meeting about something"
You shield the team from most of these. They focus; you context-switch.
Cost: you're context-switched all day. That's part of the job.
Step 9: Career Costs (5 min)
You may:
Code less; code skills atrophy slightly
Lose touch with cutting-edge tech
Be less individually marketable
Trade-offs. Some people regret the move. Some thrive.
Talk to leads you respect before committing. Try it for 6 months; see how it feels.
Step 10: It Takes Time (5 min)
3 months: feeling lost. Normal.
6 months: starting to see the team improve.
1 year: comfortable.
2 years: doing it well.
Don't expect to be great immediately. The skills are different.
What You Just Did
The transition: output changes, time trap, delegation, glue work, staying technical, decisions, vision, focus, costs, time horizon. Becoming a tech lead.
Common Failure Modes
Try to be the best IC and the lead. Burnout in 6 months.
Stop coding entirely. Lose credibility; suggestions miss reality.
Hoard decisions. Bottleneck.
No vision repetition. Team drifts.
Compare to ICs by their metrics. Different job.
Continue the Engineering Leadership path
Part of the Engineering Leadership learning path.
