What a Tech Lead Owns

Scenario

Example team: a payments team of seven engineers, one engineering manager and a product manager. Priya, the strongest engineer, is named tech lead. Nobody writes down what that means. Within a month she is reviewing every pull request, attending every meeting, and writing the hardest code herself.

What you see on the team

• Pull requests wait two days for "Priya's approval", even small ones.
• Priya works evenings; her own tickets slip and she is the bottleneck on every design question.
• The manager assumes Priya handles "technical stuff", Priya assumes the manager handles priorities — so nobody owns the reliability backlog, which quietly grows.
• Two engineers say in 1:1s that they "don't get to make decisions any more".

The common mistake

Treating the tech lead role as "the best engineer, but more": the most code, the final say on every review, the person who answers every question. The title arrives without a written scope, so the lead fills every gap with personal effort.

Why it happens

The role is rarely defined. Will Larson's Staff archetypes describes the Tech Lead as someone who "guides the approach and execution of a particular team" and partners closely with a manager — the word is guides, not does. Promotions, however, usually reward individual output, so new leads keep optimising for it. Without a split of responsibilities with the manager, overlapping work falls on whoever cares most.

The playbook

1. Write the scope down with your manager. A useful split for most teams:

2. Own outcomes through the team. Your job is that the team makes good technical decisions, not that you make them all. Measure yourself by the team's throughput and quality, not your commit count.

3. Know the neighbouring roles.

• Team lead — runs the team's day-to-day process and people topics; in some companies the same person as the tech lead.
• Engineering manager — owns people and organisation; hiring, performance, careers.
• Staff engineer — technical leadership across several teams; the tech lead is one of the Staff archetypes, scoped to one team.

4. Decide what you will stop doing. Typically: being the only reviewer, being the default implementer of hard tickets, answering every question in real time.

What to say

To your manager in week one:

"I'd like us to agree what I own and what you own, so nothing falls between us. Can we fill in this table together and review it in a month?"

To the team:

"My job is to make sure we make good technical decisions and ship safely — not to make every decision. If you're blocked on a design question, bring options and a recommendation; I'll help you decide, and you'll own the result."

Trade-offs

• Hands-on vs hands-off. A tech lead who stops coding loses context and credibility; one who codes like before becomes a bottleneck. Aim for code that is on the critical path to learning, not on the critical path to delivery.
• Combined tech lead and team lead. Common in small teams. It works when the person has protected time for people topics; it fails when both jobs are done at 50%.
• Written scope can feel bureaucratic. Keep it to one table and review it quarterly.

Signals it's working

• Pull-request review time falls, and more than one person approves most changes.
• Team members present and defend designs in reviews, not only the lead.
• The reliability and tech-debt backlog has an owner and moves.
• In 1:1s, engineers describe decisions they made, not decisions made for them.

Key points

• A tech lead guides the approach and execution of a team — they are not the team's best individual contributor with more hours.
• Write the split of responsibilities with your manager and product manager; review it quarterly.
• Measure yourself by the team's outcomes: throughput, quality, decisions made well by others.
• Decide explicitly what you will stop doing.