What is a good leader?

Hello! That's time for a hard post to write. I would like to share my thoughts how a good Team Leader/Tech Leader should look like. I'm writing from my perspective (experience) as a Leader and from "casual programmer" point of view.

Do not forget anyone while sending kudos!

Not mentioned people can be only angry, sad and so on. Finally they productivicy can slip rapidly.

I've seen many situations in which a successful project was followed by a meeting for a larger group of people (even the whole company), and the Leader praised only a few people, forgetting all the people behind the success. Of course! Often it can be difficult or even impossible to mention everyone by name and thank them, but in such a situation you should send kudos to the whole team (e.g. I would like to thank the team X).

Otherwise, you can only show people that you don't respect them and their work. Yes, this is how it works. I have even had situations where the Leader was able to thank me and my colleague while forgetting 3 other people and vice versa.

Not mentioned people can only be angry, sad and so on. In the end, their productivity may drop sharply.

Don't have a favourite person

You definitelly should not have any favourite person in our team and treat anyone better than other. If not, you only show your team that they are no equal, won't be treat equal and may expect management problems in the future.

• No one should be given more time to complete a task than the other.
• Everyone should be given an easier/relaxing task than the other.
• People should be selected for any initiative based on their soft and technical skills, not based on their relationship with the boss.
• Everyone should have the same chances for promotion and salary increase
• And so on...

Unfortunatelly, it's quite offen behavior with a huge impact on other people. I have seen how it can drop the morales and productivity.

A good leader doesn't do everything alone

Imagine a situation where you are an ordinary programmer, you have a technical leader who cannot help you with anything. You may ask why? It's because your leader is running out of time. He has to take care of so many things that he can't have free time for team matters. Praciticaly you work without a leader. I have seen a lot of such situations...

A good leader knows that he can't do everything by himself, can't be at every meeting, can't be involved in every initiative.

You should know very well when you are needed in a meeting, when your involvement is really necessary. Remember that you are there for your team. You need to lead them, not work alone and leave the programmers without any care.

So how should you know when you are needed? The simple answer: by feelings. A more complex answer: when you can trust your team members to handle themselves.

As a leader, you can (and should) see many things; for example: one of your developers can do both front-end and back-end work, one of them is very familiar with Docker, and so on. With this knowledge, you can select specific areas for them. If you have an application dockerization meeting, take a programmer from your team who knows Docker with you. In the second meeting, you can skip the meeting and let your guy deliver such a thing.

Do not panic!

If the leader panics, the team panics as well. A leader should always be calm and not show negative emotions because they affect your team a lot. The last thing you want when a deadline is approaching is panic on board.

Be a guard for your team

Don't hesitate when someone breaks team rules in terms of coding style, overtime, deadlines, etc.

That obvious, yeah? Not for everyone.

I've seen many situations where someone broke any team rule, such as pushing code without tests (while the project is written in TDD methodology), but that's for our happiness! Deadline is just around the corner, so is it a good time to break such a rule, yup? You might think the answer is yes, but I disagree.

This is just one way to reduce the quality of the product. One feature without testing? What is there to worry about, yes? But how to know when it is a good time to break the TDD rule? Every product release is important and we need to pack it with as many new features as possible to get new funding for our company and keep our jobs, so why right know?

Breaking any rule is dangerous because it greatly increases the possibility of breaking such a rule again in the near future. Because if we broke it once, why can't we break it again?

Let's imagine that we see a house. It is fully clean, fashionable and so on. It is our human nature to keep such a house in the best possible condition.

Now imagine a house with broken windows, holes in the walls, no doors, dusty, dirty and so on. If we already have 2 broken windows, one more doesn't make that much difference, right?

My point is that if the product is not fully operational, it is easier to break another rule.

In a project without poor performance and code quality, it is difficult to agree awful code. It's hard to stop writing tests when we have a high level of test coverage.

The same from a people perspective. If you let one member of the team be late for daily meeting, the rest of the team will start late.

Do not accept overtime

No one should be allowed to work extra hours without needing to. For example, we have a retro, during which one employee says that he has worked 12 hours a day for the past four days. You should never praise such a person for extra hours. Otherwise, you will introduce a feeling in your team that they should also take extra hours. Ultimately, employees will be overworked, without their former passion for work and with a lot of pressure.

Last words

That's all about beeing Leader. Thanks for reading! If you enjoyed it, I will be very pleased if you follow my GH account: https://github.com/RafalKostecki