Tips for being an empowering tech lead

Being a tech lead requires you to be able to wear many hats and think on your feet, making decisions quickly and confidently.

It’s a role that’s also about the people: you’re responsible for your team’s success, and that means you need to be able to understand their strengths and weaknesses, see through their eyes and help them succeed. 

This can be highly rewarding, but it also makes the role even more challenging.

In this article, we’ll look at how you can evolve from a good tech lead into a great one that empowers team members to do their best work. 

Let’s dive in!

The mantra of fail fast, fail better is a slogan that’s become popular among Silicon Valley’s start-ups, and from there, it spread across the tech industry.

Some big companies even use this concept as an internal motto, with Facebook with their “Move fast and break things” being the most famous example. 

The idea behind this philosophy is to encourage employees to make mistakes while developing new products or services, without beating themselves up about it too much.

The idea is to prevent developers from feeling defeated as soon as they face an obstacle. Instead, they should adopt a growth mindset and view mistakes as a learning experience.

That sounds great in theory, but in practice, employees are often so afraid of failure that this fear has negative effects on both individuals and organizations.

There are many reasons why people don’t want to fail: they don’t want to be seen as incompetent by their peers or superiors, they might think they’ll lose their job or get downgraded, or they simply don’t want to let other people down by being unable to complete a task successfully.

Whatever the reason may be, the truth is that if they feel psychologically unsafe, they simply won’t feel comfortable enough to take risks or make mistakes.

As you can see in the picture, the fear of admitting mistakes leads to shifting the blame, reluctance to share opinions, and eventually to the common knowledge effect—i.e., decisions being made based on the information available to most members, ignoring dissenting or novel insights held by the minority, regardless of accuracy or relevance.

On the other hand, psychological safety allows people to learn from failure and openly share thoughts and ideas. 

The bottom line is that if you want your team members to feel safe enough to take risks and try new things, then you as a team lead need to give them some kind of assurance that failure won’t have negative consequences for them personally.

For example, if team members make a mistake and it causes a problem for the company, it’s important that you let them know that there are no hard feelings about what happened—and that it’s alright if they try again later (or try something different).

That’s exactly what Zayd Tolentino, chief technology officer at Singlife Philippines, recommends based on his experience working at Telco. 

According to his own words, at Telco, failure wasn’t “just alright, but encouraged”, which eventually helped him grow, advance in his career, and coin his own version of the fail fast, fail often motto: “It’s better to ask for forgiveness than for permission.”

To sum up, mistakes are a natural part of the learning curve. 

Convince your developers of this, and they’ll become better at their craft and pick up new skills faster. 

And as a result, you’ll become a tech leader that empowers the team to do their best work.

In addition to promoting professional growth, psychological safety also breeds innovation.

A team of researchers at Google confirmed this with their project Aristotle, whose aim was to find the secret to building highly successful teams. 

Because they studied teams, they named the project after the famous Greek philosopher who said that the sum was greater than its parts.

It was after analyzing four years of data from 180 teams that they discovered that psychological safety was the only factor distinguishing innovative teams from non-innovative ones.

Their conclusion was that, when teams have psychological safety, the members are more likely to bring up suggestions for improvement and engage in brainstorming, leading to productive discussions.

So what’s the key to building a psychologically safe environment? 

Duena Blomstrom, a co-founder and CEO of PeopleNotTech, believes that, among several important factors, the most important one is a strong relationship between the leader and the employee.

Blomstrom tells us that the team which feels psychological safety is one where everyone can bring their entire selves to work.

Employees need to trust that there will be no repercussions for being authentic.

On the other hand, she thinks that tech leads should also show vulnerability by admitting when they’ve failed, without trying to gloss over their mistakes.

Thus if you want to empower your developers and encourage innovative thinking, create a culture where everyone can speak up, and everyone’s ideas are valued and taken into consideration.

That’s even more important considering that studies show that 50% of employees keep quiet at work, meaning that a lot of potential for innovation is lost.

Therefore, encourage your developers to suggest ideas and, most importantly, back their decisions.

This sort of empowerment is incredibly useful in day-to-day work because it helps team members feel more confident, and more comfortable with making suggestions.

This can sometimes lead to better solutions and ultimately have a positive impact on the final product or application.

Trusting your team members, and giving them the autonomy to make decisions and create solutions on their own, is critical for a successful tech team.

You need to be willing to tell them what you want from them and let them figure out how to do it best.

If you’re not showing them trust, your developers will be less productive, and most likely not nearly as good as they would be if given the opportunity to do things their own way.

Or, as Manuel Garcia phrased it on Twitter, you should be a gate opener, not a gatekeeper.

When you’re not guarding the gates by insisting on things being done your way, but rather opening them by empowering your team to do things the way they see fit, you’ll find that your employees will start to feel more confident in their roles and responsibilities. 

Software developer Tash Postolovski discusses that in her article on Commenter, shown below, where she lists some common indicators of unnecessary gatekeeping.

As a tech lead, you want to make sure that your team members feel motivated, productive, and respected.

The last thing you want to do is create a work environment where they feel like they’re being micromanaged or disempowered.

Micromanagement can negatively affect employee morale to such a great extent that employees often even consider changing jobs because of it.

One way to make sure this doesn’t happen is by giving developers as much autonomy in their work as possible, while still keeping them accountable for the work they’re doing and the progress they’re making.

This way, they won’t feel like they’re being micromanaged because they’ll have control over their own work, while you won’t feel overwhelmed by constantly checking up on them. 

Joao Melo, a software developer with a decade’s worth of experience leading tech teams, thinks that one way to drop the reins is to enable peer code reviews, as it can be an excellent opportunity for developers to look at another developer’s code and learn from the experience.

He suggests that in the beginning, tech leads should participate in code review sessions. 

After a few sprints, they should shift responsibility towards the team and intervene only in the more complex tasks.

However, that might not be easy at first, but if you stop yourself from taking over tasks that they would perfectly be able to tackle on their own, they’ll grow in confidence and skills.

As you can see, trusting your team members and letting them make decisions independently can go a long way in empowering them to do their best work.

The discomfort that comes with giving up control is often a small price to pay for the benefits that come out of it. And that’s something worth considering.

One of the most important steps to becoming an empowering tech lead is to understand that you shouldn’t be just a leader, but also a coach. 

In other words, you’re there to guide, support, and encourage your team.

It’s tempting to do all the things yourself when you have extensive experience gained through years of working on different projects, and it may seem easier and faster to do everything by yourself than to delegate. 

But when you do that, you’re not giving your team a chance to grow into their roles. 

Joao Melo perfectly describes this situation with a story from his own experience. He delegated a task to a developer who was not yet ready to take the lead, but he decided to do it anyway. 

What he’s trying to say is that when it comes to delegation, at some point, you have to make the leap.

You may find that your developer may not yet have the background info or experience necessary to handle things in a way that makes sense to you.

However, it’s important to be open-minded about giving someone the chance to learn.

By handing your developers increasingly complex tasks, you’ll help them become more capable of taking on bigger responsibilities in the future.

However, there are some aspects of the tech lead position that are easier to delegate, while others are better to still leave under your supervision.

As you can see in the picture, when it comes to supporting and motivating your team, you shouldn’t delegate too much.

Your team looks up to you and seeks your guidance and advice. 

If you’re not there to show them the way, they’ll feel unsupported, which is not healthy for their motivation and willingness to go the extra mile. 

However, when it comes to the organization part, you should delegate about half of the assignments. 

Finally, tasks in the innovation and technical area you can almost entirely leave in the hands of your developers. After all, it’s their job! 

To sum up, if you really want to empower your team, become better at delegating. 

You’ll not only be giving your developers more opportunities to grow within the company but you’ll also be doing yourself a favor. 

When you’re no longer responsible for every aspect of the project, you’ll feel less stressed and able to focus on more important tasks.

As a team lead, you’re probably used to thinking about dependencies. 

Whether it’s another team or a client, you need to understand who relies on your team and what your team relies on to create the best possible outcome.

In software development, dependency management is especially challenging because it requires a lot of planning and coordination.

But it can also be one of the most rewarding parts of your job because it enables you to remove obstacles that are preventing your team from delivering high-quality work as efficiently as possible.

With that in mind, let’s take a look at four major types of dependencies: mandatory, discretionary, external, and internal.

As you can see in the picture, dependencies can be as obvious as the need for a client to approve of a design before it goes live, or as subtle as the way that one team’s work influences another’s.

However, to remove blockers in your team’s workflow, you should ensure that all of the pieces come together in time for launch.

Keeping in mind that 71% of companies fail to complete their projects on time, taking care of dependencies beforehand becomes even more important.

One of the best methods to handle them is to use Gantt charts or Kanban boards, as they can be an excellent way to organize a team’s workflow.

In the picture, you can see an example of a Kanban board. As you can see, it breaks down tasks into smaller, simpler ones, and then organizes them into columns.

The first column, To Do, is where tasks are placed. The next column, In Progress, is where your developers will spend most of their day.

If you manage dependencies well, in this phase, they’ll most likely be in a state of flow. They’ll be fully immersed in the project and able to accomplish most of the work quickly and efficiently.

You can also use two more columns (such as In Review and Done) to signify that the task is ready for review or finished.

On that note, it’s important to mention that Kanban isn’t just about efficiency—it also increases collaboration among team members as you can use it to help them make great contributions to the same project.

Therefore, if you want to empower your team members, managing dependencies is one small thing you can do that makes a big impact on how productive everyone is.

One of the most difficult things about being a tech lead is that you’re not only responsible for the technical implementation of your product, but you’re also in charge of its quality and usability.

In other words, you should have a product mindset.

But what exactly is a product mindset and how does it differ from the more traditional project-oriented approach?

According to TechTarget, in a product mindset, the customers (or users) are at the center of the software development process, and their needs guide every decision.

On the other hand, project thinking is more rigid about sticking to business requirements, project documentation, deadlines, and budget.

This idea of starting with the product can seem counterintuitive to developers, who are used to diving straight into implementation and finding solutions there.

But this approach can lead you and your team down the wrong path. 

You might implement all kinds of features, but if they’re not valuable to your users, then you won’t have a successful product.

Therefore, as a tech lead, you need to be able to walk the fine line between building what your developers want to build and building what your users want.

Again according to TechTarget, there are six good practices to do that, and we’ll address just a few to give you a better picture. 

For example, you should give your developers clear responsibilities that align with a product mindset, and seek regular reports on the relevant metrics that focus on the product and its value to the end user.

For instance, it’s essential to track the user adoption and retention rate for new products or features so you can adjust them accordingly. 

You can also use these metrics to compare the product against internal benchmarks or against competitors’ products. 

Next, when it comes to designing products, the end user should play a huge role in the process.

The goal is always to design with the user in mind, which means creating something that solves a real problem.

And finally, the old saying goes that even if you put lipstick on a pig, it’s still a pig.

The same is true for software development—process fixes aren’t enough to change the environment in your team. 

A product mindset means that your entire team should focus on results instead of processes. 

And that’s something that can only come as a result of adopting a different, product-oriented approach.

The key to being an empowering tech lead is that you need to build good relationships with your team, and then trust them to make their own decisions.

The more you encourage your team members to take on their own responsibilities and challenges, and the more you give them freedom of decision-making, the more they’ll value you as the leader.

In this article, we laid out a few best tips on how to inspire your team members.

We hope that you’ll find these suggestions helpful to you as you embark on your journey of becoming a tech lead that’s truly capable of empowering your team members.