What Makes a Good Technical Team Lead?

Question

As a technical team lead of a small team of web developers, I have been finding it difficult lately to identify and focus on the core responsibilities of keeping my team running.

Specifically, I'm finding myself pulled in several directions between doing actual hands-on development work, allocating work items to team members, making / assisting with technical or design decisions, documentation and administration and keeping up-to-speed with development progress and support handover preparation.

What have other people found to be the core attributes of an effective team leader and what sorts of techniques or strategies did that person employ that made them so effective?

Answer 1

The hardest part of being the team leader is that you need to deal with people, with different tempers, different ways of thinking, interpersonal relations, etc.

Here are some things a team leader needs, in my oppinion and experience (the list is not complete):

• The team leader has to be, first of all, a leader. He needs to influence and motivate the team members to do their job in an effective manner.
• He needs a lot of "soft" skills (communication, conflic solving) and needs to have a good awareness of what happens between the team members (relations betweeen the team members).
• He needs to gain the respect of the team. In software, from my experience, he needs to show the team members that he has good technical skills, to gain respect of the team members.

I can't think of a strategy on this. Mayb some good practices :)

• Try to be fair with everyone, expect they will be fair to you and everybody else.
• When trying to correct wrong behavior, try to emphasise facts, situations, and not persons, so your "feedback" will not be perceived as a personal attack.
• Quicly react in case something goes wrong inside the team.

PS: Fair means if something good happens, you signal this to the team. When something wrong happens, you signal this to the team, too.

Answer 2

In such situations I always recommend a book by Tom DeMarco and Tim Lister of the Atlantic Systems Guild. it is called PeopleWare and has some great advice for management positions in programming. Another good book is Managing Humans by Rands in Repose.

As a technical team lead you still are technical, what means that there still might be a programming hands on part you will have to do. But your greatest duties now is to get the stones out of the way of your people. See that they have the necessary tools to work, all the education and information they need, instead of doing something yourself teach somebody to do it.

Invest yourself into multiplying your knowledge. Bringing forth a great team and a bunch of great programmers will make you invaluable for your company, not being a great programmer yourself that frustrates his team mates by stealing the tasks with the highest fun factor ;-)

Answer 3

People management are key to being an effective team leader. In fact, the best TL I ever had was a guy who had little relevant technical skills. He instead focussed on making sure we were working effectively, had the right areas to match our skills and attitudes, and then took much of the paperwork and testing chores away from us (I'm sure to keep tabs on us so we were working well, not simply to free us from those 'nasty' jobs).

If you are getting caught up in the administration of the team, then that's good - that's your job. If you want to be a team member, and code, then too bad, that's not your primary job. Its hard to hear sometimes, often team leads who are promoted to the role expect to be able to continue coding as before, and get the benefits of being team lead.

So, it sounds like you've reached the point where you need to decide where you want to take your career - more development/senior dev, or team leader/management. That's the first thing you have to get your head around.

Once you've decided that, and I will assume you keep the TL role, then it should become easier to delegate the work to your team and find ways to track their progress, with a little coding around the edges when you have the time. The key is to ensure that the team comes first, that you see to their needs before your own. Communication with them comes second, make sure you're explaining what and why you're doing, not just issuing orders from on-high. As an example, remember this. If you go to a subway and shout 'everyone get out', people will stand around and look at you like you're an idiot. shout 'fire' and they leave PDQ. The point is that if you explain yourself, people will accept what you say.

One place I found that helped with a lot of of the more difficult areas you'll come up against is Scott Berkun's articles. He was a project manager at Microsoft, and now writes some excellent, thought-provoking articles on the 'softer' side of development. Read a few of those every so often and you should work out for yourself what you need to do from your own experiences and your team's organisation.

Answer 4

I believe in respect.

I believe most developers respect and love to work with developers (or team leaders) who helps them to solve problems, learn new things and become better developers.

I am team leader too, and I am trying hard to have always good answer to my devs questions about coding issues, bug solving techniques or product features/functionality.

Of course, "soft" skills are also important, but without good technical knowledge, which helps devs become better developers, it is a bit harder to be respected and be good leader.

Answer 5

Another big aspect of being a team leader which allot of people (myself included) initially forget, is that you need to communicate with and keep management up to date. Management are often a different species and don't communicate i the same way.

Example; telling a manager (including project and program managers) that the application is complete except for the exception code, means nothing to them. They may have NO Technical knowledge.

Make sure you can answer questions from management, so that you can keep those guys out of your team’s hair. Create To-do Lists and Issue Logs that you keep up to date. Many of my To-do Lists and Issue Logs became tools that Managers would use directly when they had to report back up to their managers.

It's easy for developers to become team leads because you have the background and context. This obviously assumes that you can LEAD rather than Manage. You need to be a leader to your team and a buffer between them and Management.

In Practise, it does help to actually do a Project Management Course (I did Prince2) and to understand the human psyche.

Answer 6

Roles and responsibilities of team leads differs from company to company. Here are some comments based on small team aspect.

1. As a management level person, a team lead wil have to face many challenges. Not just professional but it can be personal also.

2. Always try to use some project tracking tool for all your projects. It helps much for team and work allocation etc.

3. You must keep a checklist for everyday's task. Effective time management skills is needed.

4. Always update your technology knowledge. Team members would like to see you as a helper in their activities.

5. A team lead is really a 'Leader'. You have powers. Respect it yourself. For that, you need to build self confidence.

6. Try to interact with your team as much as possible. It is not just in the form of official stuff, but also you can talk about their personal matters like family, brothers, his/her past etc. (if the team member likes it)

7. Communication should be given priority. Your client may tolerate your bugs in project but he cannot tolerage bad communication.

8. Try to call meetings if you do not have such a habbit. It will let your team know 'you are something'

9. Do not think you are a 'team lead', think the next step (may be PM in your organization?) and behave like that.

10. No hard feelings. Try to smile even if you want to Cry!

Answer 7

"Team lead" is a much abused title and it's important what middle management means by the role. Usually development team lead is akin to foreman in production, petty officer in navy or sergeant in army.

Duties normally include:

• Ensuring day to day smooth operation of the team (general problem solving).

• Serving as an ambassador for the team, i.e. single point of contact for management on one hand and team members on another.

• Timely identifying and escalating any serious issues to management.

• Setting a good example for team members.

• Identifying individual team members training needs.

• Time keeping, being able to report work progress, current location and activity of any of the team members.

• Ensuring their team is fit to perform their tasks every working day.

• Being at least as able at performing team tasks as any individual team member.

Qualities of a development team leader from management's point of view:

• Unquestionable and demonstrable competence

• Loyalty to company and management

• Clear understanding of own remit

• Ability to complete tasks independently

• Ability to gain respect of team members

• Approachability

• Political correctness

• Strong work ethic

As a developer you would probably be able to deduce a mix of qualities and behaviours team members expect from their team leader: fairness, competence, representation of serious issues to management etc.

I remember writing on some specific aspects of communication as a team leader, however it might not be completely relevant to this question.

Answer 8

Similar question that may be useful to look at those answers:

What is the most important attribute of a project manager/team leader you expect?

Answer 9

First and formost is organization. If you don't know what everyone on your team is working on and what else needs to be done, that is the first step.

Delegate. Yes it is easier to do many things yourself, but working 18 hour days while your team is leaving every day on time and not busy is a bad thing. Also, they don't learn to do those things if you don't give them to them. As a the team lead, you can often become the bottelneck, delgating helps to prevent that from happening.

When developers do things wrong, don't fix them yourself. Tell the developer what is wrong and have him or her do the fix. I've seen people merrily go on making the same mistakes repeatedly because their boss was in a hurry and just fixed things himself. It will take longer the first time or two, but you know what, once people find out that you will send stuff back, you end up getting higher quality stuff to begin with.

Keep notes on performance, you will end up doing the appraisals, so take notes through the year on bad and especially good things for each employee you have. It seems obvious but don't save these in a public folder. (I accidentally found my own appraisal and someone else's once in a public folder.)

Be even-handed in applying rules. Some of the team members are probably your friends. Make sure you hold them to the same standards you hold other team members to. As a manager, you need to be able to separate any personal relationships you have from work performance. I've seen a lot of people go down in flames because they couldn't do this and kept their buddy on when he wasn't performing or promoted their girlfriend when others were more qualified. If you play favorites, the others will resent it and will eventually undermine you in the company. Some of your friends will try to manipulate you to treat them better, give them better assignments than the others, allow them more latitude concerning work hours etc. It is best to establish from the start that you will treat everyone evenly.

Listen as much as you talk. Make sure your people feel their concerns are heard.

Protect your folks as much as possible from the stuff that comes down from above. Everyone prefers to work for someone who will take the heat and share the praise.

If you have a problem performer (and most team leads have to deal with this eventually), make sure you clearly tell the person what the problem is, document the problem and tell the person what he or she needs to do to correct it. But do it in a way that allows the other person to express his or her own view on the subject. And try to keep to actions not personality. Remember though you are the final arbiter of what consitutes acceptable performance, so even if Joe disagrees that his performance is unacceptable (poor performers almost always think they are stars for some reason), you still may have to insist on the change. Be specific in dealing with problems. Also try to catch those poor performers doing something right. Make sure you mention that to them and others if apropriate. Try not to make every conversation you have with this person be a negative one.

Answer 10

I would add "Behind Closed Doors" to the list of above reads.

Answer 11

Here's another great question that seems to be relevant and has some good answers:

How do you manage your time as a team leader?

I found it on the "related" bar on the right. Apologies if you've seen it already.

Answer 12

These are the tasks (not an exclusive list) I think contribute to one being a good [IT] technical team lead ...

1) identification of and alignment with key parties

2) determination and the documentation of scope and approach

3) creation and publication of the build plan based upon agreed priorities

4) communication of the pipeline and target dates to the developers

5) daily tracking and documentation of progress

6) weekly summary reporting of progress to the PM using tracking documentation from point 5

7) awareness of issues and helping progress them towards resolution

8) awareness of risks and identification and actioning risk mitigation steps

9) amendments to the plan (duration, resource, prioritization) as new information becomes known during the course of the project and communication of the changes

10) arranging the availability and timely refresh of environments

11) sharing with the team information regarding the status, issues, concerns, important milestones, etc of the project as a whole

12) maintaince of a shared [organized] folder structure to share the various project and admininstration documents

13) communication with and escalation to senior management as appropriate

14) attending weekly project team leads meetings and discussing status, concerns, issues. Feeding back project news to the team.

15) organizing of quality assurance via peer reviews

I do not get involved with the technical work. I do keep abreast with the technologies so that I can make reasonable asessments on the technical estimates being provided by the team. Where necessary I ask developers to provide a plan (breakdown the work into steps) so that estimates can be reviewed in terms of lower level activities.

Also I think being able to understand the technology at a conceptual level is very important (basically domain knowledge). This helps me to participate, shape and contribute in technology discussions.

I work to ensure that the developers have a clear understanding of their priorities, of their target dates and encourage open and honest communication within the team.

The team appears to respond well to the above.