This post is part of my Tech Lead Series, a collection of practical advice for engineers stepping into leadership roles.
Three weeks into my first tech lead role, my manager asked how things were going. I told her I wasn’t sure what I was supposed to be doing. She laughed, “Neither does anyone else.”
I’d spent those three weeks bouncing between writing code, reviewing PRs, sitting in planning meetings, having 1:1s with engineers and trying to figure out why the deployment pipeline kept failing on Thursdays. Nobody had given me a job description.
The role is different everywhere, defined by context rather than a career ladder document.
The Role Nobody Defines
Ask ten companies what a tech lead does and you’ll get twelve answers.
At large tech companies, the role often means “senior IC who sets technical direction.” No people management. No delivery responsibility. Just architecture, code quality, and mentoring. These companies have separate engineering managers handling the people side.
Most companies aren’t like this. They don’t have the headcount to split technical leadership from people leadership. They need someone who can do both.
At a typical mid-sized company, the tech lead is responsible for the technical direction of the team AND helping people grow AND making sure things ship. You’re in the architecture meetings and the 1:1s. You’re reviewing the RFC and coaching the junior developer. You’re debugging the production issue at 6pm and explaining to the PM why the timeline slipped.
This isn’t a failure of organisation design. It’s just how smaller teams work. You can’t specialise when there are only 30 engineers in the company.
Three Core Responsibilities
The hybrid tech lead role breaks down into three areas that overlap constantly.
Technical direction
You’re responsible for the architecture decisions that shape how the team builds software. You don’t make every decision yourself, but you make sure the team makes good ones. You set quality standards, manage technical debt on purpose rather than by accident, and know when to push back on shortcuts.
Team growth
You help engineers get better at their jobs through code reviews, pairing sessions, and 1:1 conversations. The less visible work matters too: sharing context about why decisions were made, explaining the business problem behind the ticket, connecting people with the right opportunities.
Delivery
Things need to ship. You’re the person who notices when a project is drifting, who has the difficult conversation about scope, who unblocks the team when they’re stuck. You’re not a project manager, but you’re responsible for making sure the team delivers.
These responsibilities pull against each other. Time spent on architecture is time not spent coaching. Time spent unblocking delivery is time not spent writing code. Learning to balance them is the actual job. (I’ve written before about these tensions in four pillars of engineering leadership.)
What a Tech Lead is NOT
The title confuses people, including the people who hold it.
A tech lead is not a senior developer with a new title. If you’re still spending 80% of your time writing code, you’re a senior developer. The tech lead role requires real time on the non-coding parts: mentoring, planning, communicating.
A tech lead is not a mini engineering manager. You probably have some people responsibilities, but you’re not running performance reviews or handling compensation. Your focus is technical growth and day-to-day support of your team.
A tech lead is not the person who writes all the important code. Your job is to make the team capable of writing important code. Don’t hoard the interesting problems for yourself.
The Multiplier Test
One measure for whether you’re doing the role well: is the team depending less on you each month?
Your goal is to make yourself less necessary over time. When you join a team, they might need you for every architecture decision. Six months later, they should be making good decisions without you in the room. When you start, junior engineers might need your help debugging. Later, they should be teaching others what you taught them.
This feels backwards. Don’t you want to be essential? No. Essential people are bottlenecks. If everything requires your input, the team can only move as fast as your calendar allows.
Good tech leads work themselves out of their current job so they can take on new challenges. They leave behind teams that are better than when they arrived. I’ve written about this before as doing leveraged work: efforts that multiply what teams can achieve long after you’ve moved on.
This Series
This is the first post in a series about the tech lead role. Not the version with dedicated career ladders and clear boundaries, but the version where you’re figuring it out as you go.
Future posts cover the practical challenges: working with PMs and designers, running 1:1s, balancing coding and leading, giving hard feedback. The stuff nobody tells you when you get the title.
Published on .