What do Team Leaders do?

Question

It's been a while since I've taken over the responsibility of leading my team and I'm probably doing a reasonable job at it. However, I get the feeling that I am not getting enough exposure to the real-world responsibilities and activities that Team Leaders engage in. On the other hand, it might be I am doing much more than an average Team Leader is expected to do! Other TL's I work with only seem to engage actively in development. Either way, I have no yardstick to compare with and my searches have not revealed anything concrete.

Therefore, I am really interested in learning about the activities that you as a Lead or your Team Leaders are involved in, on a daily basis. Specifically, regarding the following points :

• What activities form an integral part of a Team Leader's average workday? (Programming, Task delegation, Reporting, Bug management, etc.)
• What tools/software form a part of a Team Leader's essential toolkit? (MS Project, Excel, TFS, etc.) Note: I have already read What tools are available to a Team leader...
• What kind of reports does a Team Leader submit to the Project Leader or Manager?
• What aspects of the initial designing/architecting/engineering the application is a Team Leader expected to be involved in?
• Are all or most Team Leaders actively involved in Object or Data modeling and designing Product Workflows?
• What aspects of a Project Manager's job should a Team Leader be involved in... for instance, resource management using Gantt charts?

I would greatly appreciate specific answers. EDIT: I would like to emphasize that I am not asking about the characteristics of a good Team Leader.

Thanks in advance for your insight!

Answer 1

General: You may also be interested to follow noop.nl blog. It's a good one for managers.

---

I'm no team lead but one of the best team leads I had kept me focused at what's important. He prioritized the tasks for me (didn't force anything). He managed me and kept me free of the other things that can be interrupting for a programmer and I got to do what I do best -- coding.

He also took care of most of the e-mail communications, I feel this is another big thing that takes up a lot of a programmer's time. He also randomly takes one of the team members out for a casual cup of coffee sometimes and chats about what he (the team member) thinks of how the project is moving, if he has any suggestions, etc. A better one-on-one meeting; not a traditional one in a meeting room.

After a small milestone is completed, he used to take us (the entire team) out for lunch where we discussed about politics, Linus vs Windows, Java's future, Indian cricket team, movies, and whatnot.

I miss his management.

Answer 2

I think it depends on your company's existing policies what kind of documents and memos you are expected to hand in.The list above sounds like the bureaucratic part of TL tasks.

My advice would be that you get to know your team as individual programmers and keep the marketing/business people away from them.

Edit: Leading a Software Development Team (The practical solutions series) by Richard Whitehead is a very good book for any team leader or even a team member.

Answer 3

There are no hard and fast rules about what a Team Lead does. It can also be confused Tech Leads, which are slightly different but the lines are blurred.

The biggest factor is the size of the team. The most devs I've had under me is 8 and on complex projects I would spend almost half my time "managing" them. Not in a HR touchy-feely sense. It was more project-focused than that. It was a question of going through the plan with them, working out what's being done, what has been done, what the issues are (if any), discussing design aspects they don't understand (my job was to understand it all), reviewing code, etc.

Those tasks I estimate will consume roughly 2-4 hours per developer per week on average. Juniors will tend to be closer to 4 (unless you can palm those duties off on a Senior). Seniors will tend to be less or, if they'r emore, it's because they're taking some of the load off elsewhere.

Early stages of a project will tend to have a high time component (10-20 hours a week) dealing with requirements, design and estimates.

Later stages will tail that off but replace it with 5 maybe 10 hours a week of defect meetings, testing and the like.

I made the mistake of estimating that I could spend half my time coding when I had 6-8 devs. In reality it was more like 10%. 20% in a good week.

I try to stay well clear of MS Project and other PM tools beyond having a task summary or possibly a GANTT chart printed out that I wander around the office with to discuss progress at various times (every 1-2 days per developer). It can be a quick 2 minute "How's it going?" chat or something longer, if required.

Bug tracking can be done any number of ways. Jira has been the most common for me.

I tend to favour Wikis for knowledge sharing, design and documentation. Even for task lists (where people can update their own progress). This can be Confluence or any number of other similar products.

Probably the most important lessons I can impart are:

• Keep communication going. Don't let people sit in a corner and code without contact. That's a recipe for disaster. That doens't mean micro-managing or constantly getting in their face. It simply means keeping in touch;
• Know every aspect or the requirements and the high-level design. You should be able to knowledgeably discuss any aspect of the project so that means having a reasonable understanding of database modelling, UI design, Web technologies and whatever else your project covers;
• Every developer is different. Some like you to be hands-on (it gives them reassurance). Others like more independance. Some will ask for help when they get in trouble. Others will panic and you'll need to look for signs that they're in trouble. Some like being comfortable in a niche. Others like learning new things. You should know what motivates each team member;
• Learn to delegate. You can't decide everything. You can't do everything. Know that someone might not do something the way you would but that's OK (a lot of developers have real problems with the fact that other people do things differently);
• Give credit where credit is due; and
• Know how to manage expectations.

Answer 4

What activities form an integral part of a Team Leader's average workday? (Programming, Task delegation, Reporting, Bug management, etc.)

One of the sacrifices of being a team leader is that you will spend less time each day coding and more time tracking tasks and bugs and making sure things are on track. One of the challenges of a coder who has been moved into a leadership role is learning how to delegate tasks that you would rather do yourself.

Also, depending on the size of the team, you will find it challenging to centralize each task (task management, bug management, etc.) into one specific time of the day. You will probably find yourself jumping from one to another all day. Certain Agile development practices can help alleviate this, for instance a daily SCRUM will allow you to gather everyone's status reports quickly without you having to track everyone down.

What tools/software form a part of a Team Leader's essential toolkit? (MS Project, Excel, TFS, etc.) Note: I have already read What tools are available to a Team leader...

All of these tools have their purpose - the charts and such can be helpful but it all depends on your management style and what kind of information you need. Do you use Gantt charts or burndown charts to manage tasks and project goals? Find a tool that supports your informational leadership approach in the easiest and least intrusive manner. I personally like the SCRUM plugin for TFS but it has its problems. MS Project is nice for some things too but nothing can beat the simplicity and ease of use of an Excel spreadsheet!

What kind of reports does a Team Leader submit to the Project Leader or Manager?

Unfortunately the answer to this question is "whatever reports they ask you for". But common reports that you will most like be asked for will be related to time budgets. Project managers care first and foremost about time budgets and whether or not the project is on time.

What aspects of the initial designing/architecting/engineering the application is a Team Leader expected to be involved in?

This is a really good question because this is a difficult areas for team leaders who love to code. If you love to code I am sure you will want to be a big part of the designing of the project and this may be appropriate for the project you are working on or it may not. You will need to look realistically at several variables:

1. The time constraints of the project.
2. The ability of other team members to create a good design (do you have an architect on your team?).
3. Your personal time constraints, how much time will you have to spend maintaining the project from a leadership perspective.

Are all or most Team Leaders actively involved in Object or Data modeling and designing Product Workflows?

This is similar to the previous question in a lot of ways. It really boils down to the quality of the project and the ability of your team members to do things correctly. Do you trust your team members? A good project almost requires that you do.

What aspects of a Project Manager's job should a Team Leader be involved in... for instance, resource management using Gantt charts?

This is a really good question. My feeling is that the data aggregated by your reports is owned by the team while the reports themselves are owned by you. As each developer tracks their time they are responsible for keeping things up-to-date. Beyond that I believe that the reporting and management of reports for team-encompassing data should be yours. However you should make the reports available to the team and even encourage your teammates to check the reports often so that they have an idea of the project's trajectory. A good teammate should always be aware of how their individual effort effects the final goal.

Answer 5

As far as the duties related - an excellent article

Answer 6

I am developer #3 at a 3 man development shop. Dev #2 is "Team Leader", and I report to him for evaluation purposes. Dev #1 is "The Boss", and a director (above him is a VP).

The Boss runs the show, no question. The Team Leader and I are afforded a good deal of autonomy, he moreso than I. We occasionally collaborate on projects but the workload right now (and this has been true for some time) is such that we're mostly isolated. His title is somewhat token, though it came with a significant raise (he was going to leave for another position and this was part of the package that brought him back). We've had two dev #4s, and it looked like his leadership responsibilities were going to increase (and there were rumors of a fifth position opening up) but that ended (one was let go, the other left).

Unfortunately, we're fairly rough in our approach to software development. That said, All three of us get involved in the planning of any projects, even if a particular person isn't working on a particular project. We don't do much modeling, but Dev #2 models when its called for (sometimes we both model and then the 3 of us will go over them and generate the working model going forward).

It used to be that I sent a status report each month to Dev #2, who passed it along I think to The Boss, who passed that along. But it changed, and I don't do written status reports anymore. But I have to help the Boss write his, so I may as well be.

Answer 7

You may want to check Rands in Repose and especially these articles.

In short, you have become an interface. It is your job to protect your team against abuse: people trundling in, keeping developers from doing the important work, annoying them with marketing or managing slang or, even worse, from developers talking to the "upper class" (CEO: "When are you finished?" Dev: "uh ... I dunno ... all tests broke this morning and I get interrupted all the time by Lenny and there is that information I need and Joe won't return my calls ...whine" -> CEO goes ballistic in your office because he doesn't understand that this means nothing).

It's your job to take all the blame for any kind of blunder and to present your team proudly when something went well. In return, you say which way to go and you can say "No" to anyone (even the CEO; having some supporting argument will help, though :).

Answer 8

For some opinions on the coding aspect of management, take a look at Should Managers be Expected to Program?

Answer 9

Roy Osherove has started a blog about Team Leadership which has good resource in it. I realise this doesn't answer your questions directly but it is related so I thought I would respond with it.