The tech lead role is one of the most misunderstood positions in engineering. It’s not a title, it’s a set of responsibilities. It’s not a promotion, it’s a lateral move into a fundamentally different kind of work. And it’s where most engineers first discover whether they enjoy leadership, or whether they’d rather stay deep in the code.

I’ve been a tech lead multiple times across my career, and I still think it’s the hardest role in engineering. Not because the problems are the most complex technically, but because you’re pulled in three directions simultaneously and nobody tells you how to balance them.

The Three Hats

Camille Fournier breaks the tech lead role into three distinct responsibilities, and the framing clicked for me immediately when I first read it:

Systems architect and business analyst. You’re the person who understands both the technical landscape and the business context well enough to make sound architectural decisions. You need to translate business requirements into technical approaches and explain technical constraints in business terms. This is the hat most engineers expect to wear, and it’s the one that feels most natural.

Project planner. You’re responsible for breaking down work, identifying unknowns, managing timelines, and pushing through the messy middle of a project where nothing goes according to plan. This is the hat most engineers don’t expect and don’t enjoy. It involves spreadsheets, status updates, dependency tracking, and the deeply unglamorous work of making sure things actually get done.

Software developer and team leader. You’re still writing code, but you’re also mentoring, unblocking, reviewing, and setting technical direction for the team. This is where the tension lives, because every hour you spend leading is an hour you’re not spending coding, and vice versa.

The thing nobody tells you is that you can’t wear all three hats equally well at the same time. On any given week, one will dominate, and the others will suffer. The skill is in knowing which one needs your attention most right now, and being comfortable with the others being slightly neglected.

Influencing Without Authority

This is, in my experience, the single hardest skill a tech lead needs to develop. You’re responsible for technical direction, but you often don’t have formal authority over the people doing the work. They don’t report to you. You can’t tell them what to do, you have to convince them.

This means your influence comes from credibility, not position. It comes from having good ideas and explaining them well. It comes from listening to other people’s ideas and genuinely incorporating them. It comes from being right often enough that people trust your judgement, and being gracious enough when you’re wrong that people aren’t afraid to disagree with you.

What I found interesting when I dug into this is how much it mirrors the research on psychological safety. A tech lead who shuts down dissent, even unintentionally, through force of personality or technical authority, creates a team that stops pushing back. And a team that stops pushing back makes worse decisions, because the tech lead doesn’t have all the information and can’t see all the angles.

The best tech leads I’ve worked with were the ones who could hold a strong technical opinion while remaining genuinely open to being wrong. That’s a harder balance than it sounds.

The Process Czar Anti-Pattern

Fournier identifies an anti-pattern that I’ve seen catch first-time tech leads over and over: the Process Czar. This is the tech lead who, faced with the chaos of coordinating a team, responds by imposing rigid processes, detailed ticket templates, mandatory status updates, strict branching strategies, elaborate review checklists.

The impulse is understandable. As engineers, we solve problems with systems. When the problem is “this team isn’t coordinating well,” the engineering instinct is to build a system for coordination. But people aren’t systems, and process imposed without buy-in creates resentment rather than alignment.

The Process Czar focuses on the mechanics of how work gets done rather than whether the right work is getting done. They optimise for predictability at the expense of autonomy, and they often don’t realise they’re doing it because the process feels productive. You’re creating documents, updating boards, running ceremonies, it looks like leadership. But if the team is spending more time on process than on the actual work, something has gone wrong.

The antidote is to start with the problem, not the process. What’s actually going wrong? Is work falling through the cracks? Are people duplicating effort? Is there a communication gap? Address the specific problem with the lightest possible intervention, and only add more structure if the light intervention doesn’t work.

The Tension That Never Resolves

After 25 years, I can tell you that the tension between staying hands-on and stepping back never fully resolves. It just changes shape.

Early in the tech lead role, the tension is about letting go of code you could write faster yourself. You watch a junior engineer take three days on something you could have done in an afternoon, and every instinct screams to just do it yourself. But if you do, they don’t learn, and you’ve just made yourself a bottleneck.

Later, the tension shifts. You’re spending so much time in planning and coordination that you start losing touch with the codebase. You review PRs but you’re not sure you’d catch a subtle architectural issue any more. You attend design discussions but your opinions feel increasingly theoretical rather than grounded in recent hands-on experience.

There’s no perfect balance. The best you can do is be intentional about where you spend your time, and honest with yourself about whether you’re staying hands-on because the team needs it or because you need it.

The Decision Point

At some point, every tech lead faces a fork: do you go deeper into management, or do you return to the technical track? Fournier describes both paths honestly, the imagined version and the reality.

The imagined management path is strategic thinking, mentoring, and shaping the future. The reality is meetings, politics, and the constant feeling that you’re not doing anything concrete. The imagined technical path is deep focus, elegant solutions, and mastery. The reality is that senior IC roles often involve just as much communication and coordination as management roles, just with a different flavour.

Neither path is better. They’re different, and they suit different people. The tech lead role is valuable precisely because it gives you a taste of both before you have to choose. Pay attention to which parts energise you and which parts drain you. That signal is more reliable than any career framework.

What I Wish I’d Known

If I could go back and tell my first-time tech lead self one thing, it would be this: your job is not to be the best engineer on the team. Your job is to make the team better than it would be without you. Sometimes that means writing code. Sometimes it means drawing architecture diagrams. Sometimes it means sitting in a room with a product manager and a designer, translating between three different mental models until everyone’s aligned.

The role is messy, it’s ambiguous, and it’s often thankless. But it’s also where you learn whether leadership is something you want to do, and that knowledge, either way, is worth the discomfort.