The balance you must strike as a Tech Lead
Let’s maybe start by saying that I wouldn’t pretend to know all there is to know about being a Tech Lead. While I have had good tech leads since 2007 (since 2001, if you count some of my professors), I’ve only had that responsibility as part of my job since 2015.
I have seen enough though, to be able to say that there is a scale from too technical and hands-on to too managerial and hands-off. Hands on (and off) the keyboard, that is.
So, let’s start with the obvious: you still need to code. You need to maintain the ability to jump onto the keyboard and help someone, pair, illustrate a concept, or just prototype a technical solution to some problem.
Also remember that you are leading a technical team, and the conversations and problems your team will have and discuss require tech knowledge. I have had hands-off Tech Leads and as a Software Engineer I couldn’t really respect them.
The counterpoint to that is that you can’t have features dependent on you: you’re not an individual contributor anymore. Your job is the people working in your team: enabling them to do a great job may sometimes require that you write some code, but will certainly require that you do other things such as 1:1s, promoting certain Engineering practices, resolving conflicts, improving communication, setup a process, etc. If you are needed to finish a feature, then you’re now supporting your team.
From these two points follows that you have to delegate work and empower your team to decide on your behalf. Without delegation there is no leadership; that is effectively what leading means – to guide others and to lead them into executing a vision, and idea. A team that’s empowered to decide and act, will be faster, learn more and scale better. Ultimately making your team really productive is your job.
Now, not everyone is ready to be empowered to the same degree, so you must have a high degree of empathy and be very good at reading your team’s moods. This can affect delegation, in that someone may feel uncomfortable with the responsibility of decision, but will affect many other aspects of your work as a Tech Lead.
In fact, I would say that your work as a Tech Lead is as much about human contact and human problem solving as it is about technology. So you have to be a people person. Trust, empathy, good communication and expression skills, the ability to listen and care and the acceptance that most problems, even many technical problems, are effectively people problems. That’s where your focus has to be.
You need to be able to influence the working process of your team. Perhaps prior to that, you need to know about and have an opinion on process. Remember that most of the research and literature on process, at least on the Agile side of things, was started by Software Engineers, technical people who came up with a solutions to the problem of how to deliver a product based on software.
Your team’s daily work is molded by whatever process your organization has and this is often one of the sources of discontent for Software Engineers. They will come to you with issues which you need to be able to talk about, brainstorm and solve.
The counterpoint here, is that defining a process is a collaborative effort: you don’t go at it alone and only with the problems of your tech team in your hands. And this requires some very strong listening and negotiation skills. Product teams and Design teams and Marketing teams will all have their own set of concerns and as a representative for Engineering, you need to be a partner for all these people.
Process is the set of rules and practices from which work emerges, and work doesn’t emerge only from the hands of Engineers.
You need to care about product, even if you’re working on a non-user facing product. The result of your team’s work is not code – is a product. It has a meaning and you need to be able to look beyond the code or the tech details. The vision that many Software Engineers have that “it’s just code anyways”, is not acceptable if you’re leading the team that produces code.
(In fact, let me add that this vision should not be acceptable for Software Engineers either. And in keeping a high standard here you are effectively leading by example.)
The counterpoint here is that you are not a product owner. There will still be moments when the people whose job is to lead Product will decide things you don’t agree with. Your job is still to care about the product, the product that other people have envisioned, and help build it.
Caring about something requires the ability to let it go. Our sphere of influence is building the product, caring about quality, making suggestions, prototyping new ideas – but it’s seldom to decide new features or the overall direction of Product.
It is very difficult to be complete. But if you chose to be that person leading a team, working in the intersection between Tech and People, complete is what you must strive to be.