How to be a good tech lead (in 5 minutes)
As you can probably tell by the title, this is a really high level look at how to be a good tech lead. There’s lots of nuance to many of these points, but we won’t cover that here.
What’s a tech lead?
Here at First AML a tech lead is what we call the engineers that run our internal engineering teams. They’re engineers themselves, running teams of ~4 other engineers. Together with a Product Manager they own a slice of our domain which we call a “charter”.
The core pillars of being a good tech lead are:
Keeping your people happy
Keeping your team productive
Keeping delivered value high, through being an expert in your charter
If you do those things well, you’ll be a valuable contributor to the team and company. So let’s break down the key points to each of those.
Keeping your people happy
This part of the job is particularly hard, and doesn’t come naturally to many engineers. You can easily keep an individual happy by placating them, but that might not be the best thing for the team dynamics as a whole. To do this well you have to be aware of the internal relationships between members of your team, and make sure they’re healthy.
Many people find it hard to give feedback, especially when it relates to how that person interacts with others, but that’s exactly what you need to do. If one person on your team doesn’t like working with the others, they’re likely being far less productive than they could be, and far more likely to leave the company to get away from it. You need to make each member of the team aware of how their behaviour may negatively impact others.
At an individual level, you need to make sure you’re keeping each member of the team engaged. You need to understand the ways in which they want to grow, and look out for the opportunities that can help them achieve their goals.
Keeping your team productive
In other words: process. This largely comes down to the day to day processes of how you deliver specific pieces of work. Ensure the team communicates effectively, have enough ceremonies in place to achieve their goals efficiently, but not so many that it creates waste.
Always be critical of your own processes and look for opportunities to cut waste. Keep meetings with fixed agendas, and hold the team to those.
Ensure the right conversations happen early on in work to avoid rework and waste. A few hours of talking through an approach with a more senior engineer can save weeks of effort in the short term, and months of effort in the long term.
Focus tactically but think strategically. Always be aware of how the current work fits into the larger picture for your charter and the company as a whole. Don’t cut corners that cause long term pain. Push back on work that doesn’t align with this.
Keeping delivered value high
So your team is happy and productive. Excellent. But are they working on the right thing? This is very much a shared responsibility between you and your Product Manager. It’s easy to get caught in the trap of always doing reactive work, i.e. saying yes to any suggestion that comes through the door. Avoid this.
The best path to success in this area is to be the expert in your charter’s domain. Really understand the problem space your customers are operating in, and the things they need to achieve with your software. (Note: this doesn’t mean listening to what they think your software should do. Consumers of software rarely make good suggestions.)
Look at how other software handles the same concepts. This can be both competitors and completely different software handles similar concepts for a different domain.
Together with your PM you should own this area of the business. People should come to you to ask the questions. You should have a good vision for what your area could look like over the next few years.
Once you really understand your domain, you’ll find requests for features fall into two camps:
Aligns with your understanding. These are problems you’re already planning to solve, but maybe in a different way to the suggestion. These requests may change priorities but shouldn’t shift the long term vision.
Doesn’t align with your understanding. This could suggest a hole in your knowledge and cause you to re-evaluate some things. Most likely though they’ll be dumb suggestions you can easily say no to, and an opportunity to share your better way of thinking.
So that’s it?
Obviously there’s a lot more to it than what can be written in a blog post, but if you focus on those things you’ll succeed. How to implement each of those is a far more nuanced discussion with many books dedicated to each point. Happy reading!
