Should Programmers Also Provide Customer Support? Eight Tips We Learned.

My job tried that the first few years I worked there and it was a nightmare. Yes, as a developer I knew the software better than anyone else and could provide quick and effective support, but it was detrimental to my coding. For example I'd be in the middle of thinking through a process and get a phone call and the call would completely take me out of the mindset of the problem at hand, since I'd have to focus on the customer. After that it would take many minutes of reading through code or looking at diagrams to get back into the mindset of the problem, what happens then if I get another call; the process starts over again. In addition to the time spent on the phone, many calls can easily be an additional 15 minute time sink.

I wasn't the only developer who felt this way and after enough complaints from almost every developer they changed the policy to have support and development separate (with the developers being available to help with support problems, but only after support attempts the problem first). I don't see any reason to ever disrupt development for a trivial problem, there are better hires for that.

Personally, I like immediate responses from a support person who can run issues by a developer if necessary. Developers shouldn't have to spend any time walking a user through logging in, helping explain how to import data, etc.

I don't see support as a valuable use of developer time, and I don't think that developers should patch code on the fly in response to a single support ticket.

I also worry that what might be a well-meaning response with a few technical details can come off as very condescending.

If you're a small team and you don't have a dedicated client coordinator or support person then of course your developers are also support -- you don't have any options. If you do have options it's best to have someone between the customer and the developer. If for no other reason than to screen common/simple issues and ensure a timely, polite response.

If programmers ever do provide customer support, I think they should probably never be expected to do both during the same time period, and possibly not even the same work day.

The economic benefits of specialization are such that even if developers can provide awesome support, they should be doing the job they are best at--software development--as much as possible, and the support should be handled by a person better at support than software development. The workload might not balance out perfectly such that each person does exclusively one job, but there is no way in hell you should be attempting to handle customer support without at least one customer support specialist.

Let the developers support that person if necessary, but be aware that pre-empting them with support-task interruptions will send your regularly scheduled development to Hell with all the losses from context switching.

And do you really want to pay developer rates for customer support work while constantly giving your employees work completely unrelated to their self-image or career growth? It's fine for them to be involved with support, but they cannot be responsible for it.

My previous job required quite a bit of customer support at the beginning, which tapered down to almost none at the end (out of necessity). I just couldn't get my development done.

It was almost always hosting type help, and development slowing down was a huge issue.

I learned a lot, but primary that I'm not interested in doing that kind of support at all. I'll simply turn down jobs that require it of me, and it's something I ask in interviews. Some personnel support is fine, and working with the UX department doing testing is welcome (and encouraged on my part), but answering calls to help people set up their outlook or helping them reset their password? No way. Not my cup of tea.

I found doing tech support for my software to be a very valuable experience. It wasn't nearly as disruptive to my coding process as some of my brethren seem to find it; perhaps because when I'm puzzling out a thorny issue, I tend to take copious notes--and let the phone go to voice mail if I think I'm on the verge of a breakthrough. And being the first person to speak to the users who have issues, you can very quickly sort out the user-education issues from the UI/UX problems.

It was also always good for a smile when a caller would ask if I was familiar with the system. I was, I would say, reasonably familiar with it. Then they'd start explaining to me how it was supposed to work. I let them, because hearing their interpretation of the system narrative gave me valuable insight into how my users' minds approached the problems that my software was intended to solve.

I also wrote my own User Guides, reference manuals, and training material. Who had better understanding of the system than I did?

After mentioning the usual "Betteridge's Law" implications, my answer is "if they do, then the company should account for the time it takes and set release dates and such appropriately." Support is not something that can be just added to responsibilities without consequences.

Depends on the company size.

For our startup, the answer is a resounding yes. As a matter of fact, extend beyond customer support -- go to Sales, Marketing, and whatever other departments matter. Not permanently, but enough to get familiar with that aspect of a business.

It goes to being well-rounded, and I find too many developers who simply aren't. Show me somebody who wants to stay in their own world and doesn't care to understand the other components of the business, and I'll usually show them the door.

I worked for a small software company that had a good system. Programmers, especially customer-facing consultant programmers, rotated through the support group for... I think 9 month stints. (it's been awhile). It was great experience to see real-world uses and issues. I think it stopped after we were bought by a much larger software company.