Technical leadership is mostly subtraction

Most engineering teams do not struggle because they lack good ideas. They struggle because they have too many, and no one is removing the wrong ones.

The instinct problem

When someone becomes a technical lead, the first instinct is usually to do more. More reviews, more opinions, more presence in every channel. The transition feels like an expansion of responsibility, so it feels like it should involve an expansion of output.

It often produces the opposite. A technical lead who touches everything is a bottleneck. Their context is irreplaceable; their bandwidth is not.

The better instinct is to ask what can be removed. Which decisions do not need to be made yet? Which meetings produce alignment that a document could have provided? Which technical discussions are a proxy for a product question nobody has answered?

Subtraction is harder to see and harder to celebrate than addition. That is part of why it is underpracticed.

What actually multiplies a team

The most leveraged work a technical lead does is usually not in the commit history.

It is the conversation that prevented a three-month detour. The architecture review that caught an assumption before it became a constraint. The quiet redirection of a discussion that was about to produce a consensus everyone would regret. The decision not to escalate a conflict that would have cost two weeks and one engineer.

These interventions are invisible in retrospect because nothing happened. Good technical leadership often looks like nothing went wrong, which is not the same as nothing being done.

The engineers who are most visibly productive — shipping features, closing tickets, writing code — are not usually the ones multiplying the team. The multiplier is the person who makes everyone else’s work more coherent.

The authority trap

Technical leads tend to overinvest in technical decisions and underinvest in clarity.

The reason is structural. Technical decisions are where their expertise is legible. Code review, system design, architecture — these are domains where a senior engineer has earned credibility and feels on solid ground.

Clarity is harder. It requires surfacing the unspoken assumptions in a requirements document. It requires asking uncomfortable questions about priorities when two things that both seem important are actually in tension. It requires saying “I don’t think we have agreed on the problem yet” to a room that wants to talk about solutions.

That work is not glamorous. It does not produce visible output. But unclear direction costs more than bad technical decisions, because it compounds across every person on the team.

When to write the code

There are moments when a technical lead should absolutely write the code.

When the team is blocked on something that requires rare context. When a decision needs to be explored rather than debated. When a prototype will answer a question faster than any discussion. When the morale value of working alongside the team outweighs the opportunity cost of not multiplying it.

But these are specific moments, not the default mode. The default mode is: who is the right person to do this, and what do they need to do it well?

That question is more useful than most code reviews.

Hiring as a technical decision

The most consequential technical decisions a lead makes are usually about people.

Who joins the team changes the code that gets written. It changes the standards that are implicitly acceptable. It changes the team’s capacity to absorb complexity and make good decisions under pressure.

A team with high hiring standards that takes six months to fill a role will often outperform a team that fills the same role in six weeks with someone who is almost right. The gap compounds in the same way that technical debt does — slowly, invisibly, until it becomes undeniable.

Most teams treat hiring as an interruption to the real work. The leads who understand it as the real work tend to build different outcomes.

The output

Technical leadership is not a more senior version of software engineering. It is a different job with different leverage points and different failure modes.

The engineers who are good at it are not necessarily the ones who write the best code. They are the ones who understand what the team needs to be effective, and who are willing to provide it — whether or not it is visible, celebrated, or interesting.

The output is not commits. The output is what the team is capable of.