Three Common Mistakes of the First Time Tech Lead

Don't miss the author's earlier post on the 5 Tips for Being an Effective Tech Lead.

The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.

In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.

1. Coding Full-Time

A first time Tech Lead will miss writing code. In fact, it is easy for them to assume that they need to demonstrate their leadership by writing code all the time. Although effective Tech Leads need to spend some time writing, reading and reviewing code, other responsibilities are left unfulfilled when they spend too much time writing code, - such as creating a technical vision and ensuring that the team understands key system quality attributes.

A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.

The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.

2. Making all the Technical Decisions

A first time Tech Lead may sometimes be the most experienced developer on the team, or feel the pressure to make all the technical decisions to demonstrate their authority or influence. When a Tech Lead is making all the technical decisions, they become a bottleneck in the team and the team cannot progress when the Tech Lead is not around. Other team members might feel demotivated when the Tech Lead makes all the important decisions, because their contributions are overruled and this could lead to resentment.

The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:

• Only delegating - A Tech Lead gives the decision to someone else without any other interaction
• Offering advice - A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
• Inquiring - A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
• Building consensus - They bring all team members together to find a solution that everyone is happy with
• Consulting with the team - They invite opinions from team members, synthesise the information, but ultimately make the final decision
• Being autocratic - They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.

3. Forgetting about Cultivating Team Culture

A team is a group of people working together towards the same goal. The first time Tech Lead might mistakenly see their role leading on all the technical aspects and forget about how the team works together. Although this responsibility may be shared with other roles such as the Team Lead or Project Manager, a Tech Lead must also shepherd the team to move in the same technical direction.

It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.

The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.

Conclusion

The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.

Find out more about the experiences of other Tech Leads in Patrick's book 'Talking with Tech Leads'. You can download a free sample of the book here.​