From developer to technical lead, without giving up deciding

Moving from developer to a team’s technical reference is almost always framed as a promotion. In practice it feels more like changing profession, and the awkward part is that nobody tells you: you still call yourself a developer, you use the same tools, and for a while you assume the job is the same with a few more meetings.

Then comes the first quarter where you wrote very little code and the team shipped more than before, and you have to redefine what counts as a productive day.

The work changes its unit of measure

As a developer, the result is what you built. As a lead, the result is what the team manages to build — and your best day can be the one where you removed an obstacle blocking three people, without touching the repository at all.

It is an uncomfortable shift, because the new unit of measure is slower and less satisfying. Code gives immediate feedback: it compiles or it doesn’t. Leadership decisions give feedback weeks later, and often ambiguously.

Delegating is not the same as giving up deciding

The most common mistake is confusing delegation with abdication. A lead who takes no position on architectural choices is not empowering the team: they are letting each person solve the same problem differently, and the bill arrives a year later, when the system is only intermittently coherent.

The useful distinction is between reversible decisions and the rest. A method name, a test’s structure, the order of parameters: reversible, and they do not need your opinion. The data model, module boundaries, the contract of a public API: hard to change afterwards — and there the decision has to be made, argued, and written down.

Delegating well means pushing every reversible decision towards whoever writes the code, and keeping only the ones that would cost too much to get wrong.

Context is the most useful thing you can distribute

Assigning a task without its context produces literal execution. Whoever receives it will do exactly what you asked, even when halfway through they discover the request made no sense — because they have no way of recognising that new information has surfaced.

Explaining why something needs doing costs a few extra minutes and changes the quality of the outcome: someone who knows the goal can notice that the chosen path does not lead there, and say so early rather than late.

It works in reverse too. Much of the information needed to decide does not come from above: it comes from the people with their hands in the code, who see before anyone else that a choice is ageing badly.

Priorities are the only real lever

A team can absorb almost anything except ambiguity about priorities. When everything is urgent, everyone independently picks what to do first, and individual choices do not add up to a plan.

Saying explicitly what comes next — and what will not be done at all — is less pleasant than saying yes to everything, but it is what lets people close things instead of keeping ten of them half-open.

What I would never delegate

Two things, from experience. The first is reviewing the decisions that touch the system’s boundaries: that is where mistakes cost most and show least. The second is the difficult conversation — about work that isn’t working, or an expectation that has drifted. If the technical lead doesn’t hold it, it either doesn’t happen or it happens badly.

Everything else, given the right context, the team does better than you. Which is exactly what should happen.