If You Want to Write Useful Software, You Have to Do Tech Support(nick.typepad.com)
nick.typepad.com
If You Want to Write Useful Software, You Have to Do Tech Support
http://nick.typepad.com/blog/2009/06/if-you-want-to-write-useful-software-you-have-to-do-tech-support.html
10 comments
And the corollary, from the customer's perspective: The best possible person to get on the phone is a developer with commit access.
I would second your thought. I worked for a enterprise software company that had developers building the product, a maintenance team that fixed bugs and 3 layers of support.
The only people who knew what was going on with a huge product were the developers who actually wrote it. But you had to go thru so many layers to get to the developers, irrespective of silver or gold or platinum support. I would never ever pay for support of another product that comes from a big corporation.
We went opensource with our products and every developer responded directly to questions from customers. It made a big difference to the users.
The only people who knew what was going on with a huge product were the developers who actually wrote it. But you had to go thru so many layers to get to the developers, irrespective of silver or gold or platinum support. I would never ever pay for support of another product that comes from a big corporation.
We went opensource with our products and every developer responded directly to questions from customers. It made a big difference to the users.
I don't think open source is the particular answer to the problem you state, I think it's an orthogonal issue.
If you have millions of users who want to ask questions (think of supporting Microsoft Office), then direct access to developers is a non-starter.
What I have seen work are rotation programs where developers spend some time as first-line support (maybe 1 week per year). When doing so, they help educate the rest of the support staff, and they get great exposure to real users facing real problems.
If you have millions of users who want to ask questions (think of supporting Microsoft Office), then direct access to developers is a non-starter.
What I have seen work are rotation programs where developers spend some time as first-line support (maybe 1 week per year). When doing so, they help educate the rest of the support staff, and they get great exposure to real users facing real problems.
> What I have seen work are rotation programs where developers spend some time as first-line support (maybe 1 week per year). When doing so, they help educate the rest of the support staff, and they get great exposure to real users facing real problems.
This skirts the real issue, though, which is that the person you get on the line should have the power to fix your problem. Putting developers on first-line support would only help if they were still developers while they worked there, with all the same access privileges and tools available to them.
This skirts the real issue, though, which is that the person you get on the line should have the power to fix your problem. Putting developers on first-line support would only help if they were still developers while they worked there, with all the same access privileges and tools available to them.
One of the reasons often cited for the structure that existed was 'it would distract developers working on the product from meeting the deliverables'.
There is a role for support on a complex product where user errors often are the reason for tech support calls.
However, If you have a problem that requires code fixes, I cannot imagine having to deal with a long line of people who have no power to make those changes.
However, If you have a problem that requires code fixes, I cannot imagine having to deal with a long line of people who have no power to make those changes.
If a lot of users make the same error, then a fix in the code is required.
Incredibly, I heard similar words when a tech support rep called me with an irate customer on the line. The customer's words: "I've called 3 times and tried 3 different approaches. There's clearly something wrong with this f*ing piece of shit. Now, I've figured I might as well talk to the developers since you guys can make what I want happen, right?".
In the end, the infuriated customer only wanted a different set of options for a report (nothing fancy). The guy stopped calling tech support after that. He used to email the developers whenever he found an issue. He was happy with this approach. So were we. We got to understand our customers a bit better.
In the end, the infuriated customer only wanted a different set of options for a report (nothing fancy). The guy stopped calling tech support after that. He used to email the developers whenever he found an issue. He was happy with this approach. So were we. We got to understand our customers a bit better.
This is really good advice. This was an essential part of developing delicious.
If it's for a product you love (and it should be if you're doing a start up), it's not tech support. It doesn't even feel remotley close to tech support. It's just fixing or explaining something that matters a lot to you. Hackers always want to talk about their pet projects... why not make the customer happy while doing it. :-)
I love doing tech support on my own sites, anything for one on one feedback with my users is very fun to me. If one user has an issue it's likely affecting others.
On my full time work though I run into the same problems he mentioned and I make a point to asking the requester (of the feature or project) why they want to do it or what the user will get out of it so I can see if there are problem areas or possible improvements as I implement the request. It might irritate the requester but I feel better knowing I've done a little bit more to make a good final result.
On my full time work though I run into the same problems he mentioned and I make a point to asking the requester (of the feature or project) why they want to do it or what the user will get out of it so I can see if there are problem areas or possible improvements as I implement the request. It might irritate the requester but I feel better knowing I've done a little bit more to make a good final result.
I worked in a place where devs were also top-tier tech support. This worked well, as we got to figure out what the problems were, got to help teach our users the capabilities of the system, and got to look cool when we fixed a problem in 2 minutes. This was for an in-house network appliance, so our users were pretty technical anyway, which definately helped. What did not help tho, was when the help desk got lazy and started directing tickets to us which had no place in our laps. Then it all went down hill.
In short, its balancing act.
In short, its balancing act.
I'm curious what balance others have struck between development and tech support. I know personally I wouldn't want to be developing something and have to take a support call (or email) every 15 minutes.
My idea would be to rotate who is "on support" every week or two. This would ensure everyone does get time doing support without it becoming a hassle and interruption to getting other things done.
What are your thoughts?
My idea would be to rotate who is "on support" every week or two. This would ensure everyone does get time doing support without it becoming a hassle and interruption to getting other things done.
What are your thoughts?
You could always force email, like 37Signals.
I don't think there's a one size fits all solution though.
I don't think there's a one size fits all solution though.
Good point, although if I remember correctly 37signals has at least one dedicated support person (possibly more).
That's just to answer emails though.
Summary: Direct communication with users yields better software. Dedicated tech support often translate poorly from user issues to feature requests.
A similar sentiment should be mentioned as a developer looking for feedback from users when you have to deal with your customer's version of "tech support". The managers and tech support people are explaining what they think the problem is that the users are seeing, but when you walk through what the user is actually doing it's usually pretty surprising what you will uncover.
I think anyone heavily involved in a not-too-unknown open source project can get this experience, via mailing lists, forums, issue trackers, IRC channels.
Depends who your target is. The channels you listed require a bit of tech savvy, my mom is not going to file a bug report.
I tend to agree, but there are obvious counter examples.