How to keep business support team motivated?

In the course of my career I've noticed that developers working on new functionality are, as a rule, more cheerful than these assigned to troubleshooting and fixing bugs.

Good tips on keeping business support a happy? Organising business support in the way that team's morale isn’t hurt?

From stackoverflow Totophil

• I have seen this too. There are few approaches that I can think of:

  1. Give some thought to selection process.

  Not everyone have same career aspirations. While some people are always dying to work for the latest technology and challenging projects, there are others who are content at a stable work environment. Picking the person with right KSA (Knowledge, Skills, Attitude) is always central to good person-job match. In this case, you just need to put more stress on the Attitude part.

  2. Choose the right lead

  Team leads play crucial role in controlling the motivation and morale of the team. There must be an open and frank channel of communication with team lead and upper management. Ideally a person from the senior management should be made the owner of the team in formal organization chart. Team lead should actively try to foster a team-culture that suites the nature of the team.

  3. Rewards

  Rewards off course are key tool for managing motivational issues. Just make sure the person receiving the rewards understand that the nature of job was also taken into consideration in decision to reward. If this point is not addressed, it is likely that the person will not take this factor into account when perceiving internal equity.

  From Tahir Akhtar

• If we start with the assumption that the reason for new function developers being happier is that they get to feel proactive or in control and the troubleshooters are reactive and pushed around by the users one answer comes to mind:

  Create a model for those doing troubleshooting to fixes to generalise these from point fixes into broad, consistent fixes for a class of problem. This puts them in the situation of creating new code, even if not new functionality, and they get to think a problem through and anticipate and avoid problems rather than playing whack-a-mole.

  In fast moving environments it may also be possible to rotate people through the job descriptions by have them follow their feature from new development into fix and realease and hopefully into version 2 of the feature.

  que que : This answer is incredibly well thought out and so well put! I wish I could give this 10 up votes.

  MarkJ : Let them refactor.
  From Bell

• Our organisation has a substantial amount of support work and we've got hit with this problem really hard. The motivation on support teams could dropping down exponentially over the time if you don't do it right.

  The principles which worked for us were:

  1. Choose the right people. Some people are happier doing new stuff. Some people are actually much more suited to a steady no-nonsense job. It means that you should have two teams - one for development and one for support. Developers only stay on a completed project until they pass their knowledge to the supporters.
  2. Choose the right leader. Good organisation is make or break here. A good leader would help to organise good relationship with the product users and at the same time will care for his team.
  3. Rotate. We try to keep the support people on the project for a period of less then 2 years and then move them to something new. This helps maintaining proper morale and ensure that their skills don't rust.
  4. Relationship with the customer. Make sure that the support team know how valuable they are. The customers/users should occasionally visit the team or the team should go on-site to have a face-to-face session with the users (a friendly dinner or lunch will also help)
  Totophil : Ilya, whilst I strongly agree with many of your answers I am not sure that splitting developers into development and support groups is the best approach. Then you get a tendency for project teams to push things, hoping that they will get fixed as support by a different group. To be cont.

  Totophil : Secondly, dedicated support team often would fail into the trap of looking for quick fixes and not having the influence on the big picture. Their motivation is usually to keep their job (more issues), faster response times (i.e. curing symptoms, not root cause), higher throughput

  Totophil : that can be achieved throught solving repetitive issues they already know to fix. Thirdly, dividing development and support functions you pretty much shield the developers from actual feedback and pain of the real-world software needs.
  From Ilya Kochetov

• Following Bell's suggestion, consider letting new or junior developers cut their teeth on fixes. Promote them from maintenance to the feature team based on their performance and ability.

  Healthy competition is also a good motivator, but it must be managed to remain a positive influence.

  From Adam Liss