10 essential tasks a PeopleSoft Team Lead is expected to do..

This Post is little different from my other posts. Its different in my style of writing. This post has no beautiful descriptions, no hi-fi words used, no similies or metaphors. It is simple and straight so that the intent is communicated and received correctly. This post gives thumb rules to be a successful Team Lead in IT (rather my scope is PeopleSoft here) Services. We could rather call these "Essential tasks for a Team Lead"...

I have come up with the below tasks to be done by team lead after my little research at work and especially after making root-cause analysis of the failed projects or not-so-successful projects. I believe that the below tasks have to be made mandatory for the team leads so that after few projects, these would get imbibed in them and help them.


Assuming the general case - Team Lead is provided with the human resources (i.e. he/she has no option in selecting his/her team members, a resource allocator has already made up the team - with a decent combination of different levels of people with different relevant skill sets)
Apart from being techincally strong enough, a team lead should also have these as part of his duties:

1. The first time the team lead meets the team, he/she should have a general introduction of each team member - this gives him/her an opportunity to understand little about the attitude, the communication skills, the depth of the thought process the team members can get into.

2. After knowing the team members in general terms, it is good to meet the team again, may be next day and meet with an agenda of knowing the relevant technical(or functional) skills - every ones' strengths and weaknesses in domain. Thumb Rule is - Prepare an Excel sheet with the skill set matrix. Some of you might already be doing this but trust me there are many many team leads who donot carry out this task.

3. By doing task 2 above, the team lead knows his/her team members and their strengths and weaknesses. Now from the project output point of view, the strengths and the tasks should be mapped i.e. the task should be mapped to that member whose strength is solving that particular kind of task or issue.
But let us pause here. We also should look at increasing the learning and growth of the team members.
So lets do this - lets look at the timeslot for the deliverbles.
> If for a task, the deadline is not aggressive, lets give that task to a member who actually has little exposure on that task. This way, it gives the team member an opportunity to work on a task which he/she is not great at, which contributes to his learning and ultimately growth. If the time elapses and the deliverable is not completed by that team member, there is always another team member who has the strength of doing that. Remember, its ultimately the team work. But this loss of time should be predicted little earlier so that we dont end up losing all the time for that task or deliverable.

> And for the tasks which have aggressive time lines, lets map them to the team members with relevant skills as strengths.
Fair Enough.

4. Now the tasks are assigned accordingly. Next is the development. The tasks are allocated to the developers (team members). So they would start working on them but before they do this, there needs to be small activity done by the team lead - it does not matter if it takes some time.
This activity is very crucial in
a) avoiding re-work
b) avoiding losing track
c) making the team members understand the best practices, optimum solutions.

The activity is:
The team lead should give some time to the developers to think and arrive at different possible solutions to the given task/issue.
Then the team lead would discuss those possible solutions - the pros and corns of the suggested solutions by developer and ultimately choose or give an optimum solution to the problem.

5. Another thumb rule i would say is - Have official team meetings at least twice in a week. This helps the individual team members with a big picture of the project and gives an opportunity to think the impact of their designs of solution on other tasks.

6. The team lead should share the revised project plans periodically. This acquaints the team members with the MPP tool (if used for the project) and also aligns themselves to the time lines and makes them responsible in delivering their tasks.

7. The cushion or buffer time if exists should be used for peer reviews. Peer reviews should be encouraged as much as possible. this helps in two ways:
a) enhances quality - could avoid rare case bugs
b) eases the review work of team lead.

8. "A Stitch in time saves Nine" - Team Lead should keep check points much before delivery dates and have the code/design reviews. This discovers wrong approaches if any followed by developers and helps correcting them much ahead. The review by team lead should be thorough enough. Reviewing periodically much before is very essential.

9. The team lead should always check for the standards followed by the team members. If any deviation from standards are found, they should immediately modified.

10. As team lead has the vision and the big picture of the project, he/she should try to have maximum re-use of the solutions/code, etc.

There are many other duties or tasks of a team lead. But these are the ones which i think really can avoid escalations and makes the project lose out of control any time.