We find it relatively easy to hire developers to work on various projects.

The problem arises when the project is finished but still needs to be supported.

We really battle to get people to join the support team. It's seen as dead-end, career-limiting, boring, second-class etc.

Currently, we get round this by getting the project team to assign some of their team to the support team for a while. Part of the assignment is to do a "brain dump" of the project so that the support team understands it. This works as long as the assignment is only for a fixed period.

Trying to hire people to work in support full-time is a problem. There are few applications and the calibre is not particularly high.

(The financial reality though is that support can be very lucrative for a company and once you get a reputation, you get approached by other companies to do their support even though you weren't involved in the original development.)

  • 8
    "It's seen as dead-end, career-limiting, boring..." - Because it usually is. Developers are often creators, and support, by definition, doesn't create anything. Commented Oct 14, 2010 at 17:07
  • Can you define support as you mean it? Is this including bug fixing or everything up to but not including that point? Commented Nov 10, 2010 at 16:26
  • It would include bug fixing.
    – rbrayb
    Commented Nov 10, 2010 at 18:33
  • Good full time bug fixers are rare, but they exist. You just have to be very attractive as a company overall and go through many honest (because many would leave soon otherwise) interviews.
    – Job
    Commented Oct 13, 2011 at 2:46

10 Answers 10



To me the best option here is not to separate the developers into support and non-support in the first place. IMHO there are three main reasons:

  • people that write things that are hard to support do not learn until they have to support these things.
  • people doing only support will usually take the path of least resistance in correcting an error even if it hampers future work.
  • the theoretical time savings in staying on schedule in the new development by having the separate support developers is always more than consumed by having to provide instruction or repeat work.

Within the dev team you can have people that have maintenance tasks or take an approach of letting the maintenance tasks be the training grounds for the newer team members, but if you try to sell it as the long term goal of the position you will only attract people that will give you heartburn or people that will soon be on their way out.

There always needs to be a clear path to getting out of a 100% support dev role, and/or a certain percentage of new development work to keep good people interested.

You do not want to attract the sort of people that are happy in that role indefinitely and you are never going to convince otherwise good devs to take that role and keep it long term unless you are offering the kind of pay that would never have them considering a career move.

  • This doesn't resolve the basic problem where we have a team on project A. Project finishes - team split up. Project A has a problem - people need to be taken off other projects to fix it. Hence the idea of a support team.
    – rbrayb
    Commented Nov 10, 2010 at 18:37
  • 3
    You will always have that constraint. Even if you have a separate support team you are loosing the original dev team member's cycles doing the documentation and handoff and the second tier support. IMHO it is much cleaner, and more attractive to the staff as a whole if this lost time is just a metric that is figured into the estimates of projects going forward rather than having a second class dev team that is always trying to catch up and only works on the problems created by the first class teams. I have never seen the support dev approach work well. It always generates staff churn.
    – Bill
    Commented Nov 10, 2010 at 19:12

Make the support job fun and valuable to your developers.

I love to do support for the following reasons:

  • I talk with people all around the world. I made many friends like that. Few years ago, one of my customer invited me to his wedding! I used to have a map of the world in my office with pins that located them.
  • Support is almost the best get gratifications for your work. When you make users happy, it really makes you happier too.
  • Complaints are useful way to improve yourself. I take any complaint seriously, and in most case, I can convert someone angry into an happy customer/user that will eventually spread the word around.
  • It helps me understand what customers/users need. Then I can build better software.

That's just few reasons.

Regarding support itself, I suggest to implement an easy to manage process.

When we get a support case, we do the following:

  • If it's a reproducible bug, we add it into the backlog and give its ID to the customer/user. We also take the ID of the customer/user to notify him of resolutions and release personnaly. This is easy if you collect his email directly.
  • If it's a problem using the software, we take this as an opportunity to improve the documentation. Any answer is written like a knowledge base article that we add in our database afterwards. It takes triple the time to write, but we don't repeat ourselve later (most users prefer browsing in KB).
  • If it's a feature request we connect the user with the product owner directly. This is very valuable. Of course we use systems like uservoice.com, but talking with the user directly is a lot better.
  • If it's a complaint we try to manage that outside the process. People that complaint like to be considered as important (even if the complain is trivial).
  • +1 for support as the best way to find out what the customer really wants.
    – AShelly
    Commented Oct 14, 2010 at 15:43
  • 3
    Don't even refer to role as a "support developer", use something that will motivate like "refactoring engineer" and encourage them to also be creative in what they're dealing with/improving. Commented Oct 15, 2010 at 3:49
  • @Nick Josevski - Definitely, giving the freedom to develop improvements / refinements to the existing system means that 'support development' isn't merely 'make it work when it breaks'. My first development role was support / maintenance (although I did enjoy it alot when I first moved onto actual project work). Commented Aug 1, 2011 at 7:17
  • @Pierre 303, I suspect that not everyone is like you. I bet that introversion vs extroversion is a part of the equation.
    – Job
    Commented Oct 13, 2011 at 2:44
  • I give more details here: pierre.mengal.eu/2011/09/27/in-praise-of-technical-support
    – user2567
    Commented Oct 13, 2011 at 6:21

Why not just pay the support devs 5 or 10k more than the build and forget devs?

By attaching an extra premium to support roles; in recognition of the additional challenges of "customer liasion" and "production code maintenance"; you'll not only provide extra motivation but more importantly the roles will be seen as having more prestige. After all a higher salary must mean a more important role and even if that's not the case it will be preceived that way.

  • I don't think this will improve retention. Sure, you'll get more people signed on, but once they've banked some cash, they'll leave. Some studies have shown that money only really matters when you don't have it. Doubly so for 'knowledge workers'. Commented Oct 14, 2010 at 17:06

If you think that support is a second-rate job, you'll likely have trouble hiring people for it. If you treat it as a career-limiting and dead-end job, you won't get good applicants.

Support isn't generally seen as as much fun as new development, and if you've got separate development and support teams the support teams have to take what development gives them, which is often not fun. (I worked at a place once where R&D would hand us some software that did something cool, but which typically needed redesign to be production-quality, and we didn't get enough time to do that, for political reasons. That wasn't fun.)

If support really is business-critical, you have to treat it as such. If you insist on having separate support teams, and it's important to have good ones, you need to address these issues. Make sure there's a career path up. Publicize the money you're making from support, partly for their self-esteem, partly to make other people realize their value, partly so they can put dollar figures for their activities on their resumes. Establish standards, and allow the support teams some input in whether a project is ready to go from development to support. Since the job is less fun and possibly more important, pay them better. (I'd have more sympathy with managers who complain "we can't get the applicants we need" if it didn't usually translate as "we can't the the applicants we need cheap".)


While I agree that being in support generally does suck, many developers might actually enjoy the prestige that goes along with the "ownership" of the project, even if they did not write the software themselves. That programmer becomes the goto on that project, and they really do become an invaluable expert on the system. While I am primarily involved in new development at the company I work for, many of my colleagues who are more than competent actually are quite respected for their maintenance of our most mission critical software. After all, the software currently being supported is probably the one currently making money (a bird in hand is worth two in the bush).
I would just say that not everyone sees support as a terrible dungeon job for sub-par programmers, and I would play off that sentiment to attract more people.


A few thoughts:

1) You say it's seen as dead end and career limiting. If this isn't true and people have gone on to other things (development, project management, running the team) then I'm sure you've got examples you can use. If you don't have examples then you might have to accept that it is dead end and career limiting and need to address these issues.

2a) If support includes bug fixing then why are they separate? If someone coded it badly to begin with then what are you teaching them by giving their mess to someone else to sort out. Moreover if the support developers aren't seen as as good as the developers how on earth can you expect them to fix what the developers couldn't get right? Seriously the rule should be you wrote it, you fix it.

2b) If support doesn't include bug fixing then they're very different jobs and emphasise different skills. You shouldn't be worrying about cross over here any more than you worry about cross over between development and cleaning.

3) You say it's lucrative for the company - then make it lucrative for the people involved. This might be through better money, better training, better kit and giving them everything they need to do this stuff really really well. If there is money available make it a great job.

The issue from reading your post is that you don't seem to believe it's a good job. If that's true then no wonder you can't sell it as one.


Support is a difficult job, no body likes to listen to people complain all day. Finding good people can take time but once you have then you need to keep them by

  1. Pay good money, even well above industry rates to keep good people
  2. Provide good working environment, little things like work supplied lunch and drinks help
  3. Don't cram all your support staff into a small, noisy room

I think zappos.com has shown that a job doesn't have to be crappy when you work for a good company. The worst part of being in support is not being able to help someone. If you screwed users over with service contract fine print or shipped buggy software that won't get fixed any time soon, support will suck. They need to be encouraged to find solutions to problems; sort of like programming.


I did support for a couple of years for my first company out of college. What got me to sign up for a couple of years was:

  1. The required career path for becoming a Software Engineer.
  2. I needed the time to brush up on the company's main language (Fortran, Circa 1989)
  3. I wasn't married so I could quit if I found I didn't like the company or the job.

How about some mixture of development and support (split roles)? I think you'll still struggle to get buy-in for that because of reasons already mentioned (developers != product support people). But if your product relies on a wide understanding of internal technology, maybe 80% development, 20% support would be a fair tradeoff. Or some kind of mentoring/shadowing for new employees to ensure they get correct information about the product.

Not the answer you're looking for? Browse other questions tagged or ask your own question.