How to you "sell" support as an career option [closed]

Question

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

Answer 1

Don't

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.

Answer 2

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

Answer 3

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.

Answer 4

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".)

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.