How do I keep my team involved and motivated? [closed]

Question

I am currently a grad student, but I was in the industry for a few years before going back to school.

I am in a class which involves teams of 4 working on fairly ambitious projects. As a result of having been in the industry, I have a lot of "software engineering" experience my fellow teammates lack (they are using SVN for the first time this semester). They are all very good programmers; but they don't have a lot of experience in building "real stuff".

Since I had a fairly concrete vision for a project, and my teammates did not, my idea is the one we will spend this semester working on. On top of that, as a result of my experience, plus the fact that I admittedly have a somewhat strong personality, I've become a de-facto team lead -- established weekly meeting times, assigned initial tasks, etc.

I want to avoid the trap of being so forceful with my ideas for what we should be doing and how we should be doing it, that my teammates feel like they have no say and become uninvolved and detached.

So here is the question:

How can I keep my team of undisciplined but talented programmers motivated while enforcing basic best practices (version control, milestones, etc) and a coherent project vision?

Edit: Thanks to everyone who answered so far. I think I've overemphasized the "software engineering" aspect of things; I'm also looking for ideas for how to encourage my teammates to contribute to the design, and feel ownership in the project which is at the moment a little bit "The SquareCog (and friends) Show!"

Answer 1

The best method I've found has nothing to do with code: team lunches.

Get together in an informal setting where you each talk about your problems, concerns, ideas, etc. This helps team unity in a way that very little else does.

As for the actual code side of it, minimize the amount of work they have to do to work inside the framework you want them to. If you want them to use tickets, do the actual management side of things for them -- have them tell you what the ticket is and have you do the actual legwork of managing these things. This seems like it'd take a long time, but overall it's minimal compared to the cost of poor communication and coordination. It pays off very quickly.

For version control, show them why it truly benefits them. Programmers pick up on ideas and run with them when they see they actually help them rather than just being a PITA.

Answer 2

I think developers are really practical people.

Play with those traits of typical developer personality: 1. Creativity 2. Curiosity 3. Practicality

Following your direct example, source control:

Most of us (I mean by my own experience) will fail to see the point in source control in the beginning (just because), so always keep them aware of the reason behind using source control.

Another thing is.. who decided to go on SVN? There are alternatives, I for one would fight to the teeth not to have SVN because I am a Git! (pun intended)

Instead of pulling them by the nose, you should/could have explained to them:

We need source control, find one you like and lets vote it out what we use to control the source.. this way there is a common ownership..and not just a follow the leader exercise.

Another thing is, be flexible in what you implement.

Draw out a plan on necessities, but try to be ready to implement them as the need arises, or as it becomes obvious to all that x, y or z practice should be implemented.

Have them need to implement the tools and resources and planning techniques you know by having them come to you for advice. (this doesn't mean you can't lay out a best practices blog internally or some other way of giving them access to this information beforehand)

Developers like to learn and grow, but we need ownership and understanding in the direction we are going.

If you try to force feed and drive them too much, both you and them will just lose motivation, enlightenment requires self driven forces.

Answer 3

How about the Scrum (even if you don't call it that). Gives everyone a chance to have their say, and you listen. As the forceful personality giving the others a real chance to communicate what's on their mind (not yours) is a good step towards harmony.

On top of that they will learn from your tech experience, you will learn from their ideas and enthusiasm. A good leader is always open to communication, you set the direction and vision (and you did choose the project) they come up with the clever ways of doing it.

Answer 4

I've been in a similar position a number of times.

Sometimes I just take charge, and be damned. Fair enough.

And many times, I resist the urge; I try to encourage my colleagues to take the lead. Sometimes this works, sometimes not.

And sometimes, I just come clean. "I seem to be taking over, as is my nature. But I don't want to railroad you guys. Anyone else fancy taking the lead? If not, are you happy with what I have already suggested? Speak up if you have any good ideas...". Again, sometimes this works, but not always.

Ultimately, you can 'lead the horse to water'... Projects need the lead, if no-one else rises to the challenge, it is better that you do.

Once you have the lead, lead by example...