Below is a short list on how I believe managers can foster a good software development team.

1. Fire bad programmers (and don’t hire them)

I decided to start with the controversial one; however it’s one of the most important. Nearly every team I’ve worked on has had someone on it that should have been fired but the company just wouldn’t do it. There are many benefits to be made from firing the bad programmers, some of which aren’t immediately obvious.

a. The obvious one is that bad programmers add bad code. This in turn causes more work for the rest of the team, adds to maintenance time and pushes deadlines back. This also leads to software entropy where good programmers will be forced to work with bad code which often encourages other bad code.

b. They bring the morale of the team down. Any good programmer can pick a bad programmer after only a few weeks of working with them. It’s very demoralising to be forced to work with someone that is no good, particularly if they are getting paid just as much, or more than the good programmers.

c. They teach bad habits. Keeping bad programmers on gives new programmers bad influences to look to for support. By letting them stay on within the team, managers are basically saying that they don’t mind having bad programmers working for them. It makes it hard to foster good quality coding standards when members of the team are openly ignoring them.

The only caveat to this is mid-development of a product. It may be detrimental in the short term to remove bad programmers immediately; however this often turns into apathy where the programmer simply stays on to the next project or milestone. Look at the schedule and actually mark off when the time is right to remove them. Once this date comes around bite the bullet and get rid of them.

2. Give rewards

I’m surprised how many programmers when asked how work is going will mention certain perks or rewards they receive from their bosses. This can be anything from having a few days off after record profits to free food/beer/game nights once a week. One of the biggest problems with ‘working for the man’ is that there’s no direct connection between the quality of work programmers do and their rewards. This was one of the key points in Office Space and every programmer I speak to has had this problem at some stage in their career. The main purpose here is to tie the success of the company to the employee’s that are creating this success. It can range from profit sharing to simply taking everyone out for a big meal (with free drinks for those inclined) after meeting a big milestone.

In the grand scheme of things it doesn’t end up costing much, and the productivity benefits returned will easily pay the rewards back many times over.

3. Give good direction

There’s nothing worse than having a project that’s just aimlessly drifting towards it’s goal. There need to be set goals that the entire project is working towards as well as sub-goals for each individual team. Programmers are logical, methodical people and they like order in their lives. The more you can make the project’s direction fit in with this view the more the programmers will ‘buy in’ on the future direction.

Programmers will look at the project as if it were a program in itself. There’s a bunch of commands the team is following (create the UI), with conditions (if there’s time, add in flashy feature 53) and iteration (each milestone). If you can learn to think like programmers do and show the direction of the project in a way they’ll understand you’ll see productivity gains.

4. Be transparent

I touched on this in an earlier post, so I’ll keep this one short. Basically let the team know what’s happening within the company. You don’t have to give them every detail, but make sure that the important information is propagated. This can be as simple as a company newsletter or an internal website that has the news. Those who are interested can stay up to date and others who don’t care can just ignore it. People often worry about their jobs and not knowing what is happening can often lead to a drop in productivity.

Conclusion

I’d like to hear from people if they have other ideas or whether people agree or disagree with my list. As things move forward with the business we’re hoping to set up a software team in the near future so I’ll start posting on how implementing these and other ideas I’ve blogged about works out in reality.