image from Successful Team Leader: How to get to know and lead a programming team?

Successful Team Leader: How to get to know and lead a programming team?

Roy Osherove, during his presentation at BACK, said that a brilliant team develops - it cannot be created from scratch. You have to work hard to put the team together, get to know each other’s strengths and weaknesses, and finally prove themselves in battle.

As a seasoned Team Leader, I would like to describe a few issues that are worth paying attention to when leading a programming team. Some of them will probably be known to you, but I hope you find value in at least a few.

I found as many as 10 of them so to make the content more digestible, I divided it into smaller posts - 2 tips in each. 😀

Get to know the strengths and weaknesses of the team

Remember that a team is a composition of individuals with their own unique traits and personalities. To achieve the maximum efficiency, you need to know the possibilities hidden in each member and lead in a way that will let them fit together and utilize each other’s strengths. Otherwise you risk leading, what would be called, a team of strangers – the teammates not knowing each other and wasting time on misunderstandings.

For example, let’s think of a person who often fails to finish the tasks assigned to them, waiting for someone else to come in and wrap up the job. Only after getting to know them, you may find out that they are not doing it on purpose - it may be just their personality. Instead, they will strive in learning the business domain and be able to start tasks at unmatched speed. They will immediately figure out a topic and move it forward at a small cost of getting lost in the final details of the problem. In such a situation, it is worth finding someone with opposite qualities, who will complement their colleague and fill in the gaps in their performance.

Tools such as: Strength Finder help recognize the team’s best qualities (and yours too). By discussing these features together, you will discover how they influence your behavior and decisions. This will help you realize why at certain moments someone reacts in a particular way. Thus, you’ll understand your advantages and disadvantages better, which will lead to the increase of trust and building a deeper bond within the team.

Let people make mistakes

It’s widely known that in order to avoid mistakes, you need experience. And how do you gather experience? Obviously, by making mistakes. And we won’t get past this.

People need space to prove themselves and test their skills in a controlled environment. Then, and only then, they will be able to level up their competences. Being tested by new situations develops skills we didn’t realize we had and encourages us to continue trying, thus opening up a completely new world of possibilities. As team leaders, we gain a colleague with broader horizons and better skills, someone we can rely on in situations that he would not have been able to cope with just a few months ago.

A quote fits perfectly here, attributed to Alberto Brandolini “Development is a learning process, working code is a side effect” – the easier it is for your colleagues to learn new technologies / practices / skills, the better the product they will create.

Of course, an attempt will not always end up with a success. Failure is sometimes inevitable and with failure comes demotivation. Then, it is our role to explain why something went wrong and give feedback on what can be done better next time. However, let’s remember to not throw employees into the deep waters right away, because it will discourage them from trying and lock them in their own world.

We must also remember that someone will have to pay for the mistakes of our colleagues. It may be the one who made the mistake, other team members fixing the errors overtime, or even the company as a whole, deciding to provide the service for free and fix the error. Sometimes it’s even the client who sees the need for development and takes on the cost. Remember the rule “Fail fast and hard. Don’t fail silently”. It must be made clear that making a mistake is not a bad thing, but the lack of information about the problem will only intensify the unpleasant consequences for the team itself.

comments powered by Disqus