Recently, I've been in charge of Growth at Whitesmith. For the last months I can pretty much resume everything to talking with everyone. Not only it will give you insights where you should go, but it will also help your team to solve their pains and frustrations and they will naturally grow and follow your lead.
So, a few (sorry, not that few) notes:
* Too much information around
You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.
* Listen your team and know their pains
More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.
* Delegate and communicate
Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)
* Iterate fast
Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.
* Are we engineers, or are we humans? (terrible pun with The Killers song)
Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.
* Align expectations
Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.
* Growth aka learning, enineering manager, space for your team to improve
Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.
Sorry for the long post. A lot of things coming to my mind atm. Feel free to reach out and disagree. That's actually what I do as a tech lead with my team. Also, I've been told the book "The Phoenix Project" is a really nice read for tech leads.
So, a few (sorry, not that few) notes:
* Too much information around You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.
* Listen your team and know their pains More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.
* Delegate and communicate Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)
* Iterate fast Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.
* Are we engineers, or are we humans? (terrible pun with The Killers song) Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.
* Align expectations Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.
* Growth aka learning, enineering manager, space for your team to improve Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.
Sorry for the long post. A lot of things coming to my mind atm. Feel free to reach out and disagree. That's actually what I do as a tech lead with my team. Also, I've been told the book "The Phoenix Project" is a really nice read for tech leads.
All the best!