At one moment, in each development team, one will stand up from the rest of his team members with his ability to support others, to speak up for the interest of the team, and to be listened and followed by his peers. These individuals are soon promoted to the “Tech Lead” role and they discover on the hard way all responsibilities that come with the job. This article is for them and for all the developers that are thinking to pursue the leadership path and even for who are wondering: “What does a tech-lead do?”. In some way, this article is also for me, or for the younger me, who would have appreciated a guide on what to look for on this journey that many discover alone.
Last summer, Patrick Kua had a great talk at the LeadDev conference in London called “The constant Life of Tech Lead”. In it, there are lots of interesting ideas, but the one that made me understood better the tech lead role is the three key areas of responsibilities: People, Tech and System. I will use the same framework to describe my view on this role and in this post we will focus on the initial area:
I think the first step towards understanding this role starts with supporting and collaborating with other developers. Most of the time is done through “pair programming.” By definition, it requires working with another person, sharing knowledge, and reaching a common goal. Usually, good developers will share their view, speak up when needed and focus the team on solutions and not on problems. In the end, they will earn the trust and respect of all parties.
Multiple Leadership Styles
When I was a senior developer, without even knowing, I was using the coach leadership style, and I believe this is one of the most commonly used forms. As you become senior in one domain, I think the instinct to share your knowledge and to help others comes naturally. You will want others to avoid the mistakes you have done, or to teach good practices that made you reach your goals. However, this is just one of the ways to lead. Your team will evolve, your team members will change, and the balance of skills, knowledge, and talent will shift.
Therefore you have to know how to adapt. The book “Primal Leadership” [Full Disclosure: I receive compensation if you purchase through this link.] describes multiple styles, each with their advantages and disadvantages (e.g. democratic, coach, commanding, pace-setting etc). Every leader has to build a “repertoire” / “a toolbox” of styles, and know when to use them depending on context or environment. Thinking that one method is enough is naive, and it will lead to a suboptimal performance from your team.
In the early days of my career, I was promoted to the team lead role, based on my technical and coaching skills and I was not aware of the importance of feedback. Now, I consider it one of the most critical aspects of our role.
Please don’t think that feedback is only about negative things. It is about behavior that you observed in others, that you would like to change or to encourage. Positive feedback enforces behavior, whereas constructive feedback helps the other party to understand that actions need to be taken to improve or resolve a possible conflict. Feedback must be specific, based on facts and observations and not on emotions or personal biases.
Besides that, I think everyone wants to know when he is doing something right or if there is something that he can improve. Unfortunately, I observed so many times where feedback was neglected, and eventually, it had severe consequences on the individual or on the team. The inability of some leads to give honest feedback creates a gap between the internal and the external image of the individual and usually this is the root of all frustrations and conflicts. It is not easy to give feedback, that is why it must be practiced and practiced until it becomes natural.
Here are some interesting resources that explain in more details the importance of feedback and how to do it right:
Leads are responsible for managing into three directions. His team, his peers, and his boss or external stakeholders.
The first one, the team, is one of the most obvious. You still need to adjust that your team members, your peers, are now your directs, but there is nothing that surprising. However, you should not underestimate your new responsibility towards your team. You have to understand that their results and their happiness relies a lot on your hands. You are not anymore the “rockstar” of the team, the guy who can code like there is no tomorrow. Your effect has to be converted from an additive one to a multiplicative one and your results will be evaluated from the results of your entire team.
Take a step back and focus on your directs, observe them, put yourself in their shoes, understand what motivates or discourages them and discover their talents. It is easy to see skills or knowledge, but the critical elements that make everyone unique are their talents. Use them, focus on their strengths and not on their weaknesses and then you will have your team performing like a “nicely oiled machine”.
The second direction is to understand your new peers, e.g., PMs, other tech-leads or specialists from external departments. Business and tech must always be aligned, even if sometimes these forces pull in different directions. You must be able to negotiate, to understand their perspective and to know how to find a middle ground. Learn all business KPIs, like LTV, ROA, Reg2Pay, etc. since they will allow you to speak the same language and translate the impact of technical projects into business terms.
The third direction is your boss or even upper management. The first lesson that I learned is that they hate surprises and you should always keep them in the loop and often ask for feedback if everything is clear or if they have any early concerns. Even if it is something small, it is better that you dig deep and find out the reason behind. It may prevent that the whole team puts a lot effort and time only to discover at the end that it does not match the strategic goals. Find out their expectations and make sure that you are always aligned.
In the next blog post we will focus on the tech area, we will discuss about iteration times, automation and about resourceful team members. Until then here is the “tl;dr” version of this post:
Have at least three leadership styles that you can use depending on team or situation
Use feedback to improve or motivate your team members
Pull back from coding and discover the hidden talents of each team members
Learn to manage expectations and to negotiate solutions that benefits both parties