I’ve been developing software for about 10 years. I think I’m pretty good at it. And until 18 months ago, I thought that being pretty good at developing software would make me pretty good at leading a technical team.
That’s an oversimplification. I had thought about it a bit more than that. But I’d never really sat down and thought through exactly what a tech lead was actually supposed to do. It seemed kind of obvious; the tech lead is, like, the leader, right? They’re calling the shots. They design the architecture, manage the build system, divvy out the work and review the code. They’re generals who coordinate a campaign and take the plaudits for success and the blame for failure.
This is certainly how a couple of leads under which I worked early in my career saw it. I now see that they were bad role models.
I also worked on a couple of teams where there was no real lead, where the project was more chaotic and everybody just sort of chipped in what they could. and even when I was relatively inexperienced I enjoyed this a lot more.
Which is not to say that I think it’s the right way to run a complex technical project; simply that being given the opportunity to contribute proactively was much better for me individually than being spoon fed requirements with no sense of ownership.
Now, for the last couple of years, I’ve been employed by an agency who pride themselves on doing these things right. This means a lot of thought goes in to how to run a project and leads themselves get more help when they are starting out. I’ve had the opportunity to work in both a lead and supporting role and it’s been a fantastic experience from a personal development perspective. two years down the line, if I had to sum up what I’d learned, I would put it like this:
A good tech lead is not a general. He is a priest.
(Bear with me).
Some context: about 18 months ago, I did a bit of consultancy work with a client that led to my agency winning a 600K project – one of the biggest bits of new business they’d ever brought in. I felt good about the project and the work I’d done to help land it, I knew that I had the client’s confidence and I was keen to take the lead of the team that would implement the solution. I’d previously coordinated small, geographically disparate teams on smaller projects prior to joining the agency and one smallish project for the agency immediately prior to the consultancy work.
I felt I was ready to step up; my manager agreed to let me take it on, but during the first few weeks of the project I realised that my previous experience had done nothing to prepare me for something of this size and complexity.
I could write a whole post just about those first few weeks (and I probably will), but to summarise: we ramped up from 2 to 8 developers in a short space of time without really fully understanding the domain and I was struggling to find a balance between decision-making, delegation and hands on development. About 6 weeks in, I realised that I’d made a couple of bad technical decisions early in the project which we needed to reverse and, while on any other project I would simply call this refactoring, I felt under so much pressure and my confidence had taken such a hit that I couldn’t help but see these as inexcusable personal mistakes.
In reality, the project wasn’t going that badly and ultimately we delivered it on time, on budget, with a great deal of appreciation from the client, who subsequently invested several hundred thousand more with us in follow up projects.
The fact that that happened however is largely down to Harry – a more experienced lead who joined the project around about the 6 week mark and was able to steady the ship and serve as a fantastic mentor. He was also the author of a talk I’d previously attended on ‘how to be a tech lead’, where the underlying thesis had been along the lines of:
“The role of the tech lead is to make it as easy as possible for your team to be awesome”.
Working with him and seeing him embody those values was probably the best learning experience I could have had.
Now, back to my priest analogy.
Priests do far more than simply preach. They teach, they guide, they advise, they encourage parishioners and help them with daily problems. They serve as focal points for a healthy community and lead from within (and not aside from) that community, encouraging people to take control of and find meaning in their own lives. They share their vision of God and of morality; promote charity and kindness; they administer sacraments and encourage holiness; they take confession and absolve sin. Above all they help their flock to lead what good lives and lead by example themselves.
A tech lead does far more than simply code. They teach, they guide, they advise, they encourage developers and help them with daily problems. They serve as focal points for the healthy team and lead from within (and not above) that team, encouraging developers to take ownership of and gain understanding of substantial sections of the code. They share their vision of the system architecture and deployment infrastructure; promote testing and communication; they administer code reviews and encourage coding standards; they mentor and take responsibility for the wider success of the team. Above all they help their team to build the best quality product they can and lead by example themselves.
Of course, there are differences; even the best analogies break down and this wasn’t even a very good one to start with.
And of course, there are plenty of smaller, more practical tips that can help a tech lead perform well.
But if you go into a lead role with this general philosophy in mind, I think you’ll do a much better job than I did first time round.