Tech leads have a lot on their plate.
They are responsible for the technical side of the project the development team is creating, they have managerial tasks to keep track of, and—let’s not forget—they are still software developers who contribute to the project.
It isn’t surprising that mistakes can creep up and hold back their performance, as well as the team’s performance.
In this article, we’ll go through the most common mistakes tech leads make and how to prevent them.
Stay with us and find out more!
Table of Contents
Coding too much themselves
One of the mistakes tech leads could make is trying to replicate the code output they had when they were software developers.
The reality of a tech lead role is that there are simply too many other responsibilities to focus on besides coding.
As Patrick Kua explains, achieving a balance of coding and other tech lead responsibilities is key.
Coding too much can be detrimental to tech leads’ satisfaction and productivity in their role.
That happened to Peter Gillard-Moss, head of technology at ThoughtWorks.
He recalls that, in the first few months in the tech lead role, he became increasingly anxious because he felt like he was wasting time.
Get unreal data to fix real issues in your app & web.
And why did he feel that? Because he wasn’t coding as much as he used to. There were meetings, emails, managerial tasks, and other responsibilities that required his time.
That mistake led to another—overworking himself.
“My response was to sacrifice my personal time to make up for what I’d missed due to these distractions (as I perceived them). I quickly became overworked.”
To avoid that, you should know how much coding time you can expect as a tech lead.
Vijay Singh Khatri mentions 30-60% of total working time, Patrick Kua leans more towards 30%, and some developers think that even that is too much.
However, just because they’re not coding as much, that doesn’t mean that tech leads don’t get involved with coding in other ways.
Therefore, tech leads don’t have to worry that they’ll never see a line of code again, far from it. What they should do is learn how to delegate coding responsibilities to developers in the team.
Delegating coding can free up more of the tech lead’s time and help them achieve a better balance of responsibilities.
Besides that, it’s beneficial to other developers—they get the opportunity to hone their coding skills and have more autonomy in their work.
Take a look at the diagram below. As you can see, delegation contributes to more freedom for the team.
In other words, the more the tech lead delegates their coding tasks, the more engaged and autonomous the team is.
Another thing you can notice in the diagram is the levels of delegation, from Tell to Abdicate. You can read more about them in this article from Martin Kwee.
The point you can take from those levels is that you might not be comfortable delegating all of your coding responsibilities as a tech lead, and that’s perfectly fine—as long as you don’t make the mistake of letting coding interfere with your other responsibilities.
Not prioritizing team needs
When you’re a tech lead, your priorities shift. A tech lead isn’t assessed by the number of code commits or individual contributions to the project, so they should put that aside.
Instead, a good tech lead is someone who knows how to improve their team, maximize productivity, and, overall, make their developers better.
Therefore, team needs should be a priority for tech leads. According to Edmond Lau, it’s understandable that some of them need time to adjust to that.
Developers can’t be at their maximum efficiency if their needs aren’t met, which could be a costly mistake that affects the results and quality of the work.
One way you can put team needs first as a tech lead is to distribute your knowledge and experience by mentoring them.
By engaging that way with teammates, tech leads can help them implement best practices, efficiently solve problems, etc.—in short, help them be better at their job.
Pair programming can be a great way to mentor your developers. For instance, Kin + Carta, a global digital transformation business, often practices pair programming.
According to Donald Johnson, their technical principal, they use pair programming mostly in complex projects.
As he said, a more experienced developer can help a new developer with the ins and outs of the project, resulting in better solutions due to their collaboration.
If a tech lead takes the role of the more experienced developers, they can significantly contribute to the outcome—they can become a “force multiplier” for others, finding ways to increase their peers’ effectiveness, as Skyler Whorton puts it.
Mentoring is a great way to prioritize your team’s needs, but it’s not the only one. A tech lead can also help the team by providing tools to save time on repetitive tasks.
Shake, our own solution, is an efficient way to do that. It’s a tool for creating detailed automated bug reports.
With Shake, users can report a bug by just shaking their phones.
Shake will then create a report with all the information a developer needs to fix the bug quickly and without additional digging for data.
Putting the team in the first place is crucial for a tech lead. Only by doing that can they count on the best results developers can deliver.
Thinking they don’t have to manage people
Tech leads are usually experienced and skillful developers or software engineers. Naturally, the technical side of their role is often more in their focus.
However, their common mistake is neglecting the other side of their job.
We’re talking about managerial responsibilities. Tech leads should shape the technical side of the project, of course, but they also should lead people.
Peter Gillard-Moss, whom we’ve mentioned earlier, knows how hard it can be to adjust to the managerial side of the role.
As he admitted, the day-to-day tasks like managing, meetings, or performance reviews were something he had no idea about.
Rather than learning more about that part of the job, he resented it and focused even more on the technical side of the tech lead role—and that was a mistake.
According to Edmond Lau, whom we’ve mentioned earlier, such an attitude can lead to subpar results.
“The reality is that investing in what many write off as ‘soft skills’ gives you a significant amount of leverage over the results your team can deliver.”
To get the most out of developers, a tech lead should approach them like people—show interest, build relationships with them, and care for their needs.
For instance, Spotify did that when they launched a Heart & Soul strategy, a plan to create a safe environment and a culture of caring for mental health and emotional wellbeing.
Furthermore, during a COVID-19 pandemic, most of the employees worked remotely.
According to Adam Winer, their Head of Content Strategy, Insights and Analytics, the company was even more proactive in checking in on employees and treating them like people.
They even encouraged them to take the first week of the month to recharge from stress and not work at all if it’s not necessary.
Of course, a tech lead can’t singlehandedly implement practices like those. However, they can recognize the need to treat developers with care and compassion.
As Eugeny Kolpakov points out, not everything about a tech lead’s job is about technology.
The sooner a tech lead realizes that and starts to take managing people seriously, the happier the team will be. And a happy team is a productive team.
Not communicating effectively
Effective communication is another skill that usually isn’t on the top of the list for software developers, but if they become tech leads, it can be vital for the team’s success.
The communication between a tech lead and developers should be on point if you want to achieve great results consistently.
Consider how complex developing software is—there are so many factors and variables at play that many things can get overlooked if the communication isn’t good enough.
In fact, communication is so vital that some experts like Jeffrey Carouth put it into their definition of what a tech lead is:
To avoid the consequences of ineffective communication, a tech lead should actively encourage discussions and sharing of ideas, both between themselves and other developers and among the team members.
That kind of open communication includes pushing back and saying no to the developers when necessary.
Eryn O’Neill, Engineering Manager at Atlassian, discusses that in the video below. You can hear her opinions on advocating with developers from 18:28.
As she points out, when you as a tech lead assess that a particular proposition from a developer isn’t right, you shouldn’t be afraid of pushing back.
That kind of open communication can save a lot of time for the team in the long run.
And we can’t talk about effective communication without also touching on feedback.
When giving feedback to a developer about a project, you can follow this outline proposed by Manny Ikomi, a UX Designer at IBM iX:
- What do I think went well?
- What do I think could be improved?
- What ideas do I have?
- What questions remain for me about the project?
These questions are self-explanatory and can help you structure your feedback.
Furthermore, you can also use software tools like Leapsome to provide feedback.
It’s a convenient way to regularly communicate with your developers about their performance without holding 1:1 meetings or Zoom calls.
Whatever tools or strategies for communication you use as a tech lead, the key is to embrace the importance of that practice.
Avoiding communication can be one of the mistakes that could significantly impact the team’s performance—and not in a good way.
Not sharing the information
Another mistake a tech lead shouldn’t make is keeping relevant information to themselves because that could lead to unwanted issues in software development.
Developers need the information to be productive and make good decisions in their work—it’s hard to work well without context.
As Jeff Stephens advises, a tech lead’s responsibility is to keep their team informed.
That leads to a sense of belonging and involvement in the company. In other words, developers should know the bigger picture and what their efforts amount to.
That isn’t just an opinion. The data also confirms the importance of sharing information.
According to a study by Jones and Kelly, employees who feel out-of-the-loop are less motivated.
In the research, those employees experienced a 58% decrease in the perception of where they stand compared to others.
That’s because the brain perceives a lack of information as social rejection.
Therefore, if you want motivated and engaged developers, ensure that you provide them with as much information they want and need as possible.
If you’re looking for inspiration regarding information sharing, look no further than Front.
Transparency is a crucial part of their company culture.
All company goals are shared with employees, each department sends a monthly report of their performance, and dashboards with live results are on the walls throughout the office.
Every week there is an All Hands meeting where they discuss the company results and metrics.
Mathilde Collin, their CEO, hosts a session every other week where the employees can ask her anything.
You can watch her talk more about company culture in the video below.
In short, at Front, they think sharing information can bring them better results, and they’re not wrong.
If a tech lead holds on to important information, they can demotivate developers and make them feel like they’re not valuable to the company. You should do what it takes to prevent that.
Not recognizing good work
As we already pointed out, a tech lead isn’t a manager in the traditional sense.
But, they spend a lot of time with developers, who often look up to them as an experienced and knowledgeable colleague.
In other words, tech leads have an impact on developers. That’s why they should avoid the mistake of not acknowledging the good work of their teammates.
Personal recognition is important as it motivates employees to produce better work. That’s also what the data indicates.
A good way to celebrate good work is to hold retrospectives with your team.
You might also know them as post-mortems, but these retrospectives aren’t focused on analyzing failures like post-mortems usually are. Instead, they are designed to recognize the positives.
Jean Hsu and Edmond Lau explain them like this:
Retrospectives have five parts:
- Happiest Moments: what were your happiest moments last month?
- Big Wins: what accomplishments do we want to celebrate?
- Assessment of Progress: how are we doing relative to the plan and the goals?
- Lessons Learned: what could we have done better and how to adjust for the future?
- Gratitudes: what are we grateful for?
As Lau and Hsu say, they always leave retrospectives feeling energized and motivated.
Besides positive retrospectives, various software tools can help you recognize the good work of your teammates.
For instance, HeyTaco is a fun way to praise developers in Slack. The idea is that you thank them for their contributions with virtual tacos.
There is even a competitive side with the leaderboard that shows who got the most tacos over time.
The point isn’t what kind of virtual gift developers get, but the fact that they receive public praise, which can do wonders for motivation and engagement.
Canva, a company that made a popular graphic design platform, includes Slack praises among their practices of celebrating achievements.
They’re big on celebrations. For instance, there is a Season Opener every season, where they recognize achievements and share visions for the future.
Whether it’s something grand like a company-wide celebration or something cute but thoughtful like sending kudos on Slack, it all counts.
Recognizing good work should be among a tech lead’s priorities.
Conclusion
It isn’t a coincidence that tech leads are usually the team’s most experienced and knowledgeable developers.
With the scope of responsibilities, they should be versatile and know how to navigate different situations.
However, even the most careful tech leads can make mistakes.
Coding too much, not considering team needs, putting aside the managerial tasks, not communicating or sharing information enough, and not acknowledging good work are mistakes that can grow into real problems.
Thankfully, now you know why and how to steer clear of those mistakes to be a tech lead your team needs.