(Un)expected Aspects of Being a Team Leader

I know there are hundreds and hundreds of good articles about being a team leader. I found out that a lot of them are too general or not so easily applicable to software development process. In this story, I will give a quick overview of ideas that I believe are the most important.

The story of “being a team leader” in a software company may start many ways. If you are lucky enough, your manager has a concept of team leader “upbringing”, skills for it and time for you. If any of these three points are missing, then your role transition will be painful for both, you and your team. If you are curious, I’m a lifetime lucker — unfortunately not everyone has such luck as I have. Sometimes, that they simply throw you in the water and you must learn to swim. Even worse, people become team leaders even though they don’t actually want based on the poor explanation: “We need someone to do it and you are the most suitable person”. If it happens to you, you can try the new position for a while. Maybe it will suit you even if you didn’t expect it would. On the other hand, if you feel that the role is not for you, then don’t be afraid to refuse it. It is no shame at all.

OK, so now you are a new team leader. What are you going to do? The first thing is to realize: You are no longer paid for implementing a code (testing… or whatever you did). Sounds easier than it really is. Personally, I found limiting or leaving code implementation the hardest part of the change. I loved to analyze problems and I loved to turn ideas into the code.
The good news is: you can still code.
The bad news is: only if you have any time left.
Sooner or later, you will find out that there isn’t much time left for coding because people and projects need your everyday care. This logically implies that the smaller team and project you have, the more likely you have time to code. Every time you want to start coding, you should ask yourself questions like: “Do all people in my team have everything they need?” or “Does the project have everything that the team leader should take care of?”. If the answer is “no”, then reasons of this “no” will very unlikely solve themselves on their own. Coding, conversely, can be delegated to someone else in your team. On the other hand, I’m not telling that team leaders should immediately stop coding. The best way to be a good leader is to lead by example, and showing that you are a good programmer is the an easy way to build respect in the development team (and avoid ivory tower effect). I’m just saying that coding is no longer your priority number one. You may burst into tears now.

So what are you paid for then? You take care of the development process in your team (including people). When I say the process, I don’t necessarily mean written processes. These can be simple agreements like “how we develop software” that people in your company share and understand. I’m pretty sure you know the situation when someone complains about how the things work in your company (typically during a coffee break). Surprisingly these statements are often false but it isn’t because these people are stupid. It is simply because they are just missing some information. Yes, you got it right — now it is your job to tell the missing details and eliminate misunderstandings. The team leader is the bearer of the company agreements and values. You should know them, and be able to explain them, as well as defend them, if needed. If you hear some complains, be proactive, join the discussion and ask for facts. Maybe you will get some information that you can use to make your company better or you will just eliminate another misunderstanding.

The company agreements and values vary a lot and there is no magic list of good ones. Some of them can be obvious like: ”We write unit tests for every class with logic.”. Some can be trickier: ”We support that developers and testers work very closely together”. These depend mainly on the company culture, on your personality and the people you have in your team. Your manager should pass the company values to you continuously. The ones for you and your team is up to you to find out and it may take some time (your manager can help as well). What works for one team may not work for the other. To give you some examples, I will share a few values I try to follow:

• Every person should understand why he/she is doing things the way I or the company require.
• There are no walls between different roles (e.g. developer, tester, UX…), we all have the same goal and we should actively try to find ways how to help each other.
• It is highly appreciated if anyone uses part of working time for investigation of new things (if it isn’t in the last days before a release :-)).
• Any risk that anyone identifies should be communicated ASAP (e.g. this feature may take longer to implement than we thought in the first place).
• … and much more

As a team leader, you should care about your people. And I would like to point out that this also applies to your manager. Even a team leader needs support of the manager on a daily or weekly basis. Appointing someone a to this role doesn’t mean that he/she becomes suddenly enlightened. Sending him/her to trainings and courses helps, but it is simply not enough. The higher you go in the company hierarchy, the less attention is usually needed due to the seniority. However, it shouldn’t be underestimated at any management level. If you lack continuous support from your manager, you should demand it. Be proactive, initiate discussions — simply don’t expect that help will come on its own.

A good team leader is accepted by his/her colleagues. The worst managers are those who demand respect by force instead of having or building natural authority. That’s why it is easier to become a team leader if you are a good programmer (tester…) because it automatically gives you some level of respect. As mentioned earlier, you are not paid for implementing code — this also implies one more important thing to realize. You don’t have to solve all tasks on your own. Actually, you shouldn’t — now you have your team to help you. If anyone asks you for something, usually he/she wants that stuff to be done. However, it doesn’t matter who in the team does it. It takes some time before you get used to it and before you learn to delegate a work properly. Delegation usually requires monitoring, so don’t hesitate to ask for confirmation that things are going in the right direction. On the other hand, don’t forget that it is still very efficient to lead by example. If you delegate absolutely everything, you may risk losing respect as well as losing performance of your team.

To be a team leader is hard (like to finish Diablo II on the Nightmare difficulty). To be a good team leader is very hard (like to finish Diablo II on the Hell difficulty). I hope this overview gave you at least a little bit of taste of what it may about. I won’t describe all the pros and cons it brings now (that could form a separate article). However, I must admit that over the time I enjoy working at this position a lot. Hopefully, you will love it too. More descriptive articles about team leading may come in the future.

Do you have a different experience or feel something doesn’t apply to you? Feel free to tell me in the comments.