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:
- “guiding and supporting” — Good leaders do not make things happen by relying on the power inherent in their position. They make things happen by providing the motivation, context, guidance and support that their team needs in order to execute effectively.
- “on its journey” — Teams evolve. Good leaders evolve with their team. A new team or a rapidly growing team may make many false starts on their path to working well together. An experienced and trusting team may need little input from a leader (and might not need a leader at all).
- “making good decisions” — Making decisions and making mistakes go hand in hand: if you attempt to build a team that doesn’t make mistakes, you will build a team that doesn’t make decisions. Your goal as a leader should be to make good decisions, as distinct from right decisions. Good decisions are made with awareness of business and technical context. Good decisions are supported by data when possible. Good decisions are made when individual ego is put to one side.
- “working effectively” — Effectively doesn’t always mean fast, especially not in a growing team. It’s important to ensure that your team is optimising its own work pattern for sustainability. Pushing people to go faster without mature efforts to identify and address what’s slowing them down will usually grind them to a halt (or burn them out) before too long.
- “in service of the organisation’s needs” — A professional is someone who doesn’t put their own desires ahead of the needs of the organisation. A team that works effectively together can find a way forward despite disagreement, because they know that paralysis and stagnation are bad for the organisation.
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.
- Read the second post: Tech lead: writing code ⟷ not writing code.
- Read the third post: Tech lead: decide everything ⟷ decide nothing.
If you have feedback on this post, please contact me on Twitter.