In this reprinted #altdevblogaday opinion piece, Blitz Game Studios' technical manager Lee Winder looks at how "negative developers" can impact your team, and how to turn them into positive contributors. It doesn't take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise morale and motivation. The following isn't based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years. Take of that what you will… When you look at the make-up of a team, it will always be staffed by people who raise the game and by some who only bring it down. It's the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It's the individuality of these people who can take a project and make it fly or cause it to crash and burn. One thing that's clear is that it's much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild-fire through a team whilst positivity acts more like treacle and can be much harder to spread around. But why? A negative attitude to work is a whole lot easier. Doing less, talking badly about the team, or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.

What defines a negative developer?

There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low-level complaining, pushing back against work requests for no good reason, or general slacking off during the day. It could be a lack of skill development or even a backsliding in the quality of the work they are producing. But it could also be an attitude that doesn't gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it's designed and implemented, and one or two developers will only work when they are told exactly what they need to do. Maybe it's a developer who doesn't get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing. At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They're the ones who are difficult to deal with in usually many aspects of the development process…

Team development

Lets have a look at a few situations where a green developer is a 'positive' developer, red a 'negative' one. In the first situation, we have two developers working side-by-side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don't want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer. In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard and not having to put in as much effort, will eventually start to slow down and equalize with the poorer developer. It's much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one. When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn't very encouraging. Take the following situation: Theres a tight balance here, but since it's much easier for a developer to reduce the quality of their work rather than improve it, it's easier to slide the wrong way, and at that point it's very easy to see where this will go. Based on a number of observations, it seems at though while a 3:1 ratio might get you some good results, it still brings risks because should one developer start to slip, it then becomes 1:1, which puts us right back at the start. In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases, the negative developer didn't change their attitude without help, but other developers didn't slip due to the peer pressure of the other better developers.

Positive developers

But in all these situations, I'm not giving these positive developers enough credit. A good developer won't always slack, they'll continue working hard, producing great content and generally continue to fly high. But take the following situation… These developers are good for a reason, be that personal pride, ambition, or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable. Great developers won't stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave, you have a much higher chance of those left realizing they don't need to actually work that hard to get through the day.

Solving the problem

There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you're working in a region with sane labor laws. Just drop them. To be honest, I wouldn't recommend this anyway. Simply letting someone go generally removes the problem, but it can leave a lot of holes on the team, and you hired this person for a reason, why not try and get that spark back? Performance Management structures (you do have a Performance Management process don't you?) within an organization can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team. Identify the source of the problem. Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated, or do they just not want to be there? Depending on what their answers are, you'll have a good idea of where to go next. Make sure goals are set. Define goals designed to turn the situation around, but don't just set and forget about them (which happens far to often). Monitor them on a weekly or bi-weekly basis, setting very short-term goals to complement the longer term ones. Define a fixed period of time. Don't just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious. Make it clear what the end results will be. Whether they are the chance to work on something different or whether it's a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed. Keep constant records. Make sure every meeting is documented and the progress or results of all the goals are recorded daily. Let them go. While it is drastic, if improvements are not being made given all the opportunities you've given them, then there really is no other option. If you've bent over backwards to try and solve the problem and the developer hasn't taken you up on the offer, then there really is nowhere else to go. And even with those sane labor laws, the documentation you've been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn't want the help. So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers. Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalize at a level far below where they need to be or will simply leave. It's vital that as a group these developers are tackled fast, rather than when their effects start to be felt. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]