The team leader is a key figure in a team of developers. It is a difficult role, involving both technical and social skills. This is the reason why not everyone is tailored for it.
The technical competence usually is not the problem (emphasis on usually). The social skills — let’s call that leadership — are a different story. Technical skills are fundamental, but leadership is not made of code. It is what keeps teams together and motivated.
Bad leadership can compromise not only the success of the product but the team itself. It is not uncommon to see good developers leave because of a bad team leader (a.k.a. the boss). This is not to be taken lightly, and it is a topic worth exploring a bit. So, what is leadership made of?
Leadership is made of respect
Respect is a key point in leadership. A good team leader needs to be respected by developers, first of all like a professional. It is hard to give respect to someone that you consider unqualified. But as stated before, leadership is not only about technical competence. This means that a team leader should also be respected as a person. How to achieve this? The answer is easy: if you want respect, you must give respect.
Respect is a two-way road
Have you ever felt like your boss doesn’t like you? That you are not really part of the team? That everything you do is not enough or correct? That’s the kind of feeling that leads a developer to perform below their capabilities. It is also what brings a developer not to respect the boss. If I feel you don’t like me, probably in the end, I won’t like you either.
Have no bias
Developers are human beings. They have their virtues and vices, they have a life or family outside the office. A team leader should understand and respect developers, both as professionals and as people, all the same way and without bias. Personal feelings should be kept outside the office. It is hard, but a good team leader manages to do it.
Leadership is made of trust
Trust is the foundation of every relationship, and professional ones are no exception. Leadership means trusting your developers.
Your way isn’t my way
Personally, I hate when the boss tells me not only what task to do, but also how to do it in every detail. It’s even worse when they are always shoulder-surfing me, checking what I’m doing — and how I’m doing it. Eventually, I will think that the boss does not trust me. The end result is that I’m more worried about completing the task in the way my boss would like instead of doing it the best possible way (yes, the two things sometimes do not overlap).
To delegate is a win-win
This is why it is important for a team leader to give trust to developers. There is a new feature of the product to implement? Choose a couple of developers and let them handle the feature, from design to implementation to production. Check with them on the status of the work, give suggestions if it is necessary, but let them be free to handle the task.
Delegating the task shows that you trust your developers to do a good job. This lets you focus on the big picture instead of implementation details. They will appreciate it and will try to deliver the best possible work. I call this a win-win.
Leadership is made of rules
Rules are what makes society work. The same is for a team of developers. Anyone can create a set of rules and impose them on the team. Leadership is what makes the team follow the rules because they want to follow them, not because they are obliged to. This is possible only if they trust the leader to create a set of rules based on shared values (trust and respect).
Forced rules are no rules
I don’t know you, but I have hard times following rules I don’t believe in. I cannot do it just because someone imposed them on me, without explanation and without a minimum discussion. I can try to do it, but probably I will bend the ones I find wrong. If everyone on the team bends some rules, the result is that there aren’t rules anymore. Say goodbye to productivity.
Create common ground
Even if you as the team leader have the final say, discuss these rules with the whole team. In this way, there will be a common ground to work on. No more rules bending. These rules can go from coding conventions to the choice of the IDE. It may sound trivial, but it is better to point out even simple things. The team leader should set an example, and should be the first one to follow the rules.
Leadership is made of time
A team leader should value their time; it’s one of the most important things they can give to the team. Avoid unnecessary meetings and save time for your developers. Leadership is being there for a developer asking for your time.
My time is valuable like yours
I can understand that everyone is always busy. But if I ask you to talk — because I need to talk, for some valid reason — and you set up a meeting, I expect that you will attend that meeting. My time is valuable exactly like yours. If you don’t respect my time, this is bad for a couple of reasons. First, if you made me wait for nothing, you wasted my time. I could have done something useful instead. Second, I feel like I’m not worth your time.
Take some time to talk to developers
Set checkpoint meetings to discuss the status of the work. Find a time slot monthly to do a one-on-one with every member of the team, to check how things are going and understand their needs. Always be on time when you schedule a meeting. By the way, remember a simple rule:
- 5 minutes in advance is on time.
- On time is late.
- Late is unacceptable
I said it before, but I can’t repeat it enough: the team leader should always set an example.
Leadership is made of strength
Sometimes things go south. When this happens, a team leader stays strong.
When pieces start falling down…
You as the team leader should be a reference in every situation. Otherwise, when something is falling down, you will trigger a chain reaction that will make the team unable to solve the situation. In the worst case, things go wrong and your developers are blamed because you cannot handle what’s happening. If you cannot handle a difficult situation, chances are you are not suited for the role of team leader.
Don’t panic
Leadership requires the strength to be always a solid reference for the developers, even in an Armageddon-like situation. If your developers see you panicking and losing control of the situation, they will panic too. This is the last thing you want in a difficult situation. Panic doesn’t fix problems. Do yourself and your developers a favour: stay calm. Don’t panic.
Conclusion
The role of the team leader is a complex one, involving both technical and social skills. Technical competence is a must, but it is not enough to be a good team leader. There are aspects that are far more important in the creation of a productive and close-knit team.
As a final note, remember that the trick is to think about what’s best for your team. In the end, the team leader works for the developers, not the other way around.
See you! ?