Poyters
Published on

What is a good leader?

Authors

Updated at 6/28/2024

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 feel angry, sad and so on. Finally their productivicy can slip rapidly.

I've seen many situations where 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 risk showing 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.


Feedback loops

As an ordinary programmer, I've often heard comments like, "Didn't I mention? You've been praised a lot since the project finished!".

No, I didn't know, and here's why: there were no feedback loops. I've noticed that some Tech/Team Leads don't prioritize feedback. They attend meetings with their bosses but don't relay the positive (or occasionally negative) feedback to the team responsible for the work. This lack of communication creates a significant disconnect between leadership and the team.

You can imagine how frustrating it is for your team when they find out that you haven't been sharing the good news with them.

For a team to remain motivated and aligned, it’s crucial that they receive timely and constructive feedback. Positive feedback, in particular, is a powerful motivator. It reinforces good practices and boosts morale, showing the team that their hard work is recognized and appreciated. When this feedback doesn't reach the team, it can lead to feelings of being undervalued and ignored.

Moreover, a lack of feedback can also hinder the team’s growth and improvement. Constructive criticism is essential for identifying areas that need development and for fostering a culture of continuous improvement.

Therefore, it’s imperative for Tech/Team Leads to ensure that feedback flows smoothly and consistently to the team. This means actively listening to what is discussed in higher-level meetings and making a concerted effort to communicate those points back to the team. Regular updates, acknowledgments of achievements, and constructive critiques should be an integral part of team management.


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 treated equally 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 equally challenging/relaxing tasks.
  • 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 spare 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 truly necessary. Remember, you are there for your team. You need to lead them, not work alone and leave the programmers without any care.

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 things 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 follows suit. A leader should always remain calm and avoid showing negative emotions, as these can significantly impact the team’s morale and performance.

When people are tired and stressed, disagreements on the right course of action are common. By staying calm, being constructive, and avoiding blame, you can set a positive example and encourage others to do the same. Maintaining composure is crucial, especially as deadlines approach, to prevent panic and ensure smooth progress.


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 become 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


Additional resources