Creating Good Software Development Teams
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.
Feed
Subscribe By Email
Twitter
I’m behind you 100% on these points. I’ve worked in environments that uphold these ideals and I’ve also been unfortunate enough to work within several companies where the stick is used liberally in preference to the carrot. Guess which ones are regarded as globally successful and which ones are struggling to be regarded as… well, as anything at all…
I don’t think any of these points apply only to programmers, morale and team spirit are contributing factors to success in most working environments. Bad apples always spoil the batch and a little appreciation goes a long way.
One thing I would like to add is that you shouldn’t secretly reward select team members. This actually has a negative effect rather than a positive one, the rewardee feels dirty and is forced to lie to his or her colleagues and, should they find out, there is massive potential for undermining the team as a whole. Reward the team or at least be open and honest about why you are picking individuals.
People are both the best and worst part of work. As you say, they can provide the productive and fun environment to collaborate together, or individuals can poison the experience to the extent that people don’t want to come to work and have to deal with another person. Firing a person is a difficult decision because it affects a person, but it must be done and done as soon as possible before it affects a whole team and the financial viability of a product or company.
Once a team works together they need to stick together. The synergy of a great team is something that has to be seen to be believed. Unfortunately my experience in the games industry has been that teams are often mashed together based on current staffing and desperate hiring, then after a project, the team splits up or is split up (assuming it was a good team), partly due to poor management, partly due to the financial success of the project and company, and partly due to the incredibly short times game developers stay at a job or in their industry (likely due to poor quality of life http://www.igda.org/qol/whitepaper.php).
Chen-
I agree completely with your thoughts on rewarding individual team members. I’ve seen this happen, and it often feeds off itself continually getting worse over time. If managers follow point 1 then they should only have good people left and therefore the entire team does deserve the reward together.
Greg-
I think the burnout factor is a key part of the problem within the game industry. With an average stay of 5 years there is little room for developers to grow both as individuals and within a team. I’ve seen first-hand how well a team can work together and it’s a sight to behold.
I agree with your points, and especially about 3 and 4, they are a must for team morale.
As a corollary to point 3, I’d say it’s important to plan team growth ahead, down to the design and implementation details. Let your programmers know which parts of the work will have to be shared with new team members, and when, so they can layout some structure. Having unfinished parts of your work unexpectedly dispatched to someone else makes you feel uneasy, just like having to monitor someone else’s work without prior research on the topic. Easier said than done I guess.
Also for point 4, the lack of such communication not only impedes morale “Why didn’t they tell me? Am I not worth it?” but it also allows for company gossip, which can often be way worse than the real thing.
Finally, I’d say that being consistent is important too. When a decision has been made, follow it up. And if you change your mind, share the reasons why. But that’s kind of a mix of to the two previous points.
(btw this cartoon picture is really cool)
Drealmer-
I couldn’t agree more with your points, particularly “being consistent”. I think managers often forget what it’s like to be an employee and don’t realize the reassurance required. Most of what managers do is hidden away and therefore they must be careful to make sure the small external interface they have is consistent and positive.
I’m glad you like the cartoon you can check out shauno’s other projects here
Just wanted to ask a question regarding #1… This is coming from an unexperienced game programmer in the making.
Any thoughts on helping the programmer out before letting him go? Of course he would have to be cooperative and the company have the resources available, but I don’t see why we would have to get rid of any position so as their work improves and attitude is right. If they don’t want to be “helped” then I can see why.
Mig-
Perhaps I should have been a little more specific with what I class as a “bad programmer”. By bad programmer I don’t mean inexperienced programmer, nor a programmer that makes mistakes. For an in-depth explanation of a “good programmer” see my blog post here.
Basically if someone is in a position they are not experienced enough to be in, or are simply slacking off then they need to be removed from the position. I could have said that they should be demoted to the position that suits them, but realistically, I don’t think this works. If a programmer is struggling, but is willing to learn and become better, then they are no longer classed as a ‘bad programmer’ and the team should work together to help this person reach their potential.
A lot of the issue comes from programmers that are too proud to turn down a position they are under qualified for. All of the very best programmers I know have been offered positions beyond their ability and have turned them down. I see bad programmers being the ones that take on responsibility when they know they can’t fulfill the role, simply to get more money or power.
I noticed you didn’t mention anything about actually not hiring bad programmers in the first place. Who let the jackass through the door?
Experience is only part of the equation. The goal of a job interview is to look beyond to check the fundamental skills Doolwind listed in his “Qualities of a good programmer” article. As of “who let the jackass through the door”, I’d say it’s more complicated than it sounds. First, you can hire a good programmer that will turn bad a few years later (then you might have to ask yourself if you don’t have your share of responsibility for letting that happen), you can also be fooled by experience (“this guy worked on xyz, he must be good”), and finally there are times where you just need manpower: right here, right now, and you don’t have time to pick the cream of the crop. I agree that this last point is usually a bad idea, but let’s face it: that happens.
cowlibob-
Very true! Prevention is better than cure. I’ll update the title of that section to better fit what I mean.
You can be fooled by experience, but that’s what a probation period is for. People going bad after that time is a different story. I believe that firing them is the last resort though [but sometimes the only choice]. It’s the responsibility of the leader(s) and the whole team to bring this person back into line.
When we have someone in department that is slacking, I let everyone else in the department know. And then we encourage this person to work hard. Not by telling the person, but by paying attention and helping them and giving them moral support and assistance. This usually solves most problems. If a programmer continues to be a bad apple then you move up to the HR department and try and resolve the problem.
for me, more than a bonus I want the feeling of satisfaction for completing a great project and achieving it with your co-workers. That’s what a team is all about. Attach that to Doolwind’s ideas of how a business should treat staff and you have a great team who will make and deliver a great project.
You seem to be a specialist in common sense posts
A pity there is not much common sense spread around evenly in the world. I will browse your site more now since I discovered it.
This comment isn’t specific to this post, but I must say you really know your stuff, we certainly have some talented people in Brisbane.
Thanks Dean, I’m glad you agreed with my thoughts. I should have a follow up to the post soon as I’ve come up with a number of new ideas.
I think bad programmers are particularly difficult to spot, partly because of the Dunning–Kruger effect: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect