How should I manage a team with different skill levels?

Question

I'll be working on a software project with some friends of mine, and I've been appointed technical lead. None of these guys is a bad programmer at all, but I do have significantly more experience than them. I need to be able to distribute the work among everyone on the team, while also making sure that we don't tread on one another's toes; that they meet the relatively high standards of quality and scalability that we need to make this project successful, without requiring me to review everything they commit.

How should I maintain standards while avoiding micromanagement? Is it enough to make some diagrams, schedule some code reviews, and trust that I'll be able to fix anything that they might break, or should I go the TDD route and write explicit tests for the team to satisfy?

Answer 1

You should review some of their code and let them review each others. It's not that you want to be the Check In Police, but want to provide feedback as often as possible. Being a reviewer can reinforce their understanding. Let them review your code as well. Be the model.

Side Note: there should be no surprises during an anual review.

Answer 2

Above all: communicate your expectations and design in as many different ways as possible. Diagrams are good for some; defined interfaces work for others; pair-programming also works; formal code reviews can also help some people.

I also recommend using automation as much as possible:

• Get the team to use a tool like NDepend or Resharper if you're in the .Net realm. Tweak the standard rules if you don't like them.
• Automate your testing as much as practical.

It's hard to argue with a failed test case or automated inspection tool, provided they are set up well.

Answer 3

If you are truly working with a large variety of skill levels on the same project there's going to be some problems. The question is when do you deal with them? Are they going to write such bad code that you may be better off not having their assistance? Is this going to create personal tension? Are you going to end friendships? These questions no one can answer but you.

Assuming everyone will stay on the team, I recommend breaking up the assignments into small chunks (bigger ones go to more skilled dudes) and let the most skilled developers refactor when you are done. Make sure to run QA in tight, regular intervals. This is pretty close to what happens in reality anyways.

Answer 4

As much as possible, stay out of the weeds. On any team, if you're the leader, you need to save a certain chunk of your bandwidth for the crises and the big picture. Diagrams are good and coding standards are always sane, but setting up processes where people check each other's work is even better (cross testing, peer reviews, pair programming). Not everyone on the team needs to be a star - the team together can usually overcome any weaknesses in individuals.

The thing I'd recommend is that you resist the urge, as much as possible, to tell people what errors you see in their coding - instead, lead them to seeing it themselves. Remain a part of the collaborative review of development work, but make sure that you don't contribute more than other members. Instead, put the extra effort into encouraging people to see what you see and give plenty of explanations of why the things you see matter.

Don't worry too much about overlap - beyond a sensible breakout of work, you can ask team members to check in among themselves, and then just verify that communication happened. The team will quickly start to look to each other as a way to acheive consensus, and that makes your job about 20 times easier - then all you have to do is be the tie breaker when major areas disagree.

Then save your effort for looking at the team collectively. Each person will have some awesome strengths and some fascinating weaknesses. Ideally, you'll start throwing work at people that suits their strengths while still giving them a chance to work through their weaknesses in ways that don't disable the team's productivity.

The ultimate gold star of team leadership is making people aware of their weaknesses in such a way that they are motivated and well informed enough to start fixing them.

Answer 5

Sit down and discuss on the technologies and tool sets everyone in the team agree on. Some people may be more experienced in the agreed tools than others in the team, so those who are more experienced must be willing and agreeable to share the experience and knowledge with the rest.

Discuss, Agree, Write down, Model and communicate the standards (such as naming convention, coding best practices and folder structures).

Do continuous and regular testing and QA checking. Notify the person ASAP when you see inconsistencies.

Answer 6

I was going to say 'get the most experienced person on the team to organize it', but it sounds like you are that person.

If you can, split the project into two levels. Application-layer/driver-layer is a good split. Form two subgroups within your team and make one person in each responsible for that level. That can work extremely well.

Resign yourself to it. You will have to review everything they commit, particularly early on. If everything is going swimmingly you'll just be eye-balling the code. Reviewing won't take you that much time at all, and it will give you a lot of confidence things are going well. More likely you'll find someone is using semaphores incorrectly, or is writing their own version of a library function or some such madness. My experience is you have to be watching the code as it is being written to nip code problems in the bud.

Answer 7

What is normally expected of a technical lead in your company ? I'm a manager and have been in this spot a few times and about to do it again starting this week (hiring newbies and others to join a team of 20 year and 4 year experienced people).

I'm a manager and can be a technical lead (in the last few years, I've played down the latter role to grow leadership within the team. In any case, some thoughts:

• Evaluate skills and weaknesses of entire team.
• Create a growth plan - While your focus is growing the weakest members, you really should focus on growing everybody as individuals and as a team.
• Communicate this plan and set everybody's expectations.
• Distribute the learning and validation across the team. While you, as lead, my own the lionshare of the work, distributing out the work will help your more senior team members into leaders.
• Create a regular feedback loop. Meet with team members to evaluate progress and to provide feedback.
• Adjust the plan, as necessary, to insure success.
• If somebody isn't working out and won't, even with reasonable help, be prepared to push them out. This is complicated, but if you've set a plan, expectations and provide a feedback loop, you'll be in a much better position to do so.
• Keep an eye on team morale. This type of situation can do great things to grow a team or rip it apart. Your leadership skills and investment in the team will go a long way to set the outcome.

Answer 8

Try looking into what goes into defining a "Software Architecture". Creating separately developable modules is one of the main reasons for doing upfront design and analysis. I know that doing this type of work is out of style, but it works in all cases, as opposed to just some cases that the newer development methods espouse.

Answer 9

As the most experienced developer in the team, I would expect from your heavy coaching.

Let the team assign work to themselves using kanban, and then spend your whole day doing pair programming with each of them.

When you see a bad habit or something they should (all) be aware of, stop everything and draw on the whiteboard.

After a few weeks, you will be able to slow down on heavy coaching as the overall skills of the team will approach yours.

Answer 10

There's a couple of different lists I'd be tempted to review from your position:

1. How well do I know this team. Do you know the strengths and weaknesses of everyone on the team? Do you know how to get the best out of each person? Do you know how to divide up the work in a relatively fair manner for everyone? Those kinds of questions are something to ask and understand that there may be shifts in these lists over time as some people may develop some skills that may change how they are viewed. When you were appointed was there expectations that some on the team had of you? That last question may be hard to get people to honestly answer but it can help a lot if that can be disclosed and discussed in a meaningful way without stirring up offense or resentment which can be pretty easy if what is being discussed is very personal to some people. Do not try to get personal opinions in a group meeting, but get this in private one on one meetings as there is nothing worse than trying to get someone to admit something rather personal in front of teammates that they wish wasn't public.

2. How well do I know myself. What elements from your background are you using to claim some technical authority here? What strengths and weaknesses do you bring to the team? Are you expected to get into the trenches regularly? Are there practices you've seen that you'd want to introduce to this team to help steer them? Are there warning signs that you remember from past experience that may be useful to see if any of these are starting to appear in the work the team is doing.

In a way this all boils down to communication. Good luck!

Answer 11

have a regular (weekly) presentation of some tech topic, and have it rotate around the group. That way everyone will learn something. And let the younger members present too, there is no better way to really understand something than by teaching it. You may have to help them choose topics.

Some coaching on how to give a talk may be in order for everyone. I had a prof in college who did that for me and it was very helpful.