To Be An Excellent Tech Lead

Before I became a Tech Lead, I had already seen a number of great Tech Leads in action and had some ideas about how I would do the job, deal with customers, plan for and solve problems, and so on.

I've slowly learned what makes a good tech lead, so I'm writing this blog now while I'm still motivated, so I don't get lost later.

What is a Tech Lead?

It is crucial to define the function of a good tech lead (hence referred to as TL).

It is important to remember that the TL is an essential member of a team, and that in the particular setting of Thoughtworks, his or her duties differ differently from those in the outside world.

If you compare a project to a war, the TL is more like the captain of the assault team on the front lines than the person strategizing from a thousand miles away.

Being a skilled shooter is only the beginning; he must also be able to devise strategies to penetrate opposing defenses with little harm to his team. He is the one who has the most in-depth knowledge of his group, has the ability to influence others to act appropriately, and has the ability to guide a team member's development into a "Special Forces" soldier. A stronger TL may even be able to "get into the enemy" and change an adversary into an ally.

The argument is straightforward: TL is not a Manager. He should not be a manager; instead, he should be more of a leader, coordinator, nurturer, and backer

Why Teams Need Tech Lead

The TL offers the most tangible glimpse into the team's technical prowess from the outside. The client's first impression of the team and how the client sees the team are mostly based on the TL's skills.

TW has always been in favor of self-organizing teams, but we still need team members to know what the different practices are for and when to use them.

Because each team member has a unique point of view and set of skills, it is important for one person to take on the role of TL and coordinate and direct the team to make it as effective as possible.

A good TL knows how to delegate, and this process is an excellent opportunity for team members to grow.

Qualities of a good Tech Lead

Being a good TL takes a lot of good qualities and is, in my opinion, a really difficult task.

Convincing

First and foremost, as TL, you must at least persuade the group; otherwise, it will be challenging for them to truly engage with you. It's clear that it's a bad approach to exert power, and programmers are bound by some rules.

The laws of the "jungle" of programmers are straightforward: if your skill is better than mine, I will obey you. The main idea is to give the impression that you are a trustworthy person.

For instance, some teams already have a specialist in a specific domain, and the TL's skills in this domain may not be as good as those of his colleague. However, if the TL is able to remove the noise and provide him with enough space to do his work, he will at least be happy to collaborate with this TL on the project.

Additionally, there are TLs who excel in a specific domain, whether it be solving challenging internal problems or showcasing the team's technical prowess to others. The team will naturally put their trust in these individuals.

Another law in the programmer's world is.

Shut up and show me your code.

In any case, please make an effort to stay with the team and avoid leaving while writing code. This is a great chance to show what you can do, but the team thinks that you can't do the task no matter how well you explain it.

Coordination and communication

I have seen that the majority of people do not want to be TLs for this specific reason.

A TL must strike the right balance between the client and the team so that the client approves of the team without overtaxing it. This includes talking technical solutions through with clients, offering technical input to the business side as needed, and discussing technical solutions with clients.

Internally, you must maintain regular contact with non-technical colleges, providing them with timely technical advice to help them prioritize tasks and clear backlogs. You also need to coordinate resources to address delivery bottlenecks as necessary.

The project's CFR management, if we are meeting the client's goals, whether the project is unstable, what should be done for subsequent staffing, etc. are all things that need to be considered holistically as you identify and manage risks in delivery.

The aggravating part is that I've only highlighted a few of these things, and TL spends a lot of time working on these "chores" that everyone refers to. Even worse, most of these things will take place in meetings where we will have to deal with real people and real concerns.

It completely contradicts the original reason we started writing code while we were in college:

** I'm not good with people, but I'm quite happy writing code, so I chose to be a programmer**.

Most programmers don't like to do these things, yet they are precisely the pieces of a TL that must be finished in a correct way. The team's efficiency and the atmosphere in which everyone works depend on how successfully or poorly these things are done.

Therefore, balancing your expectations is the first thing you need to do. Once you do that, your concentration will significantly change. Second, you must prioritize tasks and manage your schedule and backlog according to your personal preferences.

Handling client relationships

This new problem needs to be talked about in a different way than coordination and communication.

Thoughtworks has a role called "Engagement Lead," although it's more of a hat than a role since TLs and BAs typically wear it on smaller projects, and TLs, BAs, and PMs typically do so on bigger, more complex projects. These split teams ultimately make up the Client Leadership Team (CLT) for the project.

The main goal of this role is to fully understand the business, technology, and organizational goals of the client before bringing Thoughtworks' unique values to the table to help the client succeed and become a close partner.

Although it's a brief declaration, it can be challenging to carry through. Many TLs have probably experienced a situation where

We insist on strong coding standards and agile development techniques to produce higher quality, but the client sees these as time wasters or even useless, whereas in our opinion, they are the only thing that matters: delivering on time.

The issue can be that the client doesn't want to take that "risk" since we don't know what they have agreed to up top, or it might be that they don't trust us yet, let alone embrace our plan, and would rather stick to their comfort zone and play by their own rules.

There is no way to summarize because these are complicated situations, but perhaps you could try some ideas below.

• Put yourself in your client's shoes and then explain how our practice can help them achieve their goal. This will show them that we are not deviating from the norm.
• Alternatively, you could agree with the client's idea initially, provide some value, and earn their trust before introducing your proposal; this may result in less resistance.
• Most importantly, since data is so persuasive in these conversations, it is ideal to have actual facts to support your own views!

Take some time for yourself

TL typically spends a great deal of effort resolving issues as they arise. But remember to schedule some alone time.Spending all of our time in the present moment puts us at risk of losing one of the characteristics of TW:

We are not just get things done; we think much more.

I've observed a variety of methods by which TLs find time for themselves. Some arrive at work early in the morning, some set aside some time after work for reflection, and still others simply block out a specific amount of time on their calendar to pursue their own interests.

We frequently discuss managing technical debt, setting priorities, using the broad picture, measuring CFR, etc. It takes some time to stand back from the situation and check to see if the train is still on the tracks; it doesn't just happen. They need your time!

You also need some time to get used to the codebase, finish some simple tasks, check to see if the code we all wrote follows the rules we set, and see if your confidence in your own ideas and skills hasn't changed.

You need a break, so slow down and give it some thought.

Talent Pyramid

Being a TL is incredibly exhausting; everything seems to be focused on me, and I feel as though I have no extra hours.

You are not a superhero, the world is still turning without you, so trust your team and delegate them.

Start by posing a few questions to yourself.

• Can you divide your team's skill pyramid into slightly stronger and slightly weaker members in 30 seconds?
• When an issue arises, are you able to quickly identify who on your team can handle it since you know what each person excels at?
• Do you understand what your teammates want to accomplish and how you can aid them?

If your teammate has a 60 on a competency scale and something requires a 70, you might decide to handle it yourself since you don't want to take the risk. However, it is clear that this is a beneficial practice for that person, and by supporting them, you can close the 10-point margin.

Perhaps you believe that you are more effective at what you do, but do you also believe that everyone has room for improvement? I've heard a lot of stories about people who took the chance to grow quickly. After a few months, they may have also become their own unique people.

Consider if you really need to do this if you frequently complain that there is too much going on. Remember that you are not a superhero and that you should believe in your team as much as your team believes in you.

While fostering team growth, you must learn to embrace risk. You can always adopt a 'trust but check' strategy by checking in on assignments at critical junctures, ensuring that progress is always under your control and that it is possible for things to alter beyond your wildest expectations.

Finally, you must understand the distinction between shifting the blame and delegation. Also, never forget that you should take responsibility for your actions.

Finally

Do you think that's the end of it?That's as far as I can take this character, constrained as I am by my own sight.

It is highly advised that you consider the various viewpoints, and perhaps you will arrive at your own understanding as well. In fact, each of the points made here could be picked out and thoroughly examined as a separate article, and there have been many excellent contributions from various colleagues within the company.

I want to thank all the TLs I have encountered over my career.