Tech lead: an introduction

As I start handing over my responsibilities at Hypothesis before I leave at the end of the month, Andrew suggested I try and write about the role of a “tech lead.” This is the first of a handful posts about the role and some of the inherent tensions that I find useful when thinking about my responsibilities as a tech lead.

I hope that some of what follows may be useful to the wonderful team I’ve been lucky enough to work with for the past few years, and perhaps to others.

To start, then, an introduction. What is a tech lead? There are at least as many answers to this question as there are people in the role, but this is mine:

As a tech lead, you are responsible for guiding and supporting your team on its journey to making good decisions and working effectively in service of the organisation’s needs.

I’ve tried to pick my words carefully:

I can’t say that this style of leadership will work well in all teams at all times. Different companies and different teams will have different needs. In particular, there may be times in highly dysfunctional teams when a more authoritarian approach is better and kinder.

What I have learned is 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 to 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.

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