Technical Leadership (Tech Lead / Lead Engineer)
Leading the technical direction and delivery of a team, without owning its people processes.
A Tech Lead is accountable for how a team's technical work gets shaped, sequenced and delivered. You still build, but your main job is that the pieces fit together, that the pace is sustainable and that the result holds up over time. It is the most common first step towards leadership, and it is genuinely reversible.
What this path actually involves
You turn large pieces of work into something a team can actually execute, set the technical approach, and keep delivery honest - noticing what is stuck, what is over-engineered and what has quietly become risky. You run design discussions, review a lot, pair with people, and translate between product intent and technical reality. You usually still write code, but you protect other people's focus before your own.
What it does not mean
A Tech Lead is not an Engineering Manager. You do not own hiring decisions, performance reviews, compensation, promotion cases or the difficult conversations that come with them, and you should be careful about drifting into them without a clear mandate. It is also not the best engineer on the team getting to decide - your job is that the team makes good decisions, which often means going with a design that is not yours. And it is not a permanent identity: many people lead one project, learn what they wanted to learn, and go back to focused engineering.
Typical responsibilities
- Set and communicate the technical approach for the team's work.
- Split ambiguous work into sequenced, deliverable pieces.
- Keep delivery visible: what is done, what is blocked, what is at risk.
- Hold the quality bar through review, testing standards and design discussion.
- Work with product on scope and sequencing, not only on estimates.
- Grow the engineers around you and hand off ownership deliberately.
Skills that matter
What changes from a strong senior engineer role
As a senior engineer you optimise your own throughput and the quality of what you touch. As a Tech Lead you optimise the team's throughput, which regularly means your own drops and you feel slower. The uncomfortable shift is becoming accountable for outcomes you did not personally implement, while having no formal authority over the people who did.
Signs you may enjoy it
- People already ask you how work should be split, and you enjoy answering.
- A team shipping something coherent satisfies you more than your own merged pull request.
- You are comfortable making a call on incomplete information and revisiting it later.
- You notice someone is stuck before they say so.
- You find it interesting to remove the reason a problem keeps recurring.
Signs you may dislike it
- The interruptions leave you no deep work, and that feels like a loss rather than a trade.
- You avoid the moment where you have to tell someone their approach will not work.
- You keep taking hard tasks back instead of coaching someone through them.
- Conversations about sequencing feel like time stolen from real work.
- You want the decision to be yours and the discussion to be shorter.
Common misconceptions
- That Tech Lead is a junior version of Engineering Manager, or a step you must take on the way there.
- That the role comes with authority; almost all of it is influence.
- That you stop coding - most Tech Leads still code, just less and more selectively.
- That it is a permanent promotion rather than a role you can hold for one project and hand on.
Where it typically leads
From here people commonly widen into engineering management, deepen into Staff or Principal engineering, or move towards architecture, depending on which part of the job they liked. It is one of the few roles where trying it and choosing not to continue usually costs you relatively little, though how a step back is read varies from company to company.
How AI is changing this role
On many teams the bottleneck has moved from writing code to reviewing and validating it, and Tech Leads absorb much of that shift: more change arrives each week, produced quickly and plausibly, and someone has to keep the design coherent. In practice that means investing in clear architectural boundaries, strong tests and shared conventions, because those are what let a team accept AI-assisted work safely. It also means setting explicit norms for how agents are used - what context they are given, what a human must verify, what never gets merged unread. The judgement and coordination parts of the role are carrying more load, not less.
Experiments to run before deciding
Lead one project end to end, deliberately
8-12 weeks
- Ask your manager to make you technical lead for one scoped project.
- Write the technical approach in one page and ask the team to challenge it.
- Break the work down with the team rather than for them.
- Give a weekly written update on progress, risk and decisions that changed.
- Deliberately do not take the hardest task yourself.
Then ask yourself
On the days you wrote almost no code, did you feel useful, or did you feel you had not worked?
Delegate something you would rather do yourself
8 weeks
- Pick a meaningful piece of work where you are the fastest person to do it.
- Hand it to someone who will take longer, and set the outcome rather than the method.
- Support it with two short check-ins instead of taking it back.
- Let a decision you mildly disagree with stand, and watch what happens.
Then ask yourself
Look at what you actually did, not at how you feel about delegation in principle: did you let the slower, different solution ship as it was, or did you find a reason to take it back and redo part of it?
Take on one uncomfortable technical conversation
8-10 weeks
- Find a disagreement in the team that is being avoided rather than resolved.
- Put the trade-offs in writing without declaring a winner first.
- Facilitate the discussion to an explicit decision and record it.
- Follow up with the person whose approach was not chosen.
Then ask yourself
Did creating alignment feel like real work you would do again, or like an unpleasant tax on engineering?
Worth reading
The Manager's Path - Camille Fournier
The early chapters on mentoring and tech lead are the sharpest short description of this role.
Team Topologies - Matthew Skelton and Manuel Pais
Useful for seeing why team boundaries and cognitive load, more than individual skill, decide delivery speed.
Accelerate - Nicole Forsgren, Jez Humble and Gene Kim
Gives you evidence-based language for arguing about delivery practice instead of trading opinions.
Debugging Teams - Brian Fitzpatrick and Ben Collins-Sussman
Short and practical on the human side of leading engineers without authority.
Not sure whether this path is closest to you?
Take the Career CompassHelp improve this page
If you have worked in this role and something here is inaccurate, incomplete or out of date, tell me. Suggestions are reviewed before anything changes.