There are a lot of companies out there. Each one of those companies has a different set of expectations about the technical leader. Still, we know that at the end of the day, everyone, including the tech lead wants to build excellent products in a great team.
This article is my way of expressing everything that I think related to work as a tech lead over the years.
For those that don't know me, I'm an almost 40 years old developer, that had been working with software development for about 19 years. So I had the opportunity to work with many people in a few companies. Some good, few bad, outstanding leaders that had inspired me, and others that I even don't want to think/talk about it.
So I had learned by experience, observation, and falling! Right now, as I'm trying to be comfortable with the ambiguity around being a tech lead. I kind of need to put my thoughts out there and maybe I can help someone or learn from them.
To me, "leader" is a strong word. I always assume that they should be recognized and not designated. The first thing that comes to my mind is that a tech lead needs to be someone that has "leadership" skills equally as they have technical skills.
I mean, the only part regarding software development that is not different in every company is that:
To build great software, we need great people, and people need to be comfortable.
People will respond more openly to a personal passion and dedication to a project than to a nagging technical point o view.
Some companies treat the Tech Lead as a role, so they have the same person "tech leading" all the projects. I think that this is wrong. In my way of seeing, everyone should be tech lead at some point in a project.
As the tech lead is the owner of the technological vision for a specific project and the technical leader of the project team. Every team member, at some point, needs to fell the responsibility and the burden of leadership. It's not easy, and this title/role needs to be shared and can improve ownership.
Lookin only to the technical aspect o the job, the tech lead should care about how and not what. He is not a project manager. So he doesn't determine the product definition. He can't decide what goes into a project or product, it's not his call. Also, they will not hire or fired anyone.
Sure, the tech lead can talk about features, but he is not responsible for long term product decisions or directions. He should focus on the technical outputs and how the team can work better regarding technical stuff.
He should care about technical delivery, tools, languages, definitions, APIs, proof of concepts, reviews, mentoring, and other tech stuff. Also, be an advisor, a technical consultant to the PjM or PM, but never defining product features.
This is tricky. Tech leads are software engineers, sure, they like and want code, but if they are spending time with that, they probably will let something behind, and this is not ideal.
So the way that I'm seeing this over the years is that tech leads should only focus on the technical delivery as I've described above and left the code for the dev team.
They will not implement things, they are not a coder in a project. It's hard, but we need to deal with that.
First thing! I've accepted that it's not easy, sometimes I will bounce between the edges of trying to figure out what is technical counseling, what is a product vision and what is overengineering.
Some things that I tried to do (maybe this will help you):
- Reading and studying about tech leading and also leadership;
- Keeping everything as simple as possible, forget about the micro-decisions like "should we worry about if/else, inverted if ...";
- Focus on the big plan;
- Listen and understand the dev team suggestions and approaches but always confronting them with the product needs, and helping on the final decision according to the scope and deadlines;
- Get everything that could help the team to perform better, highlighting issues, flagging and anticipating product definitions, detailing features and pointing to technical approaches or just sharing my experience;
- Build a noise-proof wall between the product headaches and the dev team, so they can focus on the tasks and not on the project pains;
- Keep the team motivated;
- Giving autonomy to the team to make code related decisions that will not impact on the long term project;
- Mentoring young developers;
- Solve issues together and not as a hero, so everyone can learn by experience.
So, that is it! If you and see things differently, please share with me, I'm always open to talk, improve, and change to be better.