Last year I had the privilege of becoming tech lead for the Document Checking Service team, a role I’ve very much enjoyed for the challenges it’s provided me.
One of the developers in my team asked me what the difference between a senior developer and a tech lead is, so after a bit of reflection these are some (but not all) of my thoughts on the wider subject of what being a tech lead “means”.
(This post is not prescriptive, your mileage may vary, etc)
Get out of the way
I, and I suspect a lot of developers, have a deep temptation to grab the fun pieces of work.
It is important for team morale that I don’t do this, and to make sure that work is spread around. Each member of the team should be able to contribute and no one person should be stuck doing one thing for long periods of time.
One of the most frequent questions I try to ask during my 1:1s with the team is
Is there anything in your way that I can remove?
You could describe part of the role as an “umbrella” where you prevent unnecessary distractions from impacting the team by absorbing them yourself. While I pick up some smaller stories with the amount of non-collaboration time I have, little refactorings here and there, I try my best to get out of the way and give the rest of the team however much space they need.
Build relationships (and people)
I go to a lot of cross-team catch-ups or updates. One of our closest relationships is with the Automate team in the TechOps program, as they helped us with the migration from a data-centre into AWS, and I have regular catch-ups with them.
I also try to have short 1:1s with each developer on the team once every two weeks. This is to talk about team-level stuff and I take care not to undercut the responsibilities of each person’s actual line-manager (unless that line-manager is also me, of course).
These are good venues to ask my team what things they are interested in, what their goals are, and how I as tech lead can help them build their way towards them.
For example, if someone has a particular interest in infrastructure, I would point out any infrastructure-heavy pieces of work we have coming up as opportunities. As another example, if someone feels uncomfortable doing large amounts of technical writing, this is good for me to know when we’re planning work.
As a sort-of selfish bonus, I am an extrovert and I thrive when getting to know the people on my team.
Create an environment where good software development is a natural outcome
During my career I’ve had the pleasure of talking to Woody Zuill about software development and while I am a firm advocate of collaborative programming, as a pair or larger mob, the thing that sticks with me most is this idea.
The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable
I spend a lot of my time thinking about the way the team operates. In my mind there’s a blur between technology and delivery, and I don’t think you can talk about one without talking about the other when you’re in the digital space.
In particular, what can I do to help the team deliver on its goals in the most sustainable way?
Some of the things I’ve done this year include:
- laying foundations so that pairs of developers can work autonomously, reducing the cycle time of individual pieces of work
- working with our team’s product manager to make sure that they have enough knowledge of our code to split our stories, meaning that we can parallelise work where we can
- encouraged the development of a team “service manual” as a one-stop shop for running our product, with help from GDS’ brilliant tech writer community
None of these things are sufficient on their own, and while I don’t believe anyone has reached the platonic ideal of that state which enables great software, we can always make small steps in that direction.
That feels like a very valuable thing to spend my time on.