5 skills needed to be a successful tech lead

Being a tech lead is challenging—being a successful one is even harder.

Consider the responsibilities that the tech lead has. 

A tech lead is, in most cases, an experienced developer who still handles technical tasks in the team but also has additional tasks of managerial nature.

Therefore, they’re not only responsible for pulling their weight as a developer but also for helping the others, delegating, keeping an eye on the quality of the code, mentoring, resolving issues… 

The list goes on.

To do all that successfully, you need some skills. What are they, and how to improve them? 

Keep reading, and you’ll find out.

Trust is one of the key elements in successfully leading a team of developers. A lot depends on trust between a tech lead and the developers, and you should do what it takes to establish it.

Let’s start with engagement. Engaged employees are more productive and less likely to look for another job, so having developers engaged in their work is undoubtedly valuable.

And engagement is tightly connected to trust. According to data from Gallup, engaged employees are those who trust their leaders.

Therefore, it’s safe to say that if you build trust with your team as a tech lead, you’ll boost their engagement, creating a more positive working environment.

Building trust with your developers is crucial if you want them to utilize their skills fully. 

Think about it—if they don’t trust you, will they be comfortable taking the initiative, making decisions, and thinking outside the box? You probably know the answer.

In other words, trust is needed for better performance. Without it, your competitors who invested in trusting relationships can overtake you in the market. Amanda Setili puts it like this:

So, how to get your team to trust your leadership? By taking advantage of the fact that trust goes both ways. Show that you trust them by giving them more freedom.

With more autonomy, developers can be creative and work on their own terms.

Whether you allow them to use their preferred tools or programming languages, or to work remotely, the simple way is just to ask them what they want.

More autonomy is something Steve Jobs also subscribed to.

Even if that freedom brings your developer more responsibilities and challenges, they would likely be happier than if they didn’t have it.

Data from State of Developer Report 2022 indicates that. Take a look at the highlighted columns.

As you can see, 81% of developers with strong autonomy at work have a very complex job, but 87% are happy with it—more than any other group.

Therefore, if you give more work freedom to your developers to form a trusting relationship with them, there’s a very good chance that they’ll appreciate it.

Another way to show that you’re trustworthy as a tech lead is to encourage developers to come up with their own solutions and ideas.

That’s something that LinkedIn did with their InCubator program. You can learn more about it in the video below.

In a nutshell, it’s a program in which LinkedIn employees can develop an idea, form a team, and pitch it to management. If the idea is approved, the team has three months to produce it.

Of course, as a tech lead, you most likely aren’t in the position to arrange something that complex. 

However, you can use the idea behind it—trust your developers, and they will return it with great results and a lasting relationship.

As a tech lead, your responsibility is to ensure an optimized and streamlined work process that can facilitate good results from your developers.

Successful tech leads can make the best out of the situation and resources they have. 

That can mean creating well-defined processes that allow them to focus on their most important tasks, as well as enable developers to focus on theirs.

For example, here’s how Tyler Hawkins, tech lead at Adobe, organizes his time.

He creates a process that puts tasks important for developers upfront. After all, as a tech lead, a part of his job is to optimize processes for his team.

As you can notice in that quote, a tech lead’s job includes dealing with code—reviewing pull requests, offering solutions, and, some experts say, writing code itself.

As you can tell, Martin Fowler was unapologetic about it in his speech at the ReThink Conference in Dallas, where he said the line in the tweet above.

And it makes sense—a tech lead is not just a manager. They’re a sort of a hybrid between a manager and a developer. 

Therefore, both managerial and technical skills should be present for a tech lead to succeed.

Patrick Kua, tech leader, and author, goes more into detail about the amount of coding he considers a tech lead should do.

Besides getting involved in coding on a daily basis, a tech lead should consider providing their team with some helpful tools for optimizing processes.

For instance, if your developers are regularly digging through Google Drive and Slack for that file they saw a week ago or asking you the same questions over and over, you should consider having one place to store information.

A great documentation tool can help with that. 

For example, with Archbee, you can create and store documents, guides, graphs, etc., organize them, and integrate them with other tools developers use—in short, create a comprehensive knowledge base.

In addition to providing a single source of truth, a tech lead can provide their team with other valuable tools for making time-consuming tasks more manageable.

Our own product, Shake, is great for that. It’s a tool for automated bug reporting that makes the process of fixing bugs faster and easier.

How? By generating a detailed bug report with one shake of the user’s phone.

Shake automatically attaches all the information about the bug a developer needs to fix, eliminating the need for a lengthy back-and-forth between the user and the developer.

As we mentioned, a successful tech lead knows how to make the best of any situation. 

However, to optimize the work process, they also know how to make their responsibilities work in favor of the whole team.

A successful tech lead should be able to clearly communicate to their team any information relevant to the project but also use communication skills to build stronger relationships with them.

When a tech lead is skillful in communicating, that benefits the whole organization.

On the one hand, they discuss the project and its progress with upper management and other stakeholders effectively.

On the other hand, they can motivate the team to do their best and explain what’s required of them to meet their goals.

That kind of communication in all directions can facilitate better results for the whole organization. According to a study by IBM, openness is crucial to successful businesses.

When communicating with the team, it’s important to be clear about the goals and requirements.

However, that doesn’t mean that the tech lead can shout orders at developers and expect them to be engaged and motivated.

One of the more progressive approaches is to build communication around empathy. 

That’s one of the core principles of non-violent communication (NVC), an approach based on the works of Marshall Rosenberg.

You can learn more about how it fits into software development environments in the video below.

NVC is a complex and layered approach to communication, but for the tech lead needs, it contains a vital nugget of wisdom—when you show empathy to others and communicate with care, you can express your needs to them without being bossy or aggressive.

According to Olivier Koch, communication then becomes much easier.

However, you approach communication with your developers, giving them a voice is an important part of doing it successfully.

A great way to ensure that is to encourage them to give you feedback about the work process, their participation, or anything else you might consider beneficial.

There are many software tools available to do that.

For instance, MatchCraft uses SurveyMonkey to set up quarterly surveys and other surveys as needed.

As they say, they use the feedback to implement changes in their work. For example, the feedback from one survey showed that the employees would want to bring their pets to work.

Bringing pets to work shouldn’t be something that a tech lead thinks about, but the feedback about developers’ needs, goals, work progress, or general happiness should be.

Communicating about it and encouraging positive changes is something a successful tech lead should have in mind.

A strong leader should stand behind their team and support them through thick and thin. 

Celebrating successes and not pointing fingers after failures is a sign that a leader has what it takes to be successful.

The team will inevitably fail at something sooner or later. 

They will miss a deadline, a piece of code will cause a system crash, or there’ll be some other of countless possible issues that can occur when software is developed.

According to Chelsea Troy, strong tech leaders won’t rush to defend themselves and deflect the blame—they’ll take responsibility and protect their team.

On the other hand, when the team delivers great results, a tech lead shouldn’t take credit.

They should acknowledge what the team did, praise them, and give appropriate credit for the success.

That can positively impact developers’ morale and productivity, as the data cited on Officevibe indicates.

When we sum it all up, it all comes down to taking responsibility and giving credit.

A successful tech lead takes responsibility for everything that happens in their team, good or bad, but also doesn’t claim all the success and lets his or her developers enjoy the fruits of their labor.

So, if the tech lead shouldn’t blame a developer when something fails, what should they do? The good thing is to use that as an opportunity to learn.

That’s the core message of a practice known as blameless post-mortem or blameless retrospective.

As the name suggests, its purpose is to analyze what happened without passing the blame.

Below is how The Prime Directive from Norm Kerth explains it.

A blameless post-mortem became a staple after outages and incidents at New Relic.

As Christina Guida, their former Senior Site Reliability Engineer, described, they tend to hold the meeting within two days of an incident when the situation is still fresh.

The facilitator of the meeting ensures that there is no passing the blame during it. 

That’s a good opportunity for a tech lead to hone protective instincts for their developers and use the failure as a learning experience.

For that purpose, the facilitator needs to collect some information before the analysis. At New Relic, that includes:

The goal is to understand why the incident happened, whether it can be prevented in the future and whether the team can improve its response.

In addition to that, we can add that another goal is to protect your developers. 

Mistakes happen, and the trait of a true tech lead is to show that nobody should be thrown under the bus because of it.

A part of getting to know your team of developers is recognizing their strengths and weaknesses, talents, and preferences.

If a tech lead has the ability to do that, they can use that knowledge to maximize the team’s productivity, not to mention developers’ satisfaction when they can do the things they’re good at.

Recognizing talent is also important for steering your developers onto the right career path. If that sounds complicated for a single person to do, don’t worry—you don’t have to do it alone.

You can form a career path for developers by encouraging them to seek mentorship from the people you trust.

According to data by CNBC, employees with a mentor rate the opportunities their company provides them higher than employees without a mentor.

Mentorship can be an excellent way to discover talent, evolve it and make it into a career path.

Companies often have programs specifically designed for that purpose. 

For example, Zynga, a game development company, devotes many resources to mentoring employees in multiple phases of their tenure.

When it comes to software developers specifically, they get a mentor with whom they spend six months.

In that time, mentors help them develop their professional goals—in other words, to decide what they want to work on and specialize in the future.

As Michelle Del Rosario, Zynga’s Technical Director, explains, great care is put into that process.

Like you should seek help mentoring your developers, you should also give jobs and responsibilities to them as a way to assess who has the talent for what.

Delegating tasks isn’t easy. You should delegate those tasks that can show your team members’ abilities and develop their talents.

Tyler Hawkins, who we mentioned earlier, proposes using a delegation matrix to make that easier.

As you can see, he categorizes tasks by their level of complexity and frequency.

He argues that you should delegate simple and frequent tasks as much as you can, while complex and frequent tasks should be delegated carefully. 

Finally, according to him, complex and infrequent tasks can also be delegated for training purposes.

The last category is beneficial in the context of recognizing and developing talents. 

Those tasks don’t come up often, but they can show if your team member can handle something challenging, like doing a performance review or programming an important feature.

That information can help you see what abilities they possess and what role they’re suited for. As a successful tech lead, you’ll know how to use that knowledge.

As we showed throughout this article, being a successful tech lead is an accomplishment that requires multiple skills.

A tech lead can’t be successful without having the ability to build trust with their team of developers. 

They should also know how to optimize processes and be an excellent communicator.

A strong tech lead should also be humble, let their team take the deserved credit, and protect them when mistakes happen.

Successful tech leads know how to recognize talented developers and point them in the right direction.

Developing all those skills can make you the tech lead that any team would wish for.