From programmer to programmers coach

Question

Coming from a "standalone" programmer job, which methods or tools do you use when the time has come to have to drive a team of programmers as project manager (but still coding with the crew) to explain, prepare and distribute the work to be done by the team ?

So a big project is coming, you're chosen as Lead Programmer, what do you use as method and tools to have the job done by the team ?

Answer 1

This is a great question, because there is no right answer. Each and every situation, team, product, company, person, is different.

There are a lot of books and websites available, some of which have already been posted (and will be posted). I won't bother doing that here, as I'm sure others will have better ideas on those than I do. I will just hit a couple of key points, in no particular order, from my own experience.

Know Your Team Sounds easy, but in practice, it's not. I don't necessarily mean knowing everything about them (although buying at lunch once in a while doesn't hurt). I just mean that you need to get a feel for what each person can do, and what they can't.

Some people are better when pushed, some people are better with being left alone; most are somewhere in between.

Be Objective If you have worked with these people in the past, the biggest problem may become being objective. You have to realistically evaluate what the people on your team are capable of, without letting friendship or dislike cloud your judgment.

Be a Technical Lead, not a Manager Sometimes its hard to remember that you are not really the boss. If you have a problem with somebody in your group, you can try and deal with it yourself, to a certain point. After that, you need to let the people that are supposed to deal with that kind of thing take care of it. You also shouldn't be approving vacations and that sort of thing, although you will certainly need to be aware of them and plan accordingly.

Delegate This was hard for me. There was a tendency to "oh, I'll just do that, it will be easier." Do it enough, it will get you in the long run. Plus, you will find that you don't have nearly as much time in a lead role for actually programming as you do outside that role. No matter what it seems like at the beginning of the project, you will no doubt be involved in meetings, documentation, more meetings, time management, meetings, and hundreds of other things you don't think of as a regular code monkey. And did I mention meetings?

Trust Your Team (but Verify) Don't waste time with weekly status meetings with the whole group, unless that would truly benefit everybody in the group. I usually found that I cared about my 5 minutes, knew enough about what the one or two people that I was working with that I didn't really care about their 5 minutes, and really thought I was stealing company time sitting through everybody else's stuff.

That being said, you need to make sure that you know enough about what is going on for those "surprise" meetings with your supervisors or managers. This goes back to knowing your team.

You Might Not Be There Forever I was once the project lead where the guy who hired me was a team member, for which I had to tell him what to do. It was awkward at first, but since we had a good working relationship, it quickly was a great benefit. You may end up as a member of a project working for any of the others in your group, or you may even need them as a reference later.

Don't Forget You weren't always a project lead. Think about the things that worked, or didn't work, when you weren't the lead on a project. And remember that you didn't necessarily have to like the things that did work - you may have a new found appreciation for them in your new position.

Good luck!

Answer 2

Your question remember me a project I was on. A developer was promoted "team leader" in a large enterprise project with no experience. Zero. Nada. He did his best. But that was more the military way. The project was a real war zone. That was a disaster. I learnt a lot from that.

I think that if you want to be a coach, you must find a coach yourself. Or a mentor, but someone with experience that will helps you avoiding obvious mistakes and let you fail gently on others to help your learn and be an effective project manager or team leader.

If your company is big enough, you will find people to talk with very easily. Invite them to lunch, talk about your situation, and keep in touch with them.

If your company is small, ask your management to book some trainings and conferences on the subject. Then be careful and try to observe the consequence of your acts to find what worked and what worked less well.

Management is a very hard thing as it's not as binary as programming.

Here are few pointers:

• Peopleware
• Slack
• Getting To Yes (very useful for conflict management)
• 7 Habits of effective people (the second part of the book is about people)
• The 8th Habit (complementary to the book above)
• Getting Things Done (you must be very well organized yourself)

Answer 3

It's a great challenge to take on leadership position. I've ever tried to follow some psychology and management theories on my first time to be a leader. However, I didn't get them quite right. If you can get them right, congratulations, you are talented as a leader! If you don't, don't worry about it. At least you have opportunity to take leadership and learn from it.

Before you lead your team, make sure you understand yourself first. What are your style, motivations, strengths and weaknesses? There are a lot of frameworks out there, but the ones that apply to your team depend on yourself. Keep improving your knowledge as a programmer and a leader. Be interested in and learn from the people you lead.

Please don't leave out your technical knowledge, because your team members can laugh at your back if you eventually can't do anything about programming. If you have something you know but your team member doesn't know, be sure to show him rather than to tell him.

Once you understand yourself, you may look at the following four points.

1. How many people are within your team? What development style that may suit your team? Agile? Waterfall?
2. What are each team member's hard skills?
3. How is each team member's style? (I usually use Hersey-Blanchard Situational Leadership Theory and DISC personality assessment)
4. How strong is each team member's motivation (I usually use Herzberg's Motivation-Hygiene Theory and Maslow's Theory of Motivation)

All those four things are for you to distribute the load to your team. It doesn't have to be balanced; just make sure each of them can get to their full potential. Also, the four points are useful to help you understand why some things work well or don't work as you expected. You can look for further solutions if you understand reason why something is wrong.

You can look for other theories that you are comfortable with. As this your first time, you may slip out at times. If that happens, practice admitting your mistakes and take charge. Also, when some of your team members slip out, it is best you cover for your team. This is to create sense of ownership throughout the project.

One book I can recommend is Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself.

Lastly, this text doesn't explain much.. so go and look for any leaders you admire, and copy their good qualities. Leaders don't have to be in the top positions. Have fun!

Answer 4

I have done this very thing, and there are a few core things to remember:

1. Management tasks first. Always be prepared to sacrifice your coding time to manage. If you don't have the time or peace to code, then don't. (Bottleneck prevention)

2. Respect your team. Don't work out all the details of a project and batch out work, instead bring the project to the team and work out the tasks and timescales together. (Motivation and team "buy-in")

3. Trust your team. Don't be afraid to delegate, and listen to them. (Value as a team member)