views:

115

answers:

2

I am a student right now. Recently, I am working in a project as a leader with three other students. Due to the lack of experience, our project is progressing slowly and our members are frustrated. They do not feel sense of accomplishment in the project. I am pressured and frustrated, too. But as a team leader, I think I need to push them. But I do not know how to do. Do I help them solve coding problem or just encouragement? But if I pay too much attention on it, it would slow down my own progress.

It is a not technical question, but it is very common in software development. I hope veteran programmers would give me some suggestions.

Thanks!

+2  A: 

Get clarity in what you want to have done. Let them do whatever they can on the project, and then give them as good pointers as you feel is right. Don't be too helpful. Let them try to solve the hard problems by themselves for a while. This would bring the sense of accomplishment when the problem is eventually solved. You can't magically make people better programmers - you have to start at where your team is, and work from there.

Consider poker planning the tasks so that you will agree (somewhat) on how long something will take. This might help get additional clarity in what needs done.

Encouragement should also help. :)

By the way, if they have programming questions, they could come here to SO. :)

Christian Jonassen
A: 

"Strengths-Based Leadership" has 4 ideas that are worth sharing when it comes to people following others:

  • Build Trust - Do the others in your team trust you? How reliable are you?
  • Show Compassion - This boils down to caring about other people. If you are friends with the others in the team, then that may help get a little more out of them as some people will work harder for a friend than for an enemy.
  • Provide Stability - Are you consistent with decisions and have some predictability in how things are going?
  • Create Hope - Is there a light at the end of the tunnel or is the project feeling like a death march?

In a similar vein, figure out where are each person's strengths. Are some better at writing code, figuring out requirements, architecting the solution, or writing documentation? Let each person contribute where their strengths are rather than trying to do where they are weak as that can be quite counter productive to my mind.

JB King