DEV Community

Cover image for The ambiguity around tech leading!
William Rodriguez
William Rodriguez

Posted on

The ambiguity around tech leading!

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.

The Leader part!

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.

The Tech part!

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.

About coding.

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.

The way that I'm dealing with this ambiguity

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.

Regards,

William.


Thanks to Nikola Johnny Mirkovic for sharing their work on Unsplash.

Discussion (1)

Collapse
magoolation profile image
Alexandre Santos Costa

First of all, congratulations for the article.
The good thing about sharing experiences is that it's uncontestable. There's no right or wrong, but only what you lived in your career.
It makes the discussion open on top of the subject and not a war of opinions related to a mindset.
I don't have anything to add related to leadership. Today it's evident that during my career, I had fewer leaders than bosses, which serves me as inspiration to improve my leadership skills every day.
Two points that in my experience were different are the fact that in my opinion, tech leaders are usually responsible for making proof of concepts/spikes and also share their knowledge with the team.
It's tough to manage the time to code and take care of all other responsibilities, but it's a way to continue evolving as a developer and also getting involved with the teamwork.
The second is that it's tough to separate technical management and product management. Tech Leaders and Product managers must be entirely aligned, so all nonfunctional requisites are mapped, and the priorities and expectations shared with the whole team.
I agree that the tech leader doesn't necessarily need to be involved in all code decisions, like being a bottleneck on the Code Review phase. Regularly, they must evaluate the code to get a sense of how things are going and how the team can improve its quality.
As it's the first article, I guess there is much more to come, and I'm excited to read it.
Thank you for sharing it with us.