About being a Team Leader

Introduction

I used to be a team leader, before starting 8th color. Now we are a small development team here (the three of us) at 8th color, and I’m still advising some other teams about their methodologies.

This made me think again about what it means for me to be a team leader, and some experiences that could hopefully help some developers aiming for the function.

What is this about?

In my experience and vision, being a technical team leader is first and foremost being a team leader. The technical part is there, of course, but people are what matters, and what you should concentrate on. No amount of technical prowess will save a project if the team is not working. I found three analogies that worked for me.

Prince2 Projectmanagement-team

Nooooooooooooo ! (Photo credit: Wikipedia)

Being the foreman

What made the difference between a project manager and a team leader is that I always saw my position as the one of a foreman. When people ask me “they are working for you?”, I tend to answer “they are working with me”. It’s a slight difference, but a potent one.

Being a foreman means that you are directing the crew, but from the middle of them, not from the outside. My father used to direct a garage crew. As a foreman, he was not putting the tires himself, but he could still go in the hole under the truck to look at the job or give advice. I’m always in the hole. I call the shots, but can get my hands in also. That is important for me, to keep up with the reality of the work, and for the other developers also, as they know they can count on me to help, not just manage.

Gatekeeping

My definition of my job is always to be the gatekeeper: I am there to be interrupted, so that my team will not be. I did impose a rule at some point, not on the team, but on the external world: all interruptions or signals (mails, people, phone calls) were to be directed to me. Should it requires to interrupt a team member, that decision would be mine. The positive impact is to allow the team to be focused and productive. The bad one is that it meant to split my time in 15 minutes chunks. Better one person than five, anyway.

Moving furnitures

Furniture Shop in Mysore, India

Your team cannot code in the middle of this. (Photo credit: Arthur Chapman)

A colleague of mine once expressed his job of team leader as “moving furnitures, to be sure that developers had enough space in the room to work”. In other words: removing impediments. Achieving the business goals is your team work. Yours is to remove any obstacle for them to achieve it.

Trust people to get the job done

This is a very pernicious problem : being a technical team leader means that you are in charge of people and able to do their job. The key is it is not because you are able to develop a feature that you should do it. Not even if you are the most capable person: you did decide to take a job with different responsibility, you should work on those first. Someone else can manage the feature, but no one else will run the team if you are busy digging into code with your headphones on.

I tak with a lot of non technical people managing developers, telling me how difficult it is, because they do not understand the job. Becoming team leader when you were a developer looks easier to them. It is not. There is nothing more difficult than to let people work on something, when you know their job and think that you could do better. After all (and it is one of the flaw of the system), most often, good developers get promoted to team leaders.

Being a team leader is all about supporting your team,, helping them, but moreover trusting them to get the job done by not doing it for them.

Take the shots, call the shots

This is something I strongly believe about every management function. When I am in charge, it means than any defect in my team is my responsibility. The basic consequence is simple : if someone have to complain, it

Staff Sgt. Howie Loughran, 31st CES EOD team l...

Be prepared to take some shots for the team. (Photo credit: Wikipedia)

complains to me. If the team made an error, it is my task to apologize and/or assume the consequence. Whoever caused the initial problem, it is my job to ensure it does not happen. The other side of the coin is that of course, if someone in the team did fail, I’ll have a discussion with him/her, and see that it does not happen again. But I’ll have this discussion personally (not my manager, not the customer that did support the consequence of the error) and privately. You have the “right” to call the shots in the team because you take the shots for the team.

Warning to those tempted

If you are a developer reading this, and tempted by making the shift to being a team lead, I’ll offer two nuggets of “experience” (wisdom is only given by old people with long, white beards) that may help you decide whether it is a good idea.

Following people is a full time job

Should you start doing some “coordination” for a small team, let say 5 persons, this will probably eat all your time, at least if you want to do it “properly”. That means that you’ll have very little time to code, however able you can be. I still open my IDE everyday, but most often than not, it is to review something, not to build it. If you like to build software, be aware of this. You may be building your last.

My previous boss advice

A good quality example of a Dartmoor Pony. The...

But I -want- a Pony ! (Photo credit: Wikipedia)

Some years ago, I was a reasonably happy developer working at a large company. I enjoyed some kind of “lead developer” status in my team (even if my official title at the company was “developer”). At some point, I thought that I “deserved” some recognition in this (my team did not have a Team Leader at the time,  and I was doing the job).

So, I went to my manager to ask (sort of demand) the position. She looked at me and said “If you want it, I’ll support you on this to the top management (who needed to approve those kind of promotions). But think about it carefully. Be sure that this is what you want”.

At that time, I did not really though over it twice – I was pretty sure I had the required skills and that I basically did most of the job already. Of course I wanted it! No one did contest that, and I got the position soon after (with some monetary benefits). End of the story, except for one thing. The good question would have been: would I be happier in this position? Fact is, since then, I did far less coding, as other tasks began replacing the coding ones – like coordination and, even worse, meetings.

A couple years after, I considered moving up the ladder again. I thought about it carefully that time, and decided not to: team leader was the last position where I could expect still doing some practical stuff. I was coding few features, but was still opening my IDE every day. The next step would have been exchanging my IDE for an MS Project.

In her words: “Be sure that you really want it”. Or, as the popular quote goes

“Be Careful What You Wish for ’cause It Might Come True”.

Conclusion

I took and still take a lot of pleasure working as a team leader. I find the function immensely rewarding. But it is a totally different job than being a developer. Both are interesting in their own way. It is not because one may be better paid or of higher status that you’ll be happier in, and that is what should matter. Good developers frequently make bad team leaders or worse : unhappy team leaders. Be careful.

Enhanced by Zemanta




One thought on “About being a Team Leader

  1. Pingback: ebook review: Memoirs of a team leader | 8th Color

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>