This is the fourth post in my series “Tech lead 101”, start with the introduction. The table of contents gives a good lay of the land.
So we’ve already established two things together. First, figure out which people lead the team as well as their responsibilies. Second, the team is your compass for what to focus on as tech lead. You’re probably starting to notice a trend, I’m very people oriented - and I believe that you should be too. The greatest impact you can possibly have is through the people you lead. Of course you need the technical skills and know-how too, and we’ll get into that I promise, but before we do that lets round off this first domain for now - to have the impact you want, you need to put the people first.
If you really want to break it down, the people matter a huge amount for two fundamental reasons. One, as mentioned above, it’s through them that the team actually moves. They write most of the code, come up with the experiences, etc. Two, the fastest way you will get awesome is with a tight feedback loop, and the people you need feedback from most are those in your team. Don’t get me wrong, those outside the team matter too, but especially in the early days your squad members are a veritable treasure trove of learnings for you. But this post isn’t about getting feedback from your team. You unlock that privilege once you do right by them.
So when I say, put the people first, what do I even mean? It really boils down to one thing - make time for them. That manifests itself in loads of different ways, but at the end of the day if you make time for the people in your team, not only will they make time for you, they will also do their best work. Let’s dive into some concrete ways to do this. Heads up, I’m now speaking mainly about the engineers on your team, but to a lesser extent the same applies to all functions.
Actively check in with everyone. This can be as simple as “Hey, how’re things going?” or as specific as a given situation might ask for. You’d be surprised how many useful things these simple questions surface. I can almost guarantee it’s through these kinds of questions that you first find out about things like dropping morale, or that workloads are too heavy (or light). This is one way to shorten the feedback loop between the individuals you work with and yourself. It shows them that you care.
Be available, you want people to know that they are your priority and there is no better way to do this than to be there when they need it. I communicate this in a few different ways. Explicitly by blocking gaps in my calendar and making sure my team know only they can schedule in them (mine are called “Coding time” and yes, I ideally also write code at that time), and generally reaffirming that if you need to move a meeting for someone in the team, you’ll always do your best. Actions speak louder than words, so make sure you actually do it too. You can continuously communicate it implicitly too, reply to questions quickly. Give thoughtful answers. Be in the room and indulge impromptu conversations. It shows them that you care.
Give specific feedback, often. It’s all too easy to not give feedback for months, and when a performance review comes around you have to wrack your brain and you write an essay. Feedback is so much more useful when it’s in the moment, when it’s most relevant. In my case this is lots of short, but frequent Slack messages. Most of them are positive feedback, “The way you brought that meeting back on track was really good, we’d not have come out with clear actions if you hadn’t done that.” Not only does this help the individual, it shows them that you care.
Review code thoughtfully (and promptly). This is probably my favorite one. There are few points as impactful as code review. Especially as the tech lead. It has countless direct benefits for you (we’ll touch on these another time) and just as many for the author. The key word here for me is “thoughtfully.” Of course you can mash that ✅ and short term your team will love you, cause you’ll be going so fast. This isn’t actually putting the people first. Good code reviews take time, so how do you put them first? Take the time. Don’t rush it, understand what you’re reading and really immerse yourself in it. You’ll give much better feedback, your team will learn from you and the sky is the limit from there. Comment on good things, as well as improvements. All this shows them that you care.
See what I did there? Hopefully repetition works. If you prioritise the people you lead, if you give them the time they deserve, it shows them that you care. Now just imagine the realm of possibilities that this unlocks.
< Team before description - Personal anti-patterns >