Tech lead: writing code ⟷ not writing code

This is part of a short series on being a tech lead, and about some of the tensions inherent in the role.

In the introductory post, I wrote that:

…the tech lead role is one which frequently involves tensions between different ways of working: writing code vs. not writing code, making all the decisions vs. making none of the decisions, and so on. In the posts that follow this one, I’ll examine some of these and try and explain why I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.

The two extremes, in this case, are:

Keep your hands dirty: spend all of your time working directly alongside your team with the code.


White gloves: never write or review code. Focus instead on higher-level design, architecture issues, or business-facing work.

A lead who spends all of their time working just like their team is not performing a meaningfully distinct role. In a team of very experienced engineers this may not be a problem: they may all be capable of holding the long-term business and technical goals in their heads even as they work on details. Or perhaps they are mature enough that they can effectively divide their time between these activities. This is rare.

Even in very experienced teams, having a designated lead (perhaps as a rotating role) can help reduce the coordination costs needed to get several people’s input on architectural and design questions.

If you are more experienced than your team, your goal should usually be to share that experience by guiding and supporting your team rather than using your experience directly in execution. It will be tempting to take the more challenging work for yourself: you’ll do a better job, faster. But if you never let the team learn how to handle this more challenging work, then they will never develop the skills they need to do it without you. This will create difficult problems for you as the business grows and you are inevitably unable to take on every challenge yourself.

The other extreme – a lead who takes an “ivory tower architect” approach – can erode trust within the team. While as a lead you will not and should not make every decision (see the next post in this series), you will need to make some. The confidence your team has in those decisions depends on the respect they have for you and your decision-making abilities. It is more difficult for the team to believe that you have made a good decision if they don’t see you facing the same problems that they do on a day-to-day basis.

Perception is as important as reality here. Perhaps you don’t need to be immersed in the gritty details of the code to make good decisions. It is likely, however, that at least some of your team feel that you do. If those people see you acting as facilitator and arbiter without a first-hand understanding of their experience, they will conclude that your decisions are arbitrary.

If you have feedback on this post, please contact me on Twitter.