The Tech Lead Role

A tech lead owns the technical outcome of a team's work without owning the people. That's the whole distinction, and it produces a role that's genuinely difficult in a specific way: you're accountable for delivery and architecture, and your only levers are credibility, clarity, and persuasion. You cannot direct anyone. You can only be right often enough, explain well enough, and create enough space that people want your input.

The transition into it catches strong engineers off guard because the thing that got them here — solving hard problems personally — is now a trap. The highest-value work becomes unblocking four people, making a decision that saves the team a month, or noticing that the design has a flaw before anyone builds on it. Those activities produce nothing you can point at in a standup, and they are the job.

The most common failure is the lead who stays the best individual contributor and becomes the bottleneck for everything.

TL;DR

What the Role Actually Contains

The boundary blurs at small companies where one person holds both, and it's worth being explicit about which hat you're wearing in any given conversation. A performance concern raised as technical feedback lands badly, and technical feedback heard as a performance concern lands worse.

The first 90 days

The instinct on day one is to demonstrate value by proposing changes. The instinct is wrong: you don't yet know why things are the way they are, and a proposal that ignores a constraint everyone else knows about costs you credibility you'll need later.

Core Concepts

Leverage

The mental shift is uncomfortable because leverage work is invisible. Nobody notices the outage that didn't happen because you spotted a flaw in a design doc, or the two weeks saved because you settled an argument in ten minutes. Measure yourself on the team's output, not on your commits — and accept that some weeks you'll feel like you did nothing.

Delegation

Delegate to level 2 and 3 as fast as people can absorb it. The instinct is to keep the hard, interesting problem because you'll do it faster — which is true once, and false over six months, because the person who never gets a hard problem never becomes able to solve one.

Delegation done badly looks like abdication. Hand over the outcome, provide the context and constraints, agree on check-in points, and stay available. Then let them solve it differently from how you would, provided the result is sound.

Influence without authority

You can't direct anyone, so what's left:

Protecting focus

A significant part of the job is being a shock absorber. Interrupts, unclear requirements, cross-team requests, stakeholder anxiety, and half-formed asks all arrive at the team, and most of them shouldn't reach the people who are building.

This is genuinely valuable and completely invisible. It's also the part that burns people out if they don't set boundaries — absorbing everything means absorbing everything.

How much to code

What you code matters more than how much. Take the work that's important but not on the critical path: infrastructure, tooling, spikes, the unglamorous refactor, the thing nobody wants. Reviewing everything and building nothing loses you the context that makes your reviews worth having; taking the critical path makes the team wait on you.

Team size shifts it. Three engineers: code a lot. Eight: code much less. Past about eight, the coordination load makes meaningful individual contribution unrealistic and you should either split the team or accept the role has changed.

Best Practices

Ask "what slows you down?" constantly

The most useful question available to you, and the answers are usually cheap to act on — a flaky test, a slow build, a missing permission, an unclear ownership boundary. Fixing three small friction points is often worth more than a quarter of architecture work.

Make decisions explicitly and record them

An undecided question blocks people quietly. A decided one, written down with its reasoning, stops being re-argued. When you're the tiebreaker, break the tie — ambiguity is more expensive than a slightly wrong choice you can revisit. See Architecture Decision Records.

Do the work nobody wants occasionally

The upgrade, the flaky test, the on-call rotation nobody likes. It's the cheapest credibility available, and it tells the team that the unglamorous work is real work rather than something junior people get assigned.

Give feedback close to the event

Specific, timely, and private for corrections; specific, timely, and public for praise. Feedback saved up for a review conversation has lost most of its value, and it belongs to the manager at that point anyway.

Grow your replacement

If the team can't function for two weeks without you, that's a design flaw in how you've been leading. Deliberately distribute context, rotate who leads design discussions, and let someone else be the escalation point sometimes. The test is whether you can take a vacation.

Say no, with a reason and an alternative

"Not this quarter, because X is committed — here's what we could drop, or here's a smaller version we could do now." Saying yes to everything means the team misses commitments, which costs far more trust than a well-reasoned no.

Keep the manager informed, especially about people

You see things a manager doesn't: who's struggling, who's ready for more, where friction is building. Share it. You're not reporting on people — you're giving the person responsible for their growth the information they need.

Common Mistakes

Becoming the bottleneck

Delegating tasks instead of problems

Announcing decisions without reasoning

Never coding

Absorbing everything without pushing back

Treating it as a promotion rather than a different job

FAQ

Is tech lead a promotion?

Not usually. It's a role, often held by a senior engineer, and at many companies it's rotational. It can be a step toward staff engineer or toward management, and it can also be something you do for two years and hand off. Titles and expectations vary enormously between companies — ask what the role means where you are rather than assuming.

How is it different from a staff engineer?

Overlapping and differently scoped. A tech lead is accountable for one team's delivery and direction. A staff engineer typically works across teams on problems too large or too cross-cutting for one team, with less delivery accountability and more architectural and organizational influence. One person is often both; at larger companies they're distinct.

What if I disagree with a decision I have to implement?

State your case once, clearly and with reasoning, to the person who can change it. If the decision stands, commit to it fully and don't relitigate it in front of the team — visible undermining costs you more credibility than losing the argument did. Write down your concern (an ADR is a good place) so it's on record if it turns out you were right.

How do I handle an underperforming teammate?

Give direct, specific technical feedback promptly — that's yours. Patterns of underperformance are the manager's responsibility, so raise it with them factually and early rather than working around it for months. Working around someone quietly is the worst outcome: they don't get the chance to improve and the team absorbs the cost.

Should I stop coding entirely?

No. Stop being on the critical path, don't stop coding. Zero hands-on time degrades your technical judgment within months and removes your ability to feel the friction the team feels. The right work is important-but-not-blocking: tooling, spikes, infrastructure, the refactor nobody wants.

How do I know if I'm doing well?

Signals worth watching: the team ships predictably, people bring you problems early rather than after they've spiraled, decisions get made and stay made, junior engineers are visibly growing, and things keep working when you're on holiday. Your own commit count is not on that list.

Related Topics

References