
Should Programmers Also Provide Customer Support? Eight Tips We Learned. - donedone
http://www.getdonedone.com/programmers-also-provide-customer-support/
======
towlesda
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.

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

~~~
ef4
> Developers shouldn't have to spend any time walking a user through logging
> in, helping explain how to import data, etc.

I actually find that spending such time is one of the few effective ways to
reliably show developers where their user experience is poor.

If your users keep asking the same question, it's not their fault -- it's a
problem with the software, and developers need to be the ones to fix it.

~~~
will_work4tears
Bug reports do that just fine though. I don't need to physically run the
person through the login process, a report or series of bug reports can clue
me in just fine.

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

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

------
R_Edward
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?

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

~~~
will_work4tears
I agree entirely. If I were forced to do support calls 6 hours a day, I'd
rather not be expected to make those 6 hours up developing off hours.
Especially to meet deadlines that don't take the support into account.

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

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

~~~
will_work4tears
This seems more reasonable. I probably still wouldn't take said job, but
certainly more likely to do so than if I were expected to Develop and meet
timelines without taking support into effect (not the case at my last job -
which was odd because I wash hourly).

