Being a great tech lead entails a set of actions and tools that will help you coach your team successfully. In this article, our PM Diego De Sogos gives us some pieces of advice that we can put into practice.
It’s very hard to be a tech lead — you’re continuously solving problems others may have failed to solve and managing increasing amounts of ever-changing complexity.
Experience is, without a doubt, the most valuable resource. But what can you do to acquire such experience? This is not an easy task. Besides the try/try/fail/learn/repeat loop, you should look for what other leaders have learned from their own practical experiences. I’ll summarize 5 critical aspects which I have found very valuable while I have been building my own career as a tech lead over the last 20 years.
Note that these pieces of advice are not my own. I took these concepts and put them into practice while working with great leaders and by reading tons of articles, books, and internet posts about the subject (as you may be doing right now). I hope they can be useful for you, too.
Motivation matters so plan on incentives
Do not wait for your team to be frustrated or completely disinterested in their daily tasks. Plan on how to keep them motivated and do it in advance.
Most people get stuck on money as the primary source of incentive; however, most of the time, it’s time itself that matters the most. By time, I’m not referring to giving days off but finding creative ways for your team to use time for their own benefit. It could be a side or pet project or a hands-on training course about any new stuff.
Depending on each team, not all incentives work the same. The key to finding what works best is to put effort into the design of your incentives. For example, if you decided to take your team out to have some drinks at a pub, would you think about who likes alcohol? Who may see this as a waste of time (time that could have been spent with their family)?
Thinking about incentives and therefore motivation in advance allows you to tailor the different incentives to match what your team would really enjoy.
Prepare for drastic measures
When you get to work with a new team and/or project, there is usually a tendency to maintain the status quo, even when such a state is harmful for the team and the project. Breaking bad habits requires expertise and empathy from the team to show them the path. The leader is leading not because they instruct people on what they need to do but because the leader is the example to be followed.
A common status quo scenario is a team that isn’t used to working with automated unit tests. As you start working with the team, you will find a lot of resistance to these new practices, with many valid arguments and explanations about why it won’t work or can’t be done. It may not be easy, but the main challenge for unit tests is not in the code but in how people look at the code. You need to set a basic set of coding rules that foster or facilitate testing. Start by looking at big integration tests using mock services/objects and show the team the way they work, thereby generating a new habit for testing. It will take time to get used to it, but you know the benefits will be worth it in the long run.
Your team needs your expertise, not your ego
Sometimes the path to follow is pretty clear to you. You know the woods well, and you also know how to get to your destination faster, cutting corners that won’t cause any harm. However, your team may not be so ready for such a ride. What’s worse is that those woods that have looked so familiar to you may be just a part of the story, and your team may have different, safer ways to go. Although some of the decisions about what path to follow may not be the shortest in distance, it will get you there faster (and safer) based on what your team knows best.
For example, I have a lot of experience in the Java ecosystem, but my new team may know the Microsoft .NET world very well. We have to be able to recognize the pros and cons of every alternative and decide based on facts, not on our ego. It’s very important not to let our experience bias us against what would work best for the team and the product we’re building.
Patience will help you move faster
When things are not going so well, and you start working with a team that has no vision at all about what needs to be built, but all they see is a deadline to commit the new fixes and improvements, well… things will get worse.
When you start on a project that has been running for a long time, with high attrition rate and many changes in management, the team may focus on delivering it as fast as possible regardless of what they need to do or the training or support they need to have, which then produces buggy software. In that scenario, it’s also highly probable that instead of revisiting what’s wrong with a high number of bugs, the team continues adding more efforts in QA and developers fighting fires than developing cool, new features. When you find yourself in this situation, you’ll realize you spend most of the time reworking.
Instead of focusing on higher delivery rates, what your team needs is to slow down. Stop coding, invest in training, and work to improve the general quality of your product. Patience will allow you to move a lot faster.
When developers are in a hurry, things never go well, and the most important organizational processes, like mentorship and training, halt. Under this situation, bugs pile up, important regression tests are skipped, communication is affected, and developers end up burning out, thereby pushing productivity down.
Remember that happy developers tend to introduce fewer bugs and build maintainable software. In other words, time pressure and unrealistic goals go against happiness; they cause anxiety and frustration which ends up as poor code quality and a ticket to failure.
Become a leader of leaders
When you are managing a team, there will be many ways of tackling technical problems. We tech leads tend to think we have to always provide an answer to every technical decision. Also, depending on the maturity and domain expertise of your team, most of them will come to you to get the right solution and your approval.
This is not practical or realistic, because you may know how to design something, but that does not imply that there aren’t other valid and even better ways of doing it. There is nothing more valuable than the exchange of different perspectives and ways of interpreting the world.
Let your team invent their own solutions and help them reflect on the pros and cons of such solutions. You have to lead by showing the path, not providing the solution. If you’re working with smart, capable people (otherwise, they wouldn’t be working at your company!), teach them to become leaders, too.
With time, as they become more confident, the right decisions will come directly from your team instead of your own, sometimes limited, vision of the world. At that moment, everyone will benefit each other by building great quality products, and you will start doing much more with less.
To sum up
Becoming a great leader involves more listening than talking, and you need to get in-sync with your team skills and product needs. You must work to build trust and motivation and have a lot of patience throughout.
Remember that the main goal of a leader isn’t about leading but coaching the team so they will be able to lead by themselves and build greater products by combining their own unique points of view.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
