From IC to Tech Lead: The First Promotion Field Guide

60-Second Summary

Tech lead is a hybrid role — half IC, half multiplier. Both halves are real.
Pick the 30% of code that only you should touch. Hand the other 70% away on purpose.
Your deliverable shifts from PRs to a working technical plan and an unblocked team.
Mentor by asking; never grab the keyboard unless the building is on fire.
Earn the right to manage before you ask for the title — manage scope, then people.

Tech lead is the most under-defined role in software. You're the senior engineer who's suddenly responsible for the team's technical output — but no one took coding off your plate, no one gave you authority over performance reviews, and no one wrote down what 'good' looks like. This guide is the field manual for that exact seat: how to lead a small group of engineers technically while staying close enough to the code to be useful.

The role no one defines

At most companies, 'tech lead' is a stretched senior engineer who has been quietly handed three new responsibilities — technical direction, team unblocking, and cross-team translation — without losing any of the old ones. The ambiguity is the role. Your first job is to define your seat, in writing, with your manager.

What tech lead is — and isn't

It IS

Owning the technical plan for a team or product surface
Setting code quality standards and reviewing the hardest changes
Unblocking other engineers, including across teams
Translating between product/business intent and engineering reality
Mentoring 2–5 engineers on the work, not their careers

It IS NOT

A people manager — you don't own hiring decisions, pay, or PIPs
The smartest engineer in every room
The bottleneck for every technical decision
A promotion title — it's a role you can step into and out of
Permission to stop coding

Write your job description in week one

Sit with your manager and answer four questions in writing: What surface do I own? What decisions are mine alone? What decisions are still yours? How will we know in 90 days if this is working? Without these four answers, you are guessing, and the team can feel it.

The 50/50 myth and the real split

The folklore says a tech lead is '50% IC, 50% lead'. In practice the split moves week to week — closer to 70/30 IC during early scoping, closer to 30/70 during execution and incidents. What matters is that you intentionally pick which code is yours and protect time for the rest of the job.

How to pick the 30% of code that's yours to write

1
Critical-path architecture
Foundational interfaces, data models, or anything two teams will depend on. Getting these wrong costs months.
2
Risk reduction spikes
Two-day proofs that de-risk a quarter of work for the team. High leverage, hard to delegate.
3
Hard reviews and pairings
Sit with the engineer doing the trickiest change. Pairing teaches; PR comments don't.
4
The boring glue
The migration script, the on-call doc, the test harness no one wants. Owning it builds credibility faster than the hero PR.
5
What to refuse
Greenfield features a mid-level can own. New CRUD. Anything you'd grab because it's fun, not because it's leverage.

The three jobs of a tech lead

The three jobs, the artifact each one produces, and the failure mode

Job	What it looks like	Artifact	Failure mode
Technical direction	Decide what we build, in what order, with what tradeoffs	A 1–3 page technical plan per quarter	Plans that live only in your head
Team multiplier	Unblock, pair, review, mentor, design-doc-feedback	Cycle time and confidence go up; you become less of a bottleneck	Becoming the bottleneck you were hired to remove
Cross-team translator	Talk to product, design, security, other teams	Crisp decisions in writing instead of looping threads	Disappearing into meetings; team feels unled

“A tech lead's job is to make the team faster than they would be without you. If you can't point to how, you're just a senior engineer with extra meetings.”
— Will Larson, paraphrased from An Elegant Puzzle

Your first 90 days as tech lead

A 90-day plan you can run on Monday

1
Week 1 — Inventory the team
30-minute chats with every engineer. One question: 'What's slowing you down that I could help fix?' Take notes. Don't act yet.
2
Week 2 — Inventory the system
Read the last quarter of design docs, the on-call runbook, and the top 10 open issues. Sketch the architecture from memory; the gaps are your homework.
3
Week 3 — Pick the one thing
Choose one visible technical improvement that the team has wanted for months — a flaky test suite, a slow CI, a missing observability layer. Ship it with one teammate.
4
Month 2 — Stand up the rituals
Weekly tech sync (30 min, decisions log), async design review (PRs with a 'Needs ADR' label), and a written weekly update to your manager.
5
Month 3 — Write the plan
Publish a 2-page technical roadmap for the next two quarters. Get product, design, and your manager to sign it. This is your first piece of leadership in writing.

Running a technical roadmap

A roadmap is not a Gantt chart. It is a written argument: here is the problem, here is what we'll do, here is what we won't, here is how we'll know it worked. The act of writing it forces clarity you can't fake in a standup.

The 2-page technical plan

1
Context (½ page)
What the team owns, what's true today, what's changing in the business that forces this plan now.
2
The 3 bets (1 page)
Three named workstreams with an owner, a rough cost in weeks, and a success signal. Three is the magic number — more becomes a wishlist.
3
Explicit non-goals (¼ page)
What you are deliberately NOT doing this quarter. Half of leadership is making the 'no' list visible.
4
Risks and unknowns (¼ page)
The two or three things that could blow the plan up, and how you'll detect them early.

Roadmaps die in shared docs no one re-reads

Print it (or pin it). Review it at the top of every sprint. If it doesn't drive what the team picks up this week, it's decoration.

Mentoring without micromanaging

The trap of the new tech lead is being too helpful. You see a junior take a wrong turn and you grab the keyboard. The short-term win costs you a long-term multiplier — they learned that you'll rescue them. Mentor by asking, not telling.

Two ways to respond when someone is stuck

What feels efficient

'Here, let me push a fix.'
'Just use X library.'
'I'll handle the review.'
Rewriting their PR yourself

What builds the team

'What have you tried? What's your next experiment?'
'What are the 2–3 options and the tradeoffs?'
'Walk me through your design first.'
Leaving comments that point at the principle, not the line

I can name one engineer I've made measurably more independent in the last 90 days.
I have NOT grabbed the keyboard during a pairing session this month.
Every junior on my team has shipped a non-trivial design doc with my coaching, not my edits.
My PR review comments end in a question more often than a command.

The credibility ledger

Tech lead authority is borrowed, not granted. You don't own performance reviews, so the team follows you only as long as your judgment compounds in their favor. Think of it as a ledger — every good call deposits credibility, every reversal or surprise withdraws it.

Deposits and withdrawals on the credibility ledger

Deposits (+)	Withdrawals (–)
Calling a risk early, in writing, before it hits	Being right in hindsight but silent at the time
Saying 'I don't know — I'll find out by Thursday'	Bluffing through a question and getting caught
Killing your own initiative when data changes	Defending a sunk cost because it was your idea
Crediting the team in public, owning the miss in private	The reverse
Shipping the boring glue work no one wanted	Cherry-picking the fun work

Anti-patterns to avoid

The hero coder

You keep the team's velocity high by working weekends and merging the hardest PRs yourself. The team learns to wait for you. When you leave, the system collapses.

The meeting tourist

You attend every meeting 'in case'. Your IC time goes to zero, your team can't find you, and your calendar becomes your identity.

The architecture astronaut

You spend weeks on a future-proof design while a customer waits for a working version of the current feature. Optionality is not the same as value.

The shadow manager

You start having career conversations, giving feedback on attitude, and weighing in on pay — without the actual authority. This makes the real manager's job impossible and confuses the team.

Are you ready for management?

Some great tech leads stay tech leads forever — it's a senior IC role with leadership texture, not a stepping stone. If you're considering the jump to engineering manager, the honest test isn't whether you can do it; it's whether you'll miss the keyboard so much that you sabotage the new job.

I get more satisfaction from a teammate's promotion than from my own merged PR.
I've coached someone through a difficult performance moment and didn't enjoy it — but I didn't avoid it.
I can sit through a long, ambiguous, people-heavy conversation without checking Slack.
I am ready to be measured on outcomes I don't directly produce.
I have read 'The Manager's Path' and didn't roll my eyes.

The honest closing

Tech lead is the role where you discover whether leadership is a thing you do or a thing you are. There's no wrong answer. The wrong move is taking the EM title because it's the only promotion path on offer.