9 Ways of Being an Effective Technical Lead

Shôn Ellerton, September 6, 2019
What does it take to be an effective technical lead? Here are 9 simple ways to be that person.

Anyone having been a member of a technical team working on a large or complex IT project without an effective technical lead will, no doubt, have experienced the symptoms of chaos, missed deadlines, high turnaround rate of employees and poor morale.

Selecting the right candidate to take on the position as technical lead is key to the success of projects that require a level of high technical agility across a wide spectrum of disciplines. Choosing the right technical lead does not necessarily mean choosing the most technically able. A balance of hard and soft skills along with the right personality traits to motivate and include all members of the team to work together is essential.

What qualities does an effective technical lead have? What are some of the pitfalls and tell-tale signs of when things start to go down the wrong way? Based on my own experiences within the IT world, here are my thoughts.

1. Don’t be overly technical

This, at first view, may seem counter-intuitive; however, allow me to expand on this.

We must first ask ourselves, what the purpose of the technical lead is. In simple terms, the technical lead is the ‘glue’ between those within the technical team and those within the ‘non-technical’ project-management layer. If the ‘glue’ doesn’t work, there is a high probability that the project will miss deadlines or even fail.

Now, I am not suggesting that the technical lead does not have a sound knowledge of the principal technical aspects of the project. Nothing of the kind. However, what I am suggesting is that the technical lead, or anyone for that matter, is highly unlikely to possess all the detailed technical aspects of the project. I worked in an environment with many technical individuals all specialising in one or more areas of IT whether it be artificial intelligence, website design, middleware coding, database architecture, security, and so on.

Going back to the ‘glue’ analogy, one of the primary roles the technical lead must undertake is to clearly communicate, in the most simple and effective way, up to those managing the project. It is seldom that project managers are armed with all the specific skillsets and knowledge of those working within the technical teams. We must remember that project managers also have a care of duty to ensure that other non-technical teams comprising the project are catered for. Moreover, the project manager is often the first on the ‘firing line’ should the project fail to achieve its milestones and deadlines.

It is imperative that the project manager is made aware in the clearest and most concise manner what goes on within the mystery box of the technical team. One of the most obvious signs of failure of the technical lead to communicate is when the project manager is unable to reason out any decision and, instead, simply to put complete faith and rely on the technical lead in making that decision. In a nutshell, the project manager has not clearly understood and has backed out.

 

 

2. Share the knowledge

We all start off young as kids when a special celebration, whether it be a birthday or a festive holiday, means receiving goodies and gifts. These days, I keep telling my young son that it’s more fun and satisfying to give than to receive. I haven’t won that battle yet!

In terms of our careers, it often turns out to be the same. I remember when I was in my young thirties collecting and assimilating as much knowledge as I could with absolutely no intention of sharing that knowledge. I wanted it all to myself. Come to think of it, I must have been borderline selfish and arrogant.

As we get older, we tend to want to pass on knowledge to others. We no longer feel that we need to protect the knowledge from others out of fear of becoming less valuable. Many of us have heard the saying that no one is indispensable in a business, and I agree, in most cases, this is all too true.

An effective technical lead will possess the passion of not only sharing his or her own knowledge but encourage everyone within the technical team to share their knowledge with their colleagues as well.

 

3. Encourage as many as possible to participate

Including or inviting as many as possible within the technical team to participate or be present in team meetings, demonstrations, workshops or anything related to the project is incredibly valuable. There are, of course, certain situations which this may not apply, for example, one-to-one HR-related issues. It may not be practical to invite everybody in a large technical team such as for a team greater than 12 people; however, best efforts should be made to bring in a wide spectrum within the team.

Many technical leads take the stance that it is not necessary to bring in anybody not immediately working on a given task within the team. This tactic often morphs the team into silos; something which is so frequently discussed in the business world as an impediment to the success of a project. Cross-pollinating expertise within the team is one way to prevent the rise of silos.

In case the term, silo, is new to the reader, it is when various groups of individuals within a team, project or company will work specifically in their tasks or departments without any or little knowledge of what is going on elsewhere in the wider group or business.

The need-to-know basis philosophy should only be used in the right circumstances, and frankly, with my twenty-plus years of experience in the IT and telco world, I have not come across a single occasion where it was deemed necessary to do so except that related to an HR issue. The feeling of some being excluded from knowledge within a project whilst others are included is, ultimately, damaging and can serious mar the overall relationship between the technical lead and the members of the team.

The biggest benefit of inclusion is that members within the team can learn something new and develop and expand on their technical knowledge. Moreover, input from somebody not working on a specific task given to someone else can often provide valuable input. Simply because somebody is not an expert in a chosen area does not mean that person has no knowledge of that area. It is sometimes surprising how out-of-the-box solutions can be derived in this way.

 

4. Delegate appropriately

Around the time of 2010, I was given the role of Telco/ICT leader in an engineering consultancy based in Adelaide. One of the first things that I learned very quickly in that position is to accept the fact that I was there, to guide, mentor and basically keep the team as happy and productive as possible while keeping a healthy balance sheet. I was also encouraged to delegate appropriately by observing the actions of fellow leaders in the firm. I was not there to learn everything about what everybody is doing and tell them how to do it. That is a sure-fire way to get oneself on the road to micro-management.

For new managers, or in this case, technical leads, it is sometimes hard to transition into this state of mind for fear that if one is not doing the work or have a detailed understanding of everything in the team, one is not adding value to the project. This feeling can be very demoralising and stressful; at least, it was for me, when it happened. However, once one takes stock that it is the team that really matters rather than the technical detail, one is on the right path of being an effective technical lead or any team leader.

 

 

5. Listen to the team

One of the best traits of an effective technical lead is somebody who listens to the team and is open to suggestions and ideas on how to overcome or solve a solution. No one individual can possibly know the collective knowledge of the team, unless the team comprises of an army of garden gnomes. Walking into a team meeting intent on implementing a specific solution or idea and seeking confirmation bias in the team is limiting and defeats the purpose of having the meeting in the first place.

I am not suggesting that a democracy is implemented but rather, an adoption of an open mind which may prove valuable in reasoning out decisions and making the right choices.

 

 

6. Don’t solely rely on task management tools

Many task management tools like Trello, VSTS (Visual Studio Team Services), Git, Flow and many others whose purpose is to track, automate and assign tasks to those working in the team throughout the lifecycle of a project are very useful. However, these tools are not a substitute for directly communicating with the team.

One time, I overheard a question being asked to a technical lead asking what the next task is. The answer given was short, sharp and discourteous.

‘Did you not see the new task I assigned you in VSTS?’

It is sometimes human nature for us to accept that if we create a tool or a process that we believe will be an improvement on working practices, we assume that everybody will immediately transition over to using that tool or process and then know how to effectively use it overnight.

 

 

7. Offer formal training

Which brings me conveniently on the subject of training. Many of us in the IT industry are willing to learn new subjects online and on their own time. However, just because one is willing to do so does not necessarily mean that everybody is willing to do the same. If a business is only interested in investing in the outcome of the project without investing in the people working on the project, the project is under serious risk of never being completed. The obvious sign that this is happening is when a project is experiencing the ‘revolving-door syndrome’ where new people come in, and old people go out (along with valuable IP) on a frequent basis.

Yes, formal training costs time and money, but, ultimately, this may be viewed as an action to properly invest in those in the team. A good technical lead should be a proponent of ensuring that those in the team are properly trained; not only to supply the knowledge required to undergo the task at hand, but also, to further their development and career.

 

 

8. Work smart

Technical leads are also important in setting examples to the team. Respected technical leads are often looked up to. The actions they perform throughout the day, the way they perform them and the way they treat others are often reciprocated throughout the team.

Technical leads who work diligently and use time at work smartly are heralded as being good examples to follow. Those who work excessively long hours on a regular basis with no life outside of work are usually shunned and disrespected. Once upon a time, in my earlier years, one of my managers said to me that one of the most rewarding pursuits one can do outside of work is to do something for the community, for example, volunteering, joining a not-for-profit club or conduct free coaching for others, and so on. In fact, this is one of the prerequisites of becoming an executive in that firm!

Working smart means being productive in the shortest space of time and trying, as far as humanly possible, not to take work home.

 

 

9. Be friendly and approachable

Seriously. How hard can this be? Yes, at times, one can be under stress with looming deadlines, but there is always time to be friendly and approachable with the team. I remember many a time when a member of my team would approach me and ask questions. Being an effective technical lead does mean that one needs to be adept at multi-tasking and being used to being interrupted throughout the day.

The first signs of being unapproachable and unfriendly is when a team member becomes apologetic for disturbing you and starts a question with something like,

‘I know this sounds stupid, but…’

 Or

‘…sorry, I know you’re really really busy but…’

Being friendly and approachable is one of the easiest ways to oil the machinery of teamwork and gain respect with the team.

 

 

Conclusion

Being the technical lead certainly has its challenges. Management look upon that position as being up-to-speed with the technical aspects of the project, maintaining synergy within the team working on the project and being able to communicate what happens in the project in a non-technical way to management.

Wisdom, soft skills and the passion to mentor others and share knowledge tend to develop and improve with experience and age. This is only natural. Those who have lived more years have the higher likelihood of experiencing some of the challenges of working within an IT project environment. However, this is not to exclude those who are in their younger years but to merely point out that many of the traits listed above do mature and develop with age.

On a final note, the technical lead should be full of energy, enthusiasm and drive which is vital to the lifeline of any project and this, of course, applies to all ages and experience!