This is the third post in a series, if you’re just starting the introduction is a good place to start. Check out the table of contents for all the other posts.
Knowing what a tech lead’s actual job is can be quite vague and daunting, it’s something that is hard to prepare for as a pure individual contributor. For many it will be the first technical role that involves at least partially running on a manager schedule, rather than a pure maker schedule (a great blog post on the two here). The main reason is that you’ll be having meetings with stakeholders and maybe even meetings with your squad leadership to prepare for other meetings. A pretty logical next step is to reach for the job description, your company’s definition of what a tech lead is and does. If your company doesn’t have one, that’s fine too, I’ve got you covered. A description of the role isn’t a bad place to start, but I see it more as a guiding star, a general direction to head in. You’ve already got your compass to plan your immediate next moves - your team!
Focus on what the team needs, and I don’t mean just the engineers (though it’s often a good place to start). Have a few one-on-ones (1:1s) and use this to gauge where the team is lacking or could use some guidance. This could be just about anything, things that obviously feel tech leady such as helping with a technical design or unblocking something specific, but it could also be something completely different like organizing the next social, focusing on team health or improving psychological safety.
Let these learnings lead you in the right direction, even if that means sometimes doing something that feels contrary to the “official expectations.” To stick with the guiding star analogy - to follow the star, sometimes you’ve got to go around a mountain and go a totally different direction for a while. As an engineer I’ve often regretted going into the weeds or down some technical rabbit hole, but as a tech lead I’ve almost never regretted following this instinct of what would benefit the team, even if it felt outside my remit. Even if this instinct takes a while to develop - I consider developing it a necessary part of the tech lead journey. The way I like to think about it, is that at the end of the day your job is ultimately about making those around you more effective and so you do what it takes to achieve that.
To illustrate this point I’d like to give you an example. In almost every squad I’ve been in I’ve been the person with the biggest focus on team health (not just for the engineers, everyone). That’s in none of the job descriptions I’ve read for a tech lead but it’s always paid massive dividends, and has even developed into a personal strength I can carry with me to any team I’m in. In an even more extreme example, I’ve spent months essentially being a product manager in addition to my more technical leadership (pseudo-PMing as I called it). I’m not saying it’s ideal (because yes, if you can have a PM that’s way more efficient) or that it’s what I wanted to do, but it was absolutely the right thing at the time.
In conclusion, this short post is really only making a single point: you’ll likely have a job description or have read about tech leading (ironic, you’re here right?). Don’t index too strongly on all that, your truth is your squad, so place your focus there first.
Almost as if I planned this series, this post leads on wonderfully to the next, not one, but two posts - putting the people first and identifying your personal anti-patterns.
< Clear leadership - Put people first >