In the Divergent Tech Lead post I talked about a number of different interpretations of what a Tech Lead means. Since the role is by no means straightforward – you may need to develop different skills depending on your current team.
In my journey I have focused a lot on gaining specialized Domain Knowledge, building up Technical expertise, working on effective Team organisation & Planning, and perhaps most importantly clear & comprehensive communication. Let’s have a closer look at what all these really mean.
Domain knowledge
Unless you have worked exclusively in one sector throughout your career you have probably crossed this line many times in the past already 🙂.
And yes it’s true some domains are conceptually easier than others. Take an online shop for example, you kinda already understand enough about products and categories that you can navigate the domain data, at least at a basic level. But how about say working on building a payment gateway or creating monitoring software for network equipment? These are a lot more specialized and require a much deeper understanding.
So is this really important or is this something that you can pick up as you go? Can your team/company support you in this journey?
The required level of expertise usually depends on the role and the amount of “bootstraping” time you (and your team/company) are willing to invest. It could very well be that you need to go through reading and training before you feel comfortable making those decisions that require a certain level of expertise.
On the other hand if there are other people in your team/company that you can easily communicate and collaborate with, this may not be a pre-requisite for your role at all, making communication skills your most critical asset.
Technical knowledge
It’s quite difficult for someone to know everything. Working in a team you may not be 100% familiar with all the technologies your team is using (imagine an interdisciplinary team which includes mobile engineers, full stack engineers, platform engineers etc).
You may not even be familiar with the entirety of your codebase, especially if you are new and joining a well established team. On top of that you may find yourself working a lot less on actual projects/code than you used to.
My personal advise here is to try and stay as close to coding and problem solving as possible.
Carry on writing code, work on technical designs, continue doing code reviews and in general make a conscious effort to stay as close to your engineering background as possible. Carve out time to practice and code as that’s the only way to really provide valuable and actionable feedback to the rest of your team.
Team organisation (impact/rituals)
Being able to help with the organization of your team will allow it to reach its full potential and this is an area where I have seen people struggle a lot when expanding from an individual contributor role to a Tech Lead role.
The two things I would mention here is being able to identify if there is something that is not working for your team and help change it for the better.
There could be a million reasons for this, for example the scheduling may not work, the team may be missing an important ritual or is having too many etc. You can relatively easily identify these areas by observing how your team works, gathering feedback by talking with people, doing group workshops and collating a combined and prioritized view of what the issues are.
What comes after that, and also the hardest part in my opinion, is actually coming up with something that works for the team. Engage your team and work together to find something that works for all of you. You can come in with ideas and recommendations of course but working together with your team to figure things out is the best way to go here.
Team planning (short term/long term)
It’s true that some of the work that we do as engineers is reactive (us responding to things that are happening) and some has to do with longer term goals and projects that we wish to complete.
It’s easy to get lost in the day to day reactive work and lose focus of your longer term goals.
This is an area that many teams struggle with as well and one that can have a big impact on a teams’ productivity. The best approach I have found is trying to balance the reactive work with the longer term planning for the team and to try to eliminate the root causes of the reactive work as much as possible.
That way your team will have more uninterrupted time to focus on longer term projects and delivering new features instead of dealing with technical debt.
Communication skills
Communication, communication, communication is one of the few key skills that apply to all types of Tech Leads in my opinion.
Being able to describe a plan, technical design or solution in a structured way creates clarity, reduces the confusion and fosters good communication within the team. I have seen the opposite happen and this usually leads to a lot of wasted time and effort, so definitely one to watch out for.
External communication can be equally important, especially when dealing with longer term plans and projects. Being able to communicate blockers and potential solutions, collaborating with other teams, identifying and communicating dependencies early can really help with the overall planning that may cross your teams’ boundaries.
This is by no means a comprehensive list of the skills that you may need to develop in any given point as a Tech lead and there are a lot more soft skills that I have found extremely useful as well, but those are probably part of a different post 😉.