Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
April 19, 2014
arrowPress Releases
April 19, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


Opinion: Negative developers and team stability
Opinion: Negative developers and team stability
October 9, 2012 | By Lee Winder

October 9, 2012 | By Lee Winder
Comments
    7 comments
More: Console/PC, Business/Marketing



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.]


Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.19.14]

Associate Art Director - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.19.14]

Associate Animator (temporary) - Treyarch
Activision Publishing
Activision Publishing — Vancouver, British Columbia, Canada
[04.19.14]

Principal Graphics Programmer
Activision Publishing
Activision Publishing — Santa Monica, California, United States
[04.19.14]

Executive Producer-Skylanders










Comments


Edward Bowman II
profile image
Great Read!!! i agree with what you have said here. Negativity is horrible to have in the workplace.

Jon Smith
profile image
I've also noticed most bad eggs can be extremely good resources if all they get is a little appreciation. I've now always made it a point to highlight everyone's good qualities more readily (however small I think it is) and implement the 3-strike rule for bad actions. This has tremendously improved the morale of my team in UK.

Dave Smith
profile image
i hope some of my bosses are reading this. negativity is a cancer.

Brian Stabile
profile image
I wouldn't want my employees to feel they have to feign happiness or pretend that they're enjoying everything their job entails in order to keep their job secure, but if they have no faith in the end result of a project, they should most certainly be removed from it.

Lyon Medina
profile image
Great read. Of course I think that firing someone should be situational, but ultimately should never be taken off the table.

Joe McGinn
profile image
I know what you mean, a negative person can be poison for a team ... and it can sometimes just be the person, I've seen that.

On the other hand, I also look at programmers kind of like mine canaries, ad a baramoter of team health. They are typically intelligent, introspective, not overly emotional people. I have seen on many more occasions that what they became negative about were real, valid, and usually longstanding problems on the project or the team.

Ines Beldi
profile image
Interesting read. I noticed negativity will spread really fast to new members of the team as well if work conditions are not great and there's nothing done about it. They don't even need to be impacted by the conditions that much, but the general feeling and gossip will get to them in no time.

Unfortunately, well being in the work place is not always a manager's top priority, especially in small, new companies where the bosses can have a lot at stake. It's a never ending issue if not adressed properly: unhappy members are fired, new members are hired, they become unhappy...etc.


none
 
Comment: