Negative Developers and Team Stability

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 moral 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 that 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, not having to put in as much effort will eventually start to slow down and equalise 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 its’ 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 realising 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 labour 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 organisation 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 labour 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 normalise 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.

Agile – Specialisations Still Matter

I originally posted this to #AltDevBlogADay on Friday October 28, 2011.

SpookyI recently came across an interesting post over on Agile Game Development titled ‘Scrum Prohibits all Specializations’. The part that stuck me was the following:

I understand that Scrum has been applied mainly to software products and that the elimination of “specialties” means that the database programmer, UI programmer and QA engineer should all be able to perform each other’s roles equally. This is valid.


Now I’m concerning myself with only the technical side of an agile team but I’ve seen this raised in a number of different agile circles. In those cases there seems to be the impression that swapping a database, physics or audio developer with any other specialisation like UI, animation or graphics and an agile team should be able to roll up their sleeves and perform the different roles to the same level with the same level of outcome.

To me, this is emphasised in how the product backlog is often used, which is a priority and risk ordered document that doesn’t take into account the skill set of the team that’ll be working on the final product.

Processes such as pair programming, constant re-factoring and code reviews (to name but a few) seem to be seen as ways to not only communicate intent and project information but also skillset and ability across an entire discipline.


So What Do Specialists Bring?

But we have specialist developers for a reason. They are great at what they do, they understand the area in which they work and they know how to get the best results in the shortest amount of time. They have a passion for the area they are focusing in which usually means they’ll go a step further to research their area and keep up with developments which other developers may not have the time or the understanding to do.

By spreading your talent thin and assuming that people can fill each others shoes leads to the following issues

  • You are not respecting the knowledge, skill, experience and passion that a specialist can bring to their work and as a result not respecting the developer themselves
  • You’re reducing the impact these people can have on a team and it’s often the experienced specialists that inspire younger members of the team into an area they are interested in
  • The ability of those specialists to learn more about their area and pass that onto others is drastically reduced.
  • The ability for the team to push their development boundaries will be indirectly reduced as everyone on the team aims for the ‘generalist’ role to fit in


What About Pair Programming?

Now I’m a massive fan of the various agile techniques out there. Pair programming is an excellent mentoring, development and training tool but it won’t allow one developer to fit into the shoes of another. True, they will have a better understanding of the tools, pipeline and systems being developed which will allow them to fill in, but it won’t transfer the amount of background experience the specialist has.

The same goes for code reviews, constant refactoring and feature discussions. It spreads the knowledge which reduces the risk to the project should the specialist not be around when needed, but the core experience and drive that made the specialist who they are simply cannot be replaced by dropping in a new developer.


But Everyone Does A Bit Of Something Every Once In A While?

Of course, sometimes people do need to jump into another developers shoes (illness, staff turn-over, hit by a bus etc.) but this is not the same as expecting a people to be able to fulfil each others roles equally. We can take steps to decrease the impact this will have on the team using the processes mentioned above but it will not allow those specialists to be inter-changed as the project continues development.

We need specialists in any development field because it’s these people that can push their respective fields in directions we might not even be able to imagine. By treating them as interchangeable we might be gaining flexibility to schedule our staff, but we’re losing something far more important and vital to a development team and the products they are creating.

As I said to some one (in 140 character or less of course) when pointed out that people have done this, and even the author of the original post has done it (see the comments)

I’m sure he has done it, I’ve done similar, but it doesn’t mean we did both with the skill of an expert of either.


PeopleWare – Read it

For the past month I’ve been reading PeopleWare, and I have to say it’s one of the most honest and relevant books on management and the work environment I have ever read.

If you are a manager, are aiming for management, or even if you’re not but want to make a difference in your work-place, I beg you to pick up a copy and see what you think.

Not everything will be relevant to you, and some of the things it recommends will be totally impractical for your situation, but as the book recommends, start small, change things little by little and it will make a big difference in the end.