loading...
Runtime Revolution

Want to be a great team leader? The “usual stuff” is not enough!

nunotomas profile image Nuno Tomás Updated on ・5 min read

Since the beginning of my career, being a team leader was on my path for evolving as a professional. But to be honest, I didn’t have a clue of what that meant. During the last few years, I had the opportunity to assume that role. Opportunity might be a strong word, at some point my team leader left and I was next in the line…

I remember looking into my past team leaders, and creating a list of good and bad things about each one. I’ve read, and continue to read, a lot about experiences from other leaders. Also being on the spot helps me to learn fast and hard.

So I felt it was a good time to stop and understand some principles that I apply while trying to be a good team leader. Today I know that there isn’t a particular set of rules that help you to become a good leader. Of course, some good foundations like communication, being fair and be able to spread confidence will help a lot. There’s a lot of posts around the web focusing on some characteristics that you need to have to be a good team leader like having excellent communication skills, being assertive and organised. You need these, but they aren’t enough.

In my simplistic view, I see leading a team more like juggling a set of personalities with different moods each day, each one with a different view on things. And like juggling you need a lot of practice!

So today I’m going to talk about some principles that I also use to lead teams, and that may help you juggle.


Be aware of changes in dynamics

A team has a lot of moving parts, with people joining, leaving, changing roles, and people themselves growing and changing. That’s the natural course; it isn’t immutable.
In a group of friends, when a new person joins the group, there’s a natural dynamic that changes how the group functions. It will adapt to absorb the personality of the new member. The same happens in professional life, but with a twist. People joining companies isn’t a natural process, it’s an informed choice on both parts (check our blog post on how we do our hiring).
Something to be careful about is the fact that each change will create a disruption in the team, for better or worse. We should be prepared for that and adjust before it happens. E.g., we know that a person with a strong personality will join and it might cause some conflicts (which can be a good or bad thing). Also, some members of your team might not be able to take advantage / handle a strong personality. In those cases there some precautions you can take, like talking with both parties before, to lessen the impact, and try to envision how these different personalities can work together.
In the end, every change makes a difference, but the goal is to ensure equilibrium, to keep or increase productivity and team happiness.


Give attention to details

“Prevention is better than cure.” Desiderius Erasmus

If you’re leading a team, you should be aware of everything that’s happening with them. For me, noticing the behavior patterns of everyone around me helps me prepare for the day when something changes. If someone is always happy, something may have happened in the day they’re not. Understanding how they act when they are comfortable and when they’re not. Understanding when their eyes say they need help. I actively try to realize that something has changed, and try to help if I can.
Trying to understand the patterns in people’s behavior helps me to actively be prepared for the worst, and prevent problems before they become serious.


Help them grow

No one likes to look back and see that they are in the same “place” they were one year ago. So I make it a personal mission that everyone should evolve under my lead. Evolve into better versions of themselves which might not necessarily include becoming better at developing software, at least directly. I try passing knowledge around on how to communicate. Showing them that they cannot be judgemental about the quality of other developers when they see bad code, as they don’t know all the surroundings when it was done. Teaching them that sometimes they must be active and other times they have to have patience. My ultimate goal is for them not to need me.


Help them help themselves

Who has never seen a colleague taking a wrong turn time after time? And there’s no problem with that. I’m a big believer that we should let people fail. People will remember the experience, the feelings and hopefully will not repeat the same process.

Sometimes what happens is that people don’t understand that there’s another path that could be easier, or it could be better. An example that I see happening quite a lot, is when someone, after being on a task for a bit of time, starts to get lost in details. It’s normal and can happen to everyone. You have to remember to look into the big picture, the final goal and understand if what you and your team is doing continues to be in the direction of the primary goal.
When I notice that something might be slowing someone down, I actively go and talk to my colleagues about what they’re doing. I then listen to them explaining what they’re doing. But at some point, I will ask what they want to achieve in the end and if there’s another way to do it. Explaining the problem and solution to someone else frequently helps to trigger a better way to do it. How many times when asking someone for help, you suddenly know the answer, even before they start talking?


Everyone is important but no one is indispensable

A team will have people with different strengths and with different flaws. Some will write better code than others. But does that mean that they are more important than the ones who have different abilities? On my understanding of things, no one is more important than the team itself.
Why would anyone prefer to have an expert developer if they aren’t able to teach the others around him? For a team, what’s the point of having someone silo the information for themselves? Team players will want others to know as much as they know. They will want to spread the knowledge. They will want to be dispensable (which in the end makes them more indispensable).
Of course, when someone leaves, some part of the team goes with that person. But a well-oiled team can survive someone leaving, and adjust. When we have a good team in place, everyone becomes less indispensable.


This is a subject where there are no rights and wrongs. Everything will depend on the context and the surroundings. These aren’t full-proof principles. There’s a lot more than this that defines a good team leader. For me, I try to apply these principles every day. It’s just a start, but it helps.

Posted on by:

nunotomas profile

Nuno Tomás

@nunotomas

Hi there! I've been creating software since 2005. Nowadays been spending more time in the role of manager, but still, have some much appreciated time around coding.

Discussion

markdown guide
 

This is a great post! My VP of Engineering and I just walked through a yearly evaluation yesterday and almost all of your points came up during our discussions about what makes someone a good leader. This is really insightful.

 

Thank you for sharing Nuno, these are all great practices I appreciate in a team lead. Sometimes I think the industry gets "management" and "leadership" all mixed up. Leadership is more than shuffling people around and making sure they get their work done on time. Leaders inspire people to follow them and inspire people to want to do more for the benefit of the whole. A lot of your points really aspire to that goal and I thank you for pointing them out. I have seen some good talks on leadership you might want to watch if you haven't already done so.

Great Management of Technical Leads by Mike Acton (gdcvault.com/play/1022025/Great-Ma...)

Patterns of Effective Teams by Dan North (youtube.com/watch?v=lvs7VEsQzKY)

Extreme Ownership by Jocko Willink (youtube.com/watch?v=ljqra3BcqWM)

 

It's important to be confident. Whether it's true or not, the team will assume their leader is a better at the job then them (for example, a better programmer, or designer, or whatever). This can obviously not be true of all skills, you'll inevitably have things your team knows better than you. And it's important to use their strengths, but if they come to you with a question, it's important to be confident you can answer, or find an answer together.

 

Great post Nuno. At my workplace, we try to follow almost same principles under the banner of "Servant Leadership".